> For the complete documentation index, see [llms.txt](https://docs.espressosys.com/network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.espressosys.com/network/network/networks/read-from-network.md).

# Reading from Espresso

Chains and applications integrated with Espresso gain access to fast, trust-minimized transaction confirmations backed by Espresso's decentralized Proof of Stake consensus. Users and applications do not need to wait for Ethereum settlement or rely on a centralized sequencer to determine whether a transaction is settled. Instead, they can act on Espresso-confirmed state much earlier.

To enable this experience, an **RPC node** runs in front of an integrated chain's existing full node and serves chain state derived from Espresso-confirmed blocks. From a developer's perspective it behaves like a standard full node: it exposes the familiar JSON-RPC interface, with state that reflects what Espresso has already settled — surfaced through the `espresso` block tag. For how the proxy resolves that tag and keeps finality safe, see [Reading via the RPC Node](/network/network/networks/read-from-network/reading-via-rpc-node.md).

> The RPC node is additive — it does not replace or modify your full node, which keeps running as-is. Because it still speaks the standard [JSON RPC API](https://ethereum.org/developers/docs/apis/json-rpc/), it works seamlessly with existing tools and libraries — point your RPC URL at it, with no extra code needed to integrate.

### RPC nodes in the architecture

Without Espresso, applications on an integrated chain can either:

* Rely on the sequencer for a *soft* confirmation, which is fast but requires trusting the sequencer, or
* Wait for parent-chain settlement, which provides strong security guarantees but introduces significant latency.

Espresso removes this tradeoff. Once Espresso confirms a transaction or block, the RPC node derives the resulting chain state and serves it through the standard RPC endpoint, just as if the transaction had already settled on the parent chain. For developers, this means no change to existing application integrations: query the same RPC methods, but the state reflects Espresso settlement sooner and with stronger guarantees.

For example, if Laura deposits **10 ETH** into an exchange on a chain integrated with Espresso, the exchange can safely treat the transaction as settled as soon as Espresso confirms it. From that point on, there is no risk of the transaction being reordered. The frontend can confidently reflect the deposit without waiting for parent-chain inclusion by simply reading from the RPC endpoint.

### Using RPC nodes

Functionally, an RPC node behaves exactly like a standard full node: it exposes the same RPC interface and methods. The key difference is in how it determines the state of the chain: applications read Espresso settlement by querying the RPC.

The examples below use the Rari testnet RPC endpoint. For a full list of available RPC endpoints across integrated chains, see [Live on Espresso](/network/network/chains-reference.md).

* Get block by block number (Rari testnet):

```bash
curl -X POST https://rari.caff.testnet.espresso.network \
    -H "Content-Type: application/json" \
    -d '{
        "jsonrpc": "2.0",
        "method": "eth_getBlockByNumber",
        "params": ["<BLOCK-NUMBER>", true],
        "id": 1
    }'
```

Where `<BLOCK-NUMBER>` is the number of the block in hexadecimal.

* Get transaction by transaction hash (Rari testnet):

```bash
curl -X POST https://rari.caff.testnet.espresso.network \
    -H "Content-Type: application/json" \
    -d '{
        "jsonrpc":"2.0",
        "method":"eth_getTransactionByHash",
        "params":["<TRANSACTION-HASH>"],
        "id":1
    }'
```

Where `<TRANSACTION-HASH>` is the hash of the transaction (prefixed with `0x`).

To run your own RPC node, see [Run an RPC Node](/network/developer/operators/running-rpc-node.md).