Reading from Espresso

Chains and applications integrated with Espresso gain access to fast and trust-minimized transaction confirmations. Users and applications do not need to wait for parent-chain finality or rely on a centralized sequencer to determine whether a transaction is final. Instead, they can use Espresso's confirmation guarantees to safely treat transactions as finalized much earlier.

To enable this experience, integrated chains run a modified full node capable of reading Espresso confirmations and producing finalized state based on them. We call these modified nodes Caffeinated Nodes, or simply Caff Nodes. A Caff Node behaves like a standard full node of the chain, but with additional logic to consume finalized blocks from the Espresso Network. From the perspective of a developer or application, a Caff Node exposes the same familiar RPC interface.

Caff Nodes are functionally identical to operating a standard full node. Running a Caff Node is as simple as running a full node with certain Espresso flags enabled in the node config so that it can read data from the Espresso Network. Caff Nodes follow the standard JSON RPC API and work seamlessly with existing tools and libraries with no extra code needed to integrate.

Caff 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 the parent-chain finality, which provides strong security guarantees but introduces significant latency.

Espresso removes this tradeoff. Once Espresso confirms a transaction or block, the Caff Node derives the resulting chain state and makes it available via the standard RPC — just as if the transaction had already finalized on the parent chain. For developers, this means no change to existing application integrations: the node behaves the same, but finality is faster and trust-minimized.

For example, if Laura deposits 10 ETH into an exchange on a chain integrated with Espresso, the exchange can safely treat the transaction as final 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 L1 inclusion — by simply reading from the Caff Node RPC.

Using Caff Nodes

Functionally, a Caff 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.

The examples below use the Rari testnet Caff Node. For a full list of available Caff Node endpoints across integrated chains, see Live on Espresso.

• Get block by block number (Rari testnet):

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):

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 Caff Node, see Run a Caff Node.