Trust model
What the sequencer, relayer, and bridge operator can and cannot do.
null today is an MVP with centralized operators. Being precise about what each one can and cannot do is more useful than claiming decentralization it does not have.
Live on devnet — dev-grade and unaudited. The trusted setup alone means this is not safe for real value, independent of the operator trust below.
The sequencer
There is one PoA sequencer. It orders and produces every block.
- Can: decide transaction ordering and inclusion; censor (refuse to include a transaction); halt the chain (liveness).
- Cannot: forge a shielded transfer or steal from the pool — every pool op requires a valid Groth16 proof the sequencer cannot fabricate; create value in the pool — the value invariant is enforced by proof verification, not by the sequencer's honesty; spend a note it does not own — that needs the owner's spending key.
- Roadmap: decentralizing the sequencer is a later phase.
The relayer
There is one relayer (see Relayer).
- Can: refuse to submit a withdrawal (censor).
- Cannot: redirect a withdrawal, change its amount, or inflate its fee — recipient, amount, relayer, and fee are all bound in the proof.
- Roadmap: a relayer market so no single relayer can censor.
The bridge operator
The bridge is a single-operator model; the relayer holds the sequencer key and the Solana vault trusts that one pubkey.
- Can: delay or censor bridge deposits/withdrawals (liveness).
- Cannot: mint unbacked credit on null (deposits are idempotent per Solana
nonce and gated by attestation) or release more SOL from the vault than is
backed (
amount > netBackingburns are rejected; thevault.bridged_balance == minted − burnedinvariant is enforced). - Pending: the real vault is not yet deployed to a validator — see Bridge.
The user
- Must: keep their spending key (derived from the wallet signature) and their encrypted note backup. Losing notes loses funds; no operator can recover them.
Summary
Operators are trusted for liveness (they can stall or censor). They are not trusted for safety — the cryptography (proof verification, value invariants, nullifier/commitment bookkeeping, destination binding) prevents theft and forgery regardless of operator honesty. The one caveat that overrides everything is the trusted setup.