> ## Documentation Index
> Fetch the complete documentation index at: https://rexrex.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# rex — Reth Node Explorer

> Developer tooling for exploring Reth EVM Node execution internals.

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](/docs/quickstart), then work through the [Chain guide](/docs/chain), [Execution guide](/docs/execution), [Engine guide](/docs/engine), [Network guide](/docs/network), [TxPool guide](/docs/txpool), or [Database guide](/docs/db).

## Architecture

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

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.