On xOneRS an operator bans a peer with admin_banPeer, giving its enode URL or its 128-hex node id. The ban closes the peer's session, ends its redial loop and refuses it in and out until you call admin_unbanPeer. Bans are kept in memory, at most 4,096 node ids, and a restart starts with none. They came in PR #951 (merged 2026-11-14, closes #867); the v0.1.0 release does not have them.

For the other ways to limit peers (the allowlist and --netrestrict), see the p2p live checklist.

How do I ban and unban a peer?

The admin namespace serves three methods (admin.rs):

REFERENCE TABLEScroll to explore all columns →
Method Parameter Result
admin_banPeer enode URL or 128-hex node id (optional 0x) false when the id is already banned
admin_unbanPeer the same true when the id was banned
admin_bannedPeers none the banned node ids, hex

Example, over the local IPC socket or an authenticated admin endpoint (the request is an example, not a recorded call):

curl -s -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"admin_banPeer","params":["enode://<128-hex-id>@<ip>:<port>"]}' \
  http://127.0.0.1:8545

Like every admin method, these are served only where the admin namespace is enabled: on authenticated or local transports. admin is not in the default HTTP API list (transport exposure).

What exactly does a ban do?

A ban is keyed by the node id, so a new IP address does not help the peer. A banned id is refused on inbound connections and on every dial: static, trusted and discovery. The ban closes the current session and ends the redial loop. Static and trusted marks stay and apply again after an unban (net.rs, peers/mod.rs).

How is it different from an automatic ban?

xOneRS also bans peers on its own. Each peer has a score; a peer that crosses the threshold is disconnected and, unless it is trusted, banned until a time, keyed by node id (score.rs). The operator ban is kept apart: a ban or an unban does not change the peer's score.

REFERENCE TABLEScroll to explore all columns →
Automatic ban Operator ban
Set by the node, when a peer's score crosses the threshold you, with admin_banPeer
Ends at a time at admin_unbanPeer or a restart
Trusted peer not banned, may reconnect at once banned; the ban wins
Changes the score yes no

Does a ban survive a restart?

No. The bans live in memory; a restart starts with none. Re-apply them after a restart, or use the allowlist --permissions.nodes, which is a start flag.

A later change, PR #993 (merged 2026-11-15), adds a module with a versioned file format for manual bans (xone-manual-bans v1, one hex id per line, at most 1,024 entries). PR #993 lists its wiring and the restart policy as remaining work, so on main today the bans that the RPC sets are still in memory only.

How do other clients describe it?

The collected competitor articles state no claim about manual peer bans. xOneRS names its methods after reth's admin_banPeer and admin_unbanPeer, as the source says, so no comparison table is given.

Frequently asked questions

Can I ban a peer by IP address?

No. Bans are by node id: an enode URL or the 128-hex id. To limit by address range, use --netrestrict.

What happens to a trusted peer that I ban?

The ban wins: the session closes and the peer is refused. Its trusted mark stays and applies again after admin_unbanPeer.

How many peers can I ban?

At most 4,096 node ids at once.

Does the v0.1.0 release support admin_banPeer?

No. The operator bans came in PR #951, merged on 2026-11-14, after v0.1.0.

Sources