Cryptography

Use this page to pick the right library when you interoperate with the chain, to check a parameter against what the node enforces, and to recompute an id or a commitment yourself. Every value here is the one the code runs on chain 21 (fullnode v0.8.0, tag c0878c3f, live since 2026-10-12); where chain 21 changed a value, the chain-20 one is kept beside it.

Primitives and where they are used

The whitepaper’s target parameters differ in places from what the implementation runs (for example the paper’s 384-bit transcript hash against the zkVM’s Poseidon2 transcript). These pages describe the code.

Post-quantum co-signatures on the bridge

The bridge’s guardian attestations are secp256k1 ECDSA, which a quantum adversary could forge. Since chain 14 every BridgeAttest — a deposit and a guardian-set rotation alike — must also carry a quorum of Dilithium2 signatures by the same guardians over the same digest:

M = "rand-bridge-pq-cosign-1" || rand_chain_id (u64 BE) || mu        // 63 bytes, deterministic signing

where mu = keccak256(keccak256(body)) is what the ECDSA quorum signs. The Rand chain id in M keeps a testnet co-signature from verifying on another Rand chain even if guardian keys were reused. M binds the chain id only, on chains 20 and 21 as well: it is the one signed message binding_domain did not move behind the genesis hash, because the guardian daemons that sign it live in another repository. A copy of a chain under the same chain id with the same guardian set would accept its deposits’ co-signatures; the guardian-set index is not in M, so a co-signature survives an ECDSA-set rotation. The action’s pq_signatures field is a list of PqSignature { index: u8, signature }, checked cheap before expensive: quorum(n) ≤ len ≤ n (PqNoQuorum), indices strictly increasing (PqIndexOrder), every index below n (PqIndexOutOfRange), every signature exactly 2,420 bytes (PqBadSignatureLength), and last every signature verified under pq_guardians[index] (PqBadSignature). The PQ signers need not be the ECDSA signers; each quorum is counted on its own. The field is inside the transaction binding, so it cannot be stripped or swapped on a copy.

The PQ set is the genesis bridge.pq_guardians — eight 1,312-byte keys on chain 21, as on chains 15 to 20, index-aligned with the genesis ECDSA set, guardian set 1 (chain 14 had six, aligned with set 0). An ECDSA guardian-set rotation never moves it. On chain 14 it was fixed for the chain’s life; since chain 15 the genesis carries the bridge’s rules_v2 group, under which a PQ quorum can replace the whole PQ set (RotatePqGuardians) or the pause key (RotatePauseKey), each under the bridge’s rotation_nonce. Chain 20’s genesis added bridge.rotation, which chain 21 carries: a rotation must be the V2 action, carrying each new key’s own Dilithium2 signature over the same message (proof of possession), and it takes effect a day after it lands unless the current pause key cancels it (Bridge). rand_getBridgeState serves the keys and a decoded bridge_attest lists pq_signers, the indices that signed. The same PQ quorum authorises the bridge’s governance messages, each a fixed big-endian layout carrying the chain id and a nonce. Since chain 20 (genesis binding_domain: 1) each domain’s version digit is 2 and the 32-byte genesis hash sits between the domain and the chain id; chains 14 to 19 use the -1 forms:

The STARK in production

The zkVM is at constraint set 9 (chain 21; chains 18 to 20 ran set 8): nine mandatory tables (program, cpu, memory, alu, range, nibble, poseidon2, input, public) plus a keccak, a sha256 and, since set 9, a modq table a proof carries only when its guest called the matching syscall, connected by buses and proved as one batch STARK. The modq table is the MODQ chip: one 1,024-row block per MODQ syscall (an NTT, inverse NTT, dot product or multiply-subtract over 256-coefficient polynomials mod Dilithium’s q = 8,380,417), declared in the proof header as modq_log_height, carried only by the multisig auth guest, and the reason every verifier key and the proof encoding moved at chain 21 (the cpu table gained the syscall’s columns). Since constraint set 7 every declared table has at least 2⁷ rows and every table’s LogUp terminal is blinded through the seventeenth bus, BLIND. A proof’s public interface is 35 field elements (pv::NUM): the entry pc, the tier, the eight output words, the program digest hc (8 words), the salted private-input commitment H_IN (8), the unsalted public-segment digest H_PUB (8) and, since constraint set 8, the declared gas limit GAS_LIMIT.

Measured sizes at constraint set 6 (Apple Silicon, release build): a keccak-free production proof was 1,298,729 bytes at tier 10 and 1,359,978 at tier 12; a keccak-carrying tier-10 proof was 3,198,430, over the 2 MiB default and under the 8 MiB of chains 13 to 15. A tier-14 proof of the retired 2-in-2-out bundle guest measured 1,321,773 bytes on chain 8, and 1,418,406 to 1,420,423 bytes on chain 13. Chain 14’s 4-in-4-out hidden-asset bundle guest stays at tier 14 with neither hash table, and its proofs measured 1,422,116 and 1,423,170 bytes on chain 14 (2026-09-20), and chain 15 pinned the same guest (hc_bundle unchanged); a bundle proof declared public_log_height 4 there, the height of the eight binding words, and the node refused any other value before building a verifier key. The keccak-carrying ERC-20 approve call proof made on chain 13 on 2026-09-19 (tier 16) is 3,412,405 bytes; every chain since fullnode v0.5.6 refuses that call, at tier 16.

