> 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/developer/operators.md).

# Run Espresso Infrastructure

There are three operator roles you can run against Espresso. Each one serves a different purpose, has different hardware needs, and is run by a different kind of team.

## Pick your role

| Role               | Who runs it                                                         | What it does                                                                                                                                               | Hardware                                                                                     |
| ------------------ | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| **Validator node** | Stake operators (institutional and independent) earning ESP rewards | Participates in [HotShot consensus](/network/network/networks.md#protocol-documentation), finalizing blocks across Espresso                                | 1 CPU core, 8 GB RAM (non-DA); 4+4 CPU, 8+4 GB RAM, 1.2 TB SSD (DA)                          |
| **Builder**        | Block proposers serving an Espresso chain's slot                    | Pulls transactions from the public mempool, assembles blocks, and submits them to Espresso for finalization                                                | 2-4 CPU cores, 4-8 GB RAM                                                                    |
| **RPC node**       | Chains and applications integrated with Espresso                    | Reads Espresso-confirmed blocks and serves standard EVM JSON-RPC, so applications see settled state without waiting for downstream parent-chain settlement | Varies; see the [caff-node-run](https://github.com/EspressoSystems/caff-node-run) repository |

## When to run which

* **You hold ESP and want to participate in consensus / earn rewards.** [Run a Validator Node](/network/developer/operators/run-a-node.md). You'll register in the stake table, attract delegations, and run the node software on the network of your choice.
* **You operate an Espresso-integrated chain and need to propose blocks.** [Run a Builder](/network/developer/operators/running-a-builder.md). The builder is the component that bundles transactions for your chain's namespace.
* **You operate a chain or application and need fast, low-latency reads of settled state.** [Run an RPC Node](/network/developer/operators/running-rpc-node.md). This is the read-side counterpart to the builder, exposing standard JSON-RPC.

## Related references

* [Networks](/network/network/networks.md): public endpoints and contract addresses for Mainnet and Decaf Testnet.
* [Stake Table Contract](/network/network/networks.md#mainnet): validator registration and stake delegation contract addresses on Ethereum.
* [Reading from Espresso](https://github.com/EspressoSystems/gitbook/blob/main/concepts/read-from-network.md): the conceptual basis for what an RPC node provides.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.espressosys.com/network/developer/operators.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.