Appearance
Validator vs RPC Node
Both validators and RPC nodes run the same agave-validator binary, but they serve fundamentally different roles in the network. Understanding the distinction is important before deciding what to operate.
Validators
A validator participates in consensus. It receives transactions via the leader schedule, produces blocks when it is the leader, and votes on the validity of blocks produced by other validators. Voting is an on-chain activity — each vote is a transaction that costs fees and earns vote credits.
Key characteristics:
- Votes on-chain using a vote account funded with the network's native token.
- Requires stake delegation — on Zink, the validator set is permissioned, so stake must be delegated through the network operators.
- Earns inflation rewards proportional to vote performance and delegated stake.
- Needs low-latency networking to keep up with the cluster and minimize skip rate.
- Runs with
--expected-genesis-hashand identity/vote keypairs provisioned during onboarding.
Zink-specific
Zink currently operates a permissioned validator set. You cannot join consensus by self-staking. Contact the Zink network operators through the current operator onboarding path before planning validator participation.
RPC nodes
An RPC node replicates the full ledger and account state but does not vote. It exists to serve JSON-RPC requests — getAccountInfo, sendTransaction, getSignaturesForAddress, and so on — to applications, wallets, and indexers.
Key characteristics:
- Does not vote — started with
--no-voting. - No stake required — anyone with the hardware can run one.
- Serves client traffic — wallets, explorers, bots, and backend services connect here.
- Often needs more storage than a validator because operators typically enable full transaction history and account indexes.
- Can expose specialized APIs like
--full-rpc-apifor methods that validators may not serve.
Upstream-compatible
The RPC node role on Zink is identical to Solana. If you have operated an RPC node for Solana mainnet or devnet, the same operational knowledge applies.
Side-by-side comparison
| Dimension | Validator | RPC Node |
|---|---|---|
| Participates in consensus | Yes | No |
| Produces blocks | Yes (when leader) | No |
| Votes on-chain | Yes | No |
| Requires stake | Yes (permissioned on Zink) | No |
| Earns rewards | Yes | No |
| Serves JSON-RPC | Optional (usually limited) | Yes (primary purpose) |
--no-voting flag | Not set | Set |
--full-rpc-api flag | Rarely | Typically |
| Account indexes | Optional | Often enabled |
| Minimum hardware | High CPU + RAM + fast NVMe | Same or higher (more storage) |
Which should you run?
Run a validator if you have been invited to participate in Zink consensus, have received or will receive stake delegation, and want to contribute to block production and network security.
Run an RPC node if you need a dedicated, low-latency RPC endpoint for your application, want to avoid rate limits on shared infrastructure, or need to serve specialized queries (historical lookups, account scans, Geyser plugins).
Zink recommendation
If you are building an application integration, data pipeline, marketplace service, or automation backend, an RPC node is almost certainly what you want. Validator operation is reserved for parties coordinating directly with the Zink network team.
Next steps
- System Requirements — hardware specs for both roles
- Run a Validator — full validator setup guide
- Run an RPC Node — full RPC node setup guide