◆Node operators

Run a node

The most useful thing anyone outside the team can do for Solieum's security is independently check its work.

The most useful thing anyone outside the team can do for Solieum's security is run a verifier. It re-derives the chain from published data and compares its own state root against what the operator posted. A mismatch is the alarm that matters most in the entire system.

  • Verifier

    In progress

    Re-derives L2 state independently and raises an alarm on divergence. The single highest-value role, and the one Solieum most wants running outside the team. It is one command today, solieum-node verify --watch, with its own RPC reader set that must agree, an alarm URL, and the supply check against the vault; drilled 2026-09-04. What is missing is someone outside the operator running it, and a published image and spec that make that easy.

    Moderate hardware · L1 RPC access · always-on

  • Challenger

    In progress

    A verifier that also plays the dispute game on Solana when it finds a bad root, putting up a bond and claiming the proposer's on success. Built for the step classes that exist: the watchtower opens a challenge under bond when it sees a divergence, then plays the moves that win — opening the dispute with the trace's step count, answering each midpoint from the re-derived trace, and sending the witnessed one-step where the traces part — for every transfer and bridge step class; program calls remain outside it. The dispute program is on devnet and the harness drives the full game from alarm to removal. On the alpha devnet chain a won game resolved nothing, because that chain's dispute authority was a key; since the beta chain (2026-09-05) the authority is the game's enforcer, and it is on gamma today, so a verdict there removes the root. No dispute has yet been played on a public cluster.

    Verifier requirements · bond capital · L1 transaction capability

  • RPC node

    In progress

    Serves state and accepts transactions for applications and wallets. No authority over consensus — an RPC can lie to its clients, which is why anything that matters should be checked against L1. solieum-node serves a Solana-shaped JSON-RPC and an explorer today, and accepts a wallet's own wire format; it is not a drop-in Solana RPC, and there is no public endpoint yet.

    Higher hardware · public bandwidth

  • Archive node

    Planned

    Retains full history so withdrawal proofs stay constructible far into the future. Unglamorous and load-bearing. Today the node's own append-only log of published batches plays this role for the chain it runs; a service others can rely on is not built.

    Large storage, growing continuously

◆Day to day

What a verifier actually does, hour to hour

Demystified: it is a quiet loop with one loud exit.

  1. 01

    Pull: fetch new batches from the Solana transactions the data-availability program posted them in, and new roots from the settlement program's account, as they land. Mostly idle bandwidth.

  2. 02

    Re-execute: run the batches through the same deterministic execution the sequencer ran. Same inputs, same code — byte-identical outputs, every time.

  3. 03

    Compare: your computed root against the posted one. Equality is the overwhelmingly common case and produces nothing but a log line.

  4. 04

    Alarm: on any mismatch, alert loudly and immediately — this is the single most important signal in the whole system, and it must reach humans in seconds.

  5. 05

    Escalate: with challenger tooling and a bond, open the dispute on L1 and see it through. The bad root is removed; the bond that backed it pays for the trouble.

Operational honesty

  • It is boring on purpose

    A verifier that never fires its alarm is succeeding, not wasting money. The value is the standing threat — fraud is deterred by the certainty of detection, which only exists if you are running.

  • Determinism is the contract

    If your node computes a different root, either you caught fraud or you found a determinism bug. Both are reportable, valuable, and taken seriously — the second is our bug, not your noise.

  • Independence is the point

    A verifier run by the operator checks nothing that matters. Geographic, organisational, and client diversity are what turn a monitoring script into a security property.

State growth is the real hardware question

At high throughput on an account-model chain, disk and state-tree update cost centralise the operator set long before execution speed does. Requirements published as a single specification are not useful; what matters is growth per month at target load, and whether an ordinary operator can still keep up in a year. Solieum will publish the growth curve alongside the first requirements.

Planning to run a verifier?

Specifications and images will be published with the public testnet, along with the protocol repository itself, which is not yet public. The node runs against Solana devnet on ordinary hardware — the entire devnet chain runs on one laptop. If you intend to run a verifier, tell us now — we would rather design the tooling with operators than hand it to them afterwards.

Tell usHow verification works