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.

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) and from the validium node role described under zkNode/validium, 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 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.

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 first: an RPC node needs meaningfully more RAM and disk than a typical small VPS. Then see the deployment tutorial for the actual install/config/sync steps, and JSON-RPC endpoints for what your node serves once it's synced.