rex — Reth Node Explorer

rex is the Reth Node Explorer: developer tooling for inspecting, experimenting with, and learning Reth EVM node execution internals. It is not intended to replace tools such as cast or a general Ethereum RPC client. Those tools answer application-level questions such as account balances, contract call return values, and block contents. Rex focuses on lower-level execution-client questions.

Why it Exists

Ethereum execution clients expose most functionality through standardized JSON-RPC APIs such as eth_getBlockByNumber, eth_call, eth_getLogs, and debug_traceTransaction. That API boundary is useful for applications, but it hides many of the execution-client systems that decide how a node behaves:

transaction validation, ordering, replacement, queueing, and propagation
EVM execution, state transitions, receipts, logs, and gas accounting
account and storage changes
provider and storage access backed by MDBX and static files
payload building and transaction selection
Engine API communication between the consensus and execution layers
peer management, gossip, and block propagation
pruning, database layout, and historical data retention

Rex gives those subsystems a CLI surface that is practical for debugging and useful for learning.

Current Surface

The current implemented areas are chain inspection, execution tracing and simulation, authenticated Engine API inspection, node networking inspection, transaction-pool inspection, and read-only local database inspection. Chain, execution, network, and txpool commands default to http://127.0.0.1:8545 (localhost:8545). Engine commands default to the authenticated Engine API at http://127.0.0.1:8551 (localhost:8551). Pass the global --rpc <URL> flag when either endpoint is elsewhere. Database commands use a local --datadir instead of RPC.

Chain

Command	Question it answers
`chain head`	What are the latest, safe, and finalized heads?
`chain block --block ...`	What does this block look like by number, hash, or tag?
`chain ancestry --block ... --depth ...`	What parent chain leads backward from this block?
`chain canonical --hash ...`	Does this hash match the canonical block at its number?

Execution

Command	Question it answers
`execution simulate --to ...`	What return data and gas estimate would this call produce?
`execution simulate --tx ...`	What would this transaction’s call fields do against a selected block state?
`execution replay-tx --tx ...`	What call tree did this transaction execute?
`execution state-diff --block ...`	Which accounts and storage slots changed while executing this block?

Engine

Command	Question it answers
`engine capabilities`	Which Engine API methods does this execution client report?
`engine payload-bodies --hash ...`	Can the authenticated Engine API return payload body data for this execution block hash?

Network

Command	Question it answers
`network status`	Is the node listening, how many peers are connected, and which network ID is active?
`network node`	What devp2p identity, addresses, ports, and protocols does this node expose?
`network peers`	Which peer sessions are established, and what are their directions and capabilities?

TxPool

Command	Question it answers
`txpool inspect`	What pending and queued transactions are visible right now?
`txpool sender --address ...`	What pool transactions belong to this sender?
`txpool nonce-gaps --address ...`	Which missing nonces are keeping later transactions queued?
`txpool replacement --tx ...`	What fee bump would be needed to replace this transaction?
`txpool fees`	What is the fee distribution across the current pool?
`txpool duplicates`	Are there same-sender, same-nonce conflicts?
`txpool stats`	What are the aggregate pool counts, types, gas, blobs, and top senders?
`txpool watch`	What transactions are added or removed between snapshots?

Database

Command	Question it answers
`db --datadir ... info`	How much data is represented by MDBX tables, freelist pages, and static files?
`db --datadir ... tables`	Which Reth tables contain entries, and how many MDBX pages do they occupy?
`db --datadir ... version`	Is this database schema compatible with Rex’s pinned Reth database API?

Start with the quickstart, then work through the Chain guide, Execution guide, Engine guide, Network guide, TxPool guide, or Database guide.

Architecture

Rex is split into a reusable core crate and a CLI crate:

rex/
|-- crates/
|   |-- rex-core/
|   `-- rex-cli/
`-- Cargo.toml

rex-core returns structured Rust types for analysis and integration logic. rex-cli handles arguments, calls the core crate, and formats terminal output. Conceptually:

CLI arguments
    |
    v
rex-core
    |
    v
structured result
    |
    |-- terminal output
    `-- future JSON or other interfaces

Depending on the feature, Rex can use JSON-RPC, IPC, or direct Reth Rust APIs. IPC is still a JSON-RPC transport; it does not imply direct database access. The database component uses Reth’s database API directly and opens MDBX read-only.

Project Direction

The project should grow along real Reth subsystems:

TxPool
  -> Providers
  -> Execution / EVM
  -> State
  -> Trie
  -> Payload Builder
  -> Engine API
  -> Networking
  -> Database / Pruning

Each command should map to a concrete execution-client concept and a practical question. That keeps Rex from becoming a generic Ethereum CLI and makes it useful as a path toward upstream debugging and contribution.

​Why it Exists

​Current Surface

​Chain

​Execution

​Engine

​Network

​TxPool

​Database

​Architecture

​Project Direction