Use this page to see who does what when a transfer moves through Rand. Proving is expensive and verifying is cheap, so the work is split along that line. The sender’s side makes the proofs. Validators only check them, order them and vote. An aggregator, once switched on, would fold many proofs into one. The figure follows one transfer from the wallet to a final block; the sections after it take each role in turn.
The path of one transfer
- The wallet builds the transfer. It picks its input notes, fetches their Merkle witnesses, builds four outputs and seals each in an ML-KEM-768 envelope. It then computes the transaction’s binding, a hash over everything but the proofs (Transactions).
- The wallet proves the authorisation itself. This is a tier-10 proof over the spend key and a fresh salt, a matter of seconds. It is the only proof that touches the spend key, and it is always made on the wallet’s own machine.
- The bundle proof is made where there is memory for it. This tier-14 proof shows ownership, membership, the nullifiers and the balance, and peaks at about 6 GB. The desktop app and a phone with about 8 GB make it themselves. Anything smaller hands the job to a prover it is paired with: one you run, or the validators’ pool at
prover.randprotocol.org. Either is sent the viewing key and the salt, never the spend key (Proofs). - An RPC node checks it. Whatever node the wallet submits to recomputes the bundle digest, verifies both proofs against the binding, checks the fee, and only then gossips the transaction to its peers (Proofs, Mempool).
- Validators order and finalise it. The leader of the view takes the transactions that still apply, best fee per KiB first, and proposes a block. Every validator re-verifies every proof in it and votes. The block commits once three quorum certificates chain on it in consecutive views, which needs 18 of chain 21’s 26 validators online (Consensus).
- The block is final, and everyone can check it. A transaction is final when
rand_getTransactionreturns a block. A node that syncs later re-verifies every certificate and every proof rather than trusting the signatures.
The roles
| role | what it does | proves? | what it sees | runs |
|---|---|---|---|---|
| wallet | builds, authorises and submits transfers and calls; scans the chain with its own keys | the authorisation proof always; the bundle proof when the device has the memory | everything about its own notes | the apps on the Clients page, or rand; on chain 21, Rand Wallet or rand v0.8.0 (on chain 20 it was v0.6.8 or later) |
| delegated prover | makes the bundle proof for a wallet paired with it; every reply is checked by the wallet before anything is submitted | bundle proofs only | the paired wallet’s viewing key: its whole history, past and future; it cannot spend | rand-prover run, or rand-node run --prover |
| validators’ prover pool | a delegated prover run by four hosts, two validators and two machines that only prove, behind one name and one key, for wallets with no prover of their own; no fee | bundle proofs only | the same as any delegated prover, for every wallet that pairs it | prover.randprotocol.org, fingerprint RGTF-7HKJ-XZFV-GQ1J |
| RPC node (observer) | syncs, re-verifies every proof, serves JSON-RPC, gossips verified transactions; no vote | no | public fields only: commitments, nullifiers, sealed envelopes, proofs | rand-node run |
| validator | everything an observer does, plus proposing in its views and voting in HotStuff | no | public fields only | rand-node run --validator |
| aggregator | proves one recursive proof over a window of finalised bundle proofs and submits it for a sealing block | yes, the largest proofs on the network | public fields and proofs only | rand-node aggregate --watch, on a chain with an aggregation section |
Proving and validating are separate jobs, and a validator does not need prover hardware. Two of the pool’s four members are validators that also run a prover, as a service; the other two are dedicated prover machines that hold no validator key. Running the pool is not part of validating. Sizes for each role, and the measured proving memory per tier, are on Validator and aggregator hardware.
What each role can learn
The privacy of a transfer depends on who holds which key, not on trusting the network:
- Validators, RPC nodes and the explorer see what every node sees: commitments, nullifiers, sealed envelopes, the fee and the proofs. Not the amount, the asset, the sender or the recipient.
- A delegated prover, including the pool, is sent the viewing key. With it, it can read the paired wallet’s entire history. It can never spend, because the authorisation proof over the spend key is made on the wallet’s machine. Pairing the pool means choosing to show its operators that history. If you want it private, prove on your own device or run your own prover.
- A delegated prover cannot cheat the wallet. The wallet reads the digest off every proof it is given, checks the size and verifies it locally, so a wrong proof never reaches a node.
Aggregation: built, not on
Today every block carries every raw proof, about 2.85 MB for a transfer, so a 20 MiB block holds about seven transfers. Block aggregation is the fullnode’s answer. An aggregator takes the bundle proofs of a window of finalised blocks (rand_getUnsealed), proves one recursive proof that verifies them all, and submits it. The block that includes it seals the window. Validators then verify one aggregate instead of N proofs, and nodes can drop the covered raw proofs. Aggregators are bonded and permissionless, run on GPU-class machines, and are paid the covered bundles’ proving share plus a block subsidy in new RAND.
It is built and merged, but it is not active. It needs an aggregation section in the genesis, and chain 21 has none, as chain 20 had none, so rand_status reports every aggregation counter as zero. Before it can be switched on, its bundle shape must be re-measured under the current constraint set, and a forged-aggregate exercise must be run against the recursion verifier. On a split-authorisation chain it would also seal only the bundle proofs, not the authorisation proofs (Proofs).