> For the complete documentation index, see [llms.txt](https://docs.lumia.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lumia.org/run-a-node/rpc-node/rpc-node-overview.md).

# RPC node overview

**Who this is for:** operators deciding whether to run their own Lumia RPC node. By the end you'll know what the node does, whether you need one, and where to go to actually deploy it.

**You should already know:** the basics of Lumia's architecture. See [`/lumia/architecture`](file:///lumia/architecture/Architecture.md).

## What it is

A Lumia RPC node is a full execution node: it syncs the complete state of the chain and serves standard JSON-RPC, both reads (`eth_call`, `eth_getBalance`, log queries, and so on) and transaction submission. It is a **read replica**, not a block producer. Lumia Prism has exactly one sequencer producing blocks; every RPC node independently verifies and serves that state but has no role in producing it. Run as many as your read traffic requires: they add availability and verifiability, not consensus weight, and you don't need anyone's permission to stand one up.

This is distinct from a **light client** (verifies without holding full state or executing every transaction; see [DA light client](file:///5838283/da-lightclient/DA-light-client-overview.md)) and from the **validium node** role described under [zkNode/validium](file:///5838283/zknode/zkNode-overview.md), which is closer to the chain's proving layer than to a read endpoint.

## Who needs one

* **Dapp backends** that don't want to depend on a shared public endpoint's rate limits or uptime.
* **Indexers** that need sustained, high-volume log/state queries.
* **Anyone who wants their own SLA** rather than the public RPC's.

If you just need occasional reads for a script or a wallet, a public endpoint from [`/reference/networks`](file:///reference/Networks-and-endpoints.md) is almost certainly enough: you don't need to run infrastructure for that.

## How it fits Lumia's design

Your node ingests new blocks from a continuous stream fed by the sequencer and independently re-executes and verifies them: it does not trust the sequencer's output blindly. Because there's no consensus protocol to participate in, adding an RPC node is purely additive: it costs you hardware and bandwidth, and it costs the network nothing.

The topology this page has established so far: the node's upstream connection is the sequencer's block stream, and its downstream connection is whatever client calls it for reads or transaction submission.

```mermaid
flowchart LR
    Sequencer -->|block stream| RPCNode[Your RPC node]
    RPCNode -->|JSON-RPC reads, tx submission| Client[Dapp backend, indexer, or script]
```

This does not show whether a transaction your node accepts is itself forwarded on to the sequencer: that path is not stated on this page.

## Before you deploy

Check [hardware requirements](file:///5838283/Hardware-requirements.md) first: an RPC node needs meaningfully more RAM and disk than a typical small VPS. Then see the [deployment tutorial](file:///5838283/zknode/Run-a-local-validium-node.md) for the actual install/config/sync steps, and [JSON-RPC endpoints](broken://pages/25979c0e6001456578937f30a0904c1c289acb74) for what your node serves once it's synced.