Constraint set 7’s blinding columns and table floors add about 5% to a hash-free proof: measured by the fullnode on 2026-09-28, fib is 1,367,688 bytes at tier 10 and 1,424,299 at tier 12, a keccak-carrying tier-10 proof 3,283,898, and a tier-14 hidden-asset bundle proof 1,498,821 (guest v1) and 1,497,156 (guest v2). A bundle proof declares public_log_height 7 since then. Constraint set 8 adds under 1%. Measured on chain 18 on 2026-09-30 (Apple Silicon): auth proofs of 1,364,940 to 1,375,371 bytes (tier 10), bundle proofs of 1,494,151 to 1,504,260 bytes (tier 14, guest v3), and call proofs of 1,498,589 bytes at tier 14 with no hash table, 1,911,152 at tier 14 with the SHA-256 table and 3,346,865 at tier 12 with the Keccak table. All fit the 4 MiB cap of chains 18 to 20.

Verification is about 16 ms with a warm verifier key and about 230 ms the first time a (tier, heights) key is built. The test FRI profile (16 queries) exists for the test suite and is insecure; chain 21’s genesis pins production, as chain 20’s did. Fullnode v0.6.8 changed no constraint: chain 20 pinned the same hc_bundle and hc_auth as chains 17 to 19. Fullnode v0.8.0 (chain 21) keeps both digests — hc_bundle 60af094a…6e3fce, hc_auth 1e4e347f…5639c1 — and adds a third, hc_auth_multisig 9705f8e2f1bc8561848b29cb8efd57c37e3e39788fa58a5f03304d8019668247, the multisig auth guest at tier 18 (up to 3 of 16 Dilithium2 signatures checked in circuit; its pinned verifier key, msauth-vk-production.bin, 23,754 bytes, SHA-256 68facb06…cd30, is loaded by every validator at startup); under constraint set 9 every verifier key is new although the digests are not.

Hash constructions you can reproduce

BLAKE3 with a domain: blake3(domain || data), the domain string with no separator.

The binding domain. Chain 20’s genesis set binding_domain: 1 (fullnode v0.6.8, audit v6 BIND-1), and chain 21 keeps it. On such a chain every proof binding and every signed action message that bound the chain id alone now binds the genesis hash too: the domain’s version number goes up by one and the 32-byte genesis hash goes first in the preimage, before the chain id. A proof or a signature made for one chain then verifies on no other, even one that reuses the chain id and the keys, as a re-cut does. The binding words are a public input of the proofs, so no guest or verifier key changed. The table gives both forms; chains 14 to 19 use the first, byte for byte. Already genesis-bound before, and unchanged: votes and proposals (since consensus_domain: 1), the v2 Registration, and an AdmitValidator vote. Not moved: the bridge’s mint co-signature (above). A wallet needs v0.6.8 to send on chain 20 and v0.8.0 on chain 21, and decides the form by chain id, not by what a node claims; rand_getLimits.binding_domain reports it.

Poseidon2 with a domain tag: H(domain, msg) = sponge_hash([domain, msg...]), the tag the first absorbed word, each word a Goldilocks element, the 4-element digest split into eight u32 words (low half then high half of each element). Domain tags:

hc, H_IN and H_PUB are not plain message-prefixed sponges: the header goes into the capacity so that the digest rows in the cpu table absorb exactly four words per permutation. Reproduce them with the vendored crate (randprotocol_zkvm::hash::{input_digest, public_digest}, isa::Program::digest) rather than by hand.

The plain sponge does not pad, so within the first block [a] and [a, 0] hash alike. Every construction above hashes a fixed-length message under its own tag. For data whose length can vary, constraint set 7 added a length-bound sponge (hash::sponge_hash_len, the POSEIDON2_LEN syscall): it starts from the state [0, 0, 0, 0, n, 0, 0, 0], n the word count, and permutes at least once. It is a different hash of the same words, and no note, nullifier, root or digest on the chain uses it.

Two properties to remember: hc is binding but not hiding (no salt, so a guessed program can be confirmed and two deployments of one program are linkable), and H_IN is hiding as well as binding (a fresh 128-bit salt per proof), so publishing H_IN reveals nothing about the inputs until the salt holder opens it.

Key derivations

The papers on the papers page carry the security arguments: the post-quantum choices, the FRI soundness accounting and why 80 queries are kept, and the trace-length bound.