Soul of Satoshi (SOS)A Fully Post-Quantum Layer-1 with Opt-In Shielded Transactions and a Proof-Based, Non-Custodial Ethereum BridgeWhitepaper v2

Public blockchains are an unusually exposed cryptographic target: the entire transcript of every signature, public key, ciphertext, and commitment is published, replicated, and immutable by design. Against a classical adversary this is the point. Against a quantum-capable adversary it is a liability, because the ledger cannot be re-encrypted after the fact.

Shor’s algorithm [3] solves integer factorization and discrete logarithms (including elliptic-curve discrete logarithms) in polynomial time on a sufficiently large fault-tolerant quantum computer. Its consequences for the current blockchain stack are direct and structural, not incremental:

• •

  Transaction authorization. ECDSA over secp256k1 (Bitcoin, Ethereum accounts) and Schnorr/Taproot signatures derive their security from the elliptic-curve discrete-logarithm problem. Any address whose public key is visible on chain — every spent Bitcoin output, every Ethereum EOA that has ever transacted — yields its private key to Shor’s algorithm. The attacker does not need to intercept anything; the ledger is the interception.

• •

  Consensus. BLS signatures on pairing-friendly curves [43] underpin Ethereum’s beacon-chain attestations and most proof-of-stake aggregation designs. A discrete-log break forges arbitrary validator aggregates, and therefore arbitrary finality.

• •

  Proof systems. Pairing-based SNARKs (Groth16 [24] and its successors) rest on knowledge assumptions in pairing groups; a discrete-log adversary can forge proofs. Rollups, zk-bridges, and shielded pools built on them inherit the break.

• •

  Privacy. Pedersen commitments, Bulletproof range proofs, and Diffie–Hellman note encryption (Monero, Mimblewimble [34, 35], Zcash Sapling/Orchard [38]) are elliptic-curve constructions. A quantum adversary de-anonymizes and, in homomorphic-commitment designs, can counterfeit value by opening commitments to different amounts.

Grover’s algorithm [4] is the second, milder effect: a quadratic speedup for unstructured search reduces an ideal $n$-bit preimage problem to $O(2^{n/2})$ quantum work and (by the BHT collision algorithm) collisions to $O(2^{n/3})$. Hash functions and symmetric ciphers therefore survive with doubled parameters: a 256-bit hash retains roughly a $2^{128}$ quantum security margin. This asymmetry — public-key cryptanalysis breaks, symmetric/hash cryptography degrades gracefully — is the foundation of the SOS design: the protocol is built, wherever possible, from hashes alone.

The threat is not hypothetical timing speculation. The relevant decision variable, as Mosca framed it [5], is the sum of the data’s required secrecy lifetime and the system’s migration time against the adversary’s arrival time. For a base-layer monetary ledger the secrecy lifetime of a private note and the integrity lifetime of a signature are both measured in decades; the migration time of a live chain with entrenched consensus rules is measured in years to decades; and a recording adversary is already active by assumption, because recording a public chain is free (“harvest now, decrypt later” — and for signatures, “harvest now, forge later”). NIST’s standardization of ML-KEM, ML-DSA, and SLH-DSA [8, 9, 10, 6] closed the primitive-availability gap in 2024. What remains open — and what this paper addresses — is the systems gap: composing the standardized primitives into a complete ledger whose consensus, privacy, proof, and interoperability layers are all post-quantum simultaneously.

A common proposal is to retrofit an existing chain with post-quantum signatures. This addresses only the first of the four break classes above. The harder problems are systemic:

1. 1.

   Privacy does not retrofit. Confidential-transaction algebra (Pedersen blinding, kernel offsets, homomorphic balance checks) has no known post-quantum drop-in with comparable properties; a private pool must be re-designed around hash commitments and explicit zero-knowledge validity proofs, and those proofs must themselves be post-quantum (transparent, hash-based), not pairing SNARKs.

2. 2.

   Aggregation does not retrofit. Lattice signatures do not natively aggregate the way BLS does. Every consensus, light-client, and bridge design that silently assumes “$n$ signatures compress to one” must be re-architected. Section 8 treats this as a first-class protocol problem with measured engineering answers rather than an afterthought.

3. 3.

   Bridges are the weakest boundary. A bridge inherits the weaker of its two endpoint assumptions plus everything in between (multisig custodians, committee oracles, pairing-based light clients). A post-quantum chain bridged by a pre-quantum multisig is not post-quantum in any meaningful end-to-end sense. SOS therefore makes the bridge a proof system (Section 7) and confines residual pre-quantum verification to the counterparty chain’s own side of the boundary.

4. 4.

   Verification economics change. Post-quantum signatures are an order of magnitude larger than ECDSA (an ML-DSA-65 signature is 3309 bytes; a public key is 1952 bytes). Block formats, quorum certificates, light clients, and gossip budgets must be designed for these sizes from the start (Sections 4, 8).

SOS’s thesis is that post-quantum security is a whole-system invariant, established by construction and policed at every boundary, rather than a property of any single primitive.

The entire protocol follows one rule, stated here informally and made precise in Definition 2.3:

Every security-bearing primitive on the SOS side of every trust boundary is post-quantum. Non-post-quantum cryptography is confined to enumerated external-chain compatibility modules at the Ethereum boundary, where the counterparty chain’s verifier dictates the primitive.

Concretely, the permitted non-PQ modules are exactly two: (i) the pairing-based (Groth16/BN254) seal into which the SOS$\to$Ethereum bridge STARK is wrapped, because an Ethereum contract can verify a pairing check in a few hundred thousand gas but not a multi-megabyte FRI transcript; and (ii) the BLS12-381 signature verification inside the Ethereum$\to$SOS light client, because Ethereum’s own sync-committee protocol [44] signs with BLS. Both verify statements about or for Ethereum; neither is load-bearing for the SOS ledger, consensus, or shielded pool. A corollary enforced in the implementation is that SOS-internal verifiers must accept only bare hash-based STARK receipts and never a pairing-wrapped receipt (Section 10.3 discusses the enforcement status).

This paper makes the following contributions. Each is developed in a dedicated section with definitions, exact constructions, and security arguments; the status tags are defined in Section 1.5.

1. 1.

   A coherent, fully post-quantum L1 protocol stack [IMPLEMENTED, TESTNET-VALIDATED] (Sections 2–4): ML-DSA-65 for every signature including consensus votes; SHAKE-256/SHA3-256 for every hash, commitment, nullifier, and Merkle node with a global domain-separation registry (Appendix B); ML-KEM-1024 plus a SHAKE-256-KDF AEAD for note encryption; and bare hash-based STARKs for all succinct proofs the SOS network verifies.

2. 2.

   A zkVM-verifiable two-phase BFT proof-of-stake consensus [IMPLEMENTED, TESTNET-VALIDATED] (Section 4): Tendermint-lineage two-phase locking (lockedValue/lockedRound, polka-gated unlock), strictly stake-weighted $>\!2/3$ quorum certificates of raw ML-DSA-65 signatures over a fixed 58-byte vote preimage, $f{+}1$ round synchronization, QC-gated catch-up, and a v4 block-hash preimage that binds chain_id, epoch, and the validator-set hash into the very hash the quorum signs — the property the bridge and light clients rely on.

3. 3.

   PQ-MWEB [IMPLEMENTED] (Section 6): an opt-in shielded extension-block ledger re-derived from MWEB’s deployment model [36] and Zerocash-style accounting [37] with no elliptic-curve algebra: hash-only ownership-welded commitments (commit_v3 binding $\mathit{npk}=H(\mathit{nk}\,\|\,\mathit{ak})$), position-bound nullifiers, a depth-32 SHAKE-256 commitment tree with a 256-root anchor window, ML-KEM-1024-sealed notes with one-byte view tags, per-action client-side STARKs with journal-as-truth verification, and binding of the entire pool state into the consensus application state root.

4. 4.

   A proof-based, non-custodial bidirectional SOS–Ethereum bridge (Section 7): for SOS$\to$Ethereum, an in-zkVM verification of a real FIPS-204 stake-weighted quorum certificate ($\approx$5.87M zkVM cycles per signature, measured), composed with Merkle transaction-inclusion proofs in a batch guest whose committed journal is the exact ABI encoding that the on-chain SOSBridge contract reconstructs and verifies against a pinned, immutable program identity; for Ethereum$\to$SOS, a finality and execution-storage proof that extracts the wSOS burn under verified sync-committee roots. Both directions, the unattended relayer, and a public validator-set rotation from $V_{0}$ to $V_{1}$ have been demonstrated end-to-end against live Ethereum Sepolia with real proofs [IMPLEMENTED]; sustained cross-chain load/chaos exercise and external review remain [IN PROGRESS].

5. 5.

   Proof-Carrying Finality and a measured acceleration program (Section 8): a quantified analysis of the post-quantum quorum-certificate size problem, with negative results (committee sampling diverges as the Byzantine fraction approaches $1/3$; algebraic batch verification of distinct-signer ML-DSA is structurally unavailable; current lattice multi-signatures are not adoptable), a bounded-validator launch posture, an epoch-checkpoint finality certificate reusing the consensus STARK [IMPLEMENTED], measured zkVM acceleration levers (keccak accelerator, key-decode caching, multi-GPU shard composition) [MEASURED PROTOTYPE], and a native ML-DSA verification AIR prototype whose two feasibility kill-criteria both passed with measured data [MEASURED PROTOTYPE].

6. 6.

   A native, bit-exact FIPS-204 verification AIR with a measured in-zkVM re-verification crossover [MEASURED PROTOTYPE] (Section 9): to our knowledge the first AIR family that arithmetizes measured cores of unmodified FIPS-204 verification — a fully range-checked mod-$q$ multiplication gadget and the complete 8-layer forward NTT, bit-exact against the reference implementation — in a transparent, hash-based FRI STARK, together with a wrap-not-replace integration in which a thin zkVM guest verifies the native proof in software and journal-commits the result, leaving the recursion pipeline and the on-chain verifier untouched. Both pre-registered feasibility kill-criteria were retired with measurements: one NTT proves at $\approx 2\%$ of a full in-zkVM ML-DSA-65 verification budget, and the in-guest verification of the native proof costs $174.1$M cycles ($K^{\ast}\approx 47$), clearing the realistic 67–128-signature quorum size. This is a measured research prototype with an explicit remaining program, not a deployed consensus primitive.

7. 7.

   An explicit threat model and TCB inventory (Section 10): security claims with reductions to the stated assumptions, an enumeration of every trust boundary including the proof system’s circuit TCB, and a list of known limitations stated against the actual code rather than the intended design.

A whitepaper for an unlaunched system has an obligation not to blur design intent with deployed fact. Throughout this paper every load-bearing component carries one of four tags:

• •

  [IMPLEMENTED, TESTNET-VALIDATED] — implemented in the codebase and exercised on a multi-node testnet under load and adversarial (chaos) conditions.

• •

  [IMPLEMENTED] — implemented in the codebase with passing unit and integration tests, not yet exercised by the full multi-node harness.

• •

  [IN PROGRESS] — partially implemented; the remaining work is plumbing or integration, not open cryptography. The text states exactly what exists and what is missing.

• •

  [RESEARCH] / [MEASURED PROTOTYPE] — a research track; [MEASURED PROTOTYPE] indicates the prototype exists and the numbers quoted are measurements, not estimates.

Three global caveats apply. First, the system is pre-mainnet and has not had an external security audit; an internal adversarial audit program exists and its findings (several of which materially changed the design, e.g. the ownership-welding of Section 6.3) are folded into this paper. Second, all performance figures are from the stated lab hardware and are reproducible measurements, but they are not mainnet-scale benchmarks. Third, where the live deployment or operating model lags the implemented cryptography (notably independent operators and mainnet bridge migration, Section 7.8), the paper says so explicitly.

Section 2 fixes notation, defines the primitives, and states the assumptions. Section 3 gives the system architecture. Section 4 specifies consensus and proves its safety. Section 5 specifies monetary policy, the genesis distribution, and staking. Section 6 specifies PQ-MWEB. Section 7 specifies the Ethereum bridge in both directions. Section 8 presents the scalability analysis, PCF, and the measured acceleration stack. Section 9 develops the native FIPS-204 verification AIR — architecture, gadget-level soundness arguments, the in-guest verifier, and the measured crossover — as a dedicated contribution. Section 10 gives the threat model and security analysis. Section 11 surveys related work. Appendices A–C collect the canonical byte layouts with RFC-style wire-format diagrams, the domain-tag registry, and the parameter tables.

All byte strings are finite sequences over $\{0,1\}^{8}$; $\,\|\,$ denotes concatenation. $\mathrm{LE}_{k}(x)$ denotes the $k$-byte little-endian encoding of the unsigned integer $x$; the implementation uses little-endian encodings in all SOS-native preimages and big-endian 32-byte words only inside the Ethereum-ABI journal (Section 7.2.4), matching Solidity’s abi.encode.

For a fixed ASCII domain tag $D$ we write

where $\mathrm{SHAKE256}_{\ell}$ denotes $\ell$ bytes of SHAKE-256 output. Domain tags are versioned constants (e.g. sos:note-commit:v3, bqp:block:v4); the registry in Appendix B lists every tag in the protocol, and the implementation rule is that a tag is never reused across purposes and never changed without a version bump and an activation height. Two tag namespaces coexist for historical reasons: bqp: (the project’s original codename) and sos:; both are consensus-frozen byte constants and the namespace carries no semantic distinction.

Validator voting power is denominated in stake (Section 5.7); a quorum is any validator set whose summed effective stake is strictly greater than $2/3$ of the total active effective stake. Amounts are integers in sats, $10^{-8}$ SOS.

ML-DSA-65 is the module-lattice digital signature standard [9] derived from CRYSTALS-Dilithium [11], instantiated at NIST security category 3. Its EUF-CMA security reduces to the Module-LWE and Module-SIS problems over power-of-two cyclotomic rings; no polynomial-time quantum algorithm is known for either, and the parameter set targets a classical/quantum security level comparable to AES-192. The concrete sizes that shape the SOS protocol are:

SOS uses ML-DSA-65 in its pure (non-pre-hash) mode with the empty context string: the signed message is the raw preimage defined by the protocol (e.g. the 58-byte vote preimage of Construction 4.3). This choice is consensus-critical — the zkVM consensus guest (Section 7.2.1) re-verifies the same bytes with the same FIPS-204 Verify algorithm, and any host/guest divergence in message formatting is a soundness break, so a single shared library defines every preimage on both sides. One ML-DSA-65 verification costs approximately $5.87$ million RISC-V cycles inside the zkVM used (measured; Section 8.5).

ML-KEM-1024 is the module-lattice key-encapsulation standard [8] derived from CRYSTALS-Kyber [12], instantiated at category 5 (the most conservative parameter set; ciphertext 1568 bytes, encapsulation key 1568 bytes, 32-byte shared secret). SOS uses it solely for note encryption in the shielded pool: each note is sealed under a fresh encapsulation against the recipient’s registered KEM key (Section 6.4), so note confidentiality is protected against a harvest-now-decrypt-later adversary for the lifetime of the Module-LWE assumption rather than the lifetime of an elliptic curve.

SHA3-256 and SHAKE-256 are the FIPS-202 [7] sponge constructions over Keccak-$f[1600]$. SOS uses SHA3-256 (fixed 32-byte output) for block hashes, transaction hashes, validator identities, and the bridge journal digest’s inner components, and SHAKE-256 (XOF, squeezed to 32 bytes unless stated) for the entire note scheme and key-derivation paths. Against a quantum adversary, Grover’s algorithm bounds preimage search at $\Theta(2^{128})$ work for 32-byte outputs and the BHT algorithm bounds collisions at $\Theta(2^{85})$ query complexity (with classical collision search at $2^{128}$); both are regarded as out of reach, and the sponge’s indifferentiability supports the domain-separation methodology of Section 2.1.

Note plaintexts are encrypted under ChaCha20-Poly1305 [13] with a key and nonce derived by SHAKE-256 from the ML-KEM-1024 shared secret (Section 6.4). Symmetric AEAD security degrades only by Grover’s quadratic factor (effective $\geq 2^{128}$ for the 256-bit key); ChaCha20 is chosen over AES-GCM for constant-time software performance in no_std and WASM wallet environments, with no reliance on hardware AES.

This is deliberately the weakest, most conservative commitment in the design space. Compared with algebraic (Pedersen-style) commitments it sacrifices additive homomorphism — so balance checks must be performed inside a zero-knowledge proof by explicit checked arithmetic (Section 6.5) — and gains two properties SOS considers decisive: post-quantum security, and the absence of any algebraic structure that an under-constrained circuit could exploit to counterfeit value, the bug class that has repeatedly affected algebraic shielded-pool designs.

A STARK [15] is a succinct, transparent argument of computational integrity compiled from an interactive oracle proof [17] whose low-degree testing uses FRI [16] and whose only cryptographic ingredient is a collision-resistant hash (for Merkle commitments and the Fiat–Shamir transform). Transparency means there is no trusted setup and no structured reference string; soundness rests on Assumption 3 plus the proximity soundness of FRI. In the quantum random-oracle model, hash-based IOP compilations of this family admit security proofs [19]; accordingly STARKs are regarded as plausibly post-quantum, in contrast to pairing-based SNARKs. We state the working assumption explicitly:

The RISC Zero zkVM proves correct execution of an arbitrary RISC-V (rv32im) program, called a guest. Three of its interfaces are load-bearing for SOS:

• •

  Receipts and journals. The prover emits a receipt containing a seal (the STARK) and a journal (the public outputs the guest committed via env::commit). A verifier checks the receipt against an image id — a 32-byte digest of the guest program binary — and then trusts the journal as the program’s authentic output. The image id is therefore part of consensus: SOS pins every guest’s image id as a compile-time constant, with CI tests that fail on any drift (Sections 7.2.3 and 10.3).

• •

  Recursive composition. A guest may call env::verify(image_id, journal) to assert that a valid receipt exists for another program with exactly that journal; the host supplies the inner receipt as an assumption and the recursion circuit discharges it. This is how the bridge folds a consensus proof and $n$ inclusion proofs into one receipt (Section 7.2.3).

• •

  Receipt kinds. The same proof can be emitted as a bare hash-based STARK receipt (composite or succinct) or wrapped into a Groth16 proof over BN254 for cheap on-chain verification. SOS’s discipline maps onto this directly: every SOS-internal verifier consumes the bare STARK; only the Ethereum-facing relayer produces the Groth16 wrap, and only the Ethereum contract verifies it (Sections 7.4, 10.3).

SOS is implemented in Rust as a single node binary exposing a JSON-RPC interface to wallets, explorers, and tooling. One binary serves every role; roles are configuration, not separate software (the “model C” decision: every node validates; proving and relaying are opt-in modules, and a GPU is never required to validate). The node’s event loop drives four cooperating subsystems:

• •

  the consensus reactor: the two-phase BFT state machine of Section 4 — proposal handling, vote tallies, locking, round synchronization, QC construction and verification, and the catch-up buffer;

• •

  the chain state machine: applies finalized blocks; maintains the transparent UTXO set, the shielded pool (commitment tree, nullifier set, anchor window), the validator and staking state, and the supply tracker; computes the chained application state root app_hash (Section 3.3);

• •

  the extension-block builder: constructs and applies the private actions (shield, unshield, private transfer) of Section 6, enforcing journal-as-truth verification;

• •

  the mempool: admission, fee policy, and content-key deduplication (a canonical key over the action type, sender, amount, and burn identifier prevents duplicate logical actions from racing into blocks).

• •

  Validators hold bonded stake and an ML-DSA-65 consensus key, run the full state machine, and vote. Validation is CPU-only by design.

• •

  Full/RPC nodes follow consensus (verifying every block’s QC), maintain full state, and serve wallets; they do not vote.

• •

  Light clients verify finality without state: given a block header and its embedded QC, a light client checks the stake-weighted ML-DSA-65 quorum against the known validator set (verify_qc), with no ledger replay. Mobile wallets are light clients; a phone is never a validator (availability and slashing, not compute, are the binding constraints). The PCF certificate of Section 8.4 is designed to replace per-block QC downloads with one constant-size STARK check per epoch.

• •

  Privacy provers are the users themselves: every private action is proved client-side, because the spend witness contains the secret nullifier key $\mathit{nk}$ whose disclosure delegates spend authority (Section 6.7). The wallet talks to the user’s own GPU-equipped prover (a hardened TLS service is provided) or proves locally. A prover that receives $\mathit{nk}$ must be treated as part of the user’s trust boundary. Private transfer (private$\to$private) submission is now implemented with an ML-DSA-65 spend authorization inside the privacy STARK: the signed digest binds the chain id, expiry height, anchor, nullifiers, output commitments, output-ciphertext hashes, and fee. This prevents a node or prover from substituting different public effects for an accepted transfer, but it does not make third-party spend proving witness-private: delegated proving by an untrusted service remains outside the security claim.

• •

  Bridge provers and relayers are opt-in, permissionless, fee-compensated roles: the prover produces the recursive bridge STARK, the relayer wraps and submits it to Ethereum. Neither is trusted: a bad proof is rejected by the contract; liveness of these roles is an availability assumption, never a safety one.

A transaction is transparent by default — a UTXO transfer authorized by an ML-DSA-65 signature — or private, routed through the extension block (shield, private transfer, unshield). Every finalized block commits to the post-state via the chained app_hash: a SHA3-256 digest over canonical encodings of (i) the UTXO set root, (ii) the contents of the shielded pool — note commitments, the commitment-tree root, the nullifier set, and the rolling anchor window (domain bqp:private-pool:v4) — (iii) the supply tracker including the bridge-locked bucket, and (iv) the validator and staking state including jailing flags. Two nodes with equal app_hash at equal height have byte-identical application state. The block hash that validators sign binds prev_app_hash (Section 4.2), so a proposer that built on divergent state is rejected at apply time, and — after the audit finding discussed in Section 6.6 — every shielded-pool change is inside the quorum-signed perimeter.

A node ships with no required network configuration. On first start it bootstraps from baked-in DNS seeds, discovers peers over the public internet, and backfills the chain via a peer-to-peer block-sync protocol whose every received block is admitted only through the same verified apply path as live consensus (block-hash and QC verification, application against the prior app_hash), so a syncing node cannot be fed an invalid history. This has been verified on the live public testnet: a fresh, unconfigured node joined from the DNS seed, synced the chain from height zero, and its block hashes matched the live chain bit-for-bit. The July 2026 fresh public testnet also exposes its public P2P ingress on TCP 30303 through seed, seed1, seed2, seed3, and dnsseed.soulofsatoshi.com; all five records resolve to the same current seed while the names remain independently rotatable. An external smoke test that pinned the expected seed peer id (and therefore ignored unrelated mDNS peers) completed the DNS-resolved libp2p handshake. DNS publication is an operations property, not part of the consensus safety argument. Local peer discovery (mDNS) and explicit --boot-nodes remain available for private or lab deployments. [IMPLEMENTED, TESTNET-VALIDATED]

A validator is registered through a staking transaction carrying its 1952-byte ML-DSA-65 consensus_pk. Its identity is $\mathit{id}=H_{\texttt{bqp:validator-pk:v1}}(\texttt{consensus\_pk})$, and its voting power is its effective stake

the sum of the operator’s own bond and all delegations (Section 5.7). The active pool at a height is the set of registered validators that are neither jailed nor pending, ordered canonically by (effective stake descending, id ascending); this canonical order is consensus-critical because the validator-set hash (Construction 4.2) is order-sensitive. Dynamic join is supported: a new validator’s bond enters a pending state and activates at a scheduled activation height, at which point membership flips deterministically across all nodes within the same block (and is bound into that block’s app_hash), so the active set and the quorum denominator change simultaneously everywhere. Voluntary exit is implemented as a consensus-key-authorized transaction. The removal height is derived as the carrying block height plus ten blocks; until that boundary the validator continues to vote and count in the denominator, then every node removes it simultaneously and binds the change into app_hash. Self-bond and third-party delegations enter the 21-day unbonding queue of Section 5.7. An exit is rejected if it would leave fewer than four active validators. The protocol supports a registered pool of up to $200$ validators and bounds proposer eligibility to the top $64$ by effective stake; these limits sit within the bounded-active-set posture of Section 8.3 ($N\leq 128$ active consensus participants).

The v4 binding deserves emphasis because it is the hinge of the bridge’s security argument. Because the quorum certificate consists of signatures over block_hash, folding chain_id, $e$, and $V$ into the hash makes the quorum cryptographically attest three statements that a verifier holding only the QC (a light client, or the zkVM guest) could otherwise not establish: that the block belongs to this chain and not a testnet or fork (anti-replay across chains); that it belongs to the claimed epoch (anti-replay across validator-set generations); and which validator set is canonical at this height — so a prover cannot present a quorum of signatures checked against a substitute validator set of its own choosing (Section 7.3). Binding prev_app_hash chains the application state: a proposer that built on divergent state produces a hash no honest validator will sign, and a syncing node rejects a block whose claimed parent root disagrees with its own.

Every field exists to kill a replay class, and each was motivated by a concrete defect found in an earlier iteration of the live path: the domain tag separates vote signatures from block-proposer signatures made with the same key (previously a proposer’s block signature was byte-identical to a vote); the chain-id field makes even nil votes non-replayable across forks or testnets; the height and round bind the vote to its position (previously a nil vote signed the same 32 zero bytes at every height — free equivocation material); the phase byte makes a prevote signature unusable as a precommit, so a quorum certificate (which is a precommit-domain object) cannot be assembled from prevotes; and the nil byte separates “no value” from a vote for a value. A single shared function constructs this preimage at every signing site, at the node’s verification site, and in the zkVM guests; its layout is pinned by byte-offset tests on both sides and rendered in Figure 6.

Each height $h$ proceeds in rounds $r=0,1,2,\dots$; each round has three steps: propose, prevote, precommit. The round-$r$ proposer is selected deterministically and proportionally to effective stake from the eligible active set by the construction of Section 4.9, so all honest nodes agree on it without communication. Each node maintains the Tendermint lock state: $\mathit{lockedValue}\in\{\bot\}\cup\{0,1\}^{256}$ and $\mathit{lockedRound}\in\{-1,0,1,\dots\}$, plus $\mathit{validValue}/\mathit{validRound}$, all reset only at a new height (a new height starts unlocked; a new round preserves locks and all vote tallies).

propose.

The round’s proposer broadcasts a block (or re-proposes its locked value, attaching the round $vr$ at which that value last obtained a prevote quorum). Non-proposers wait for the proposal or a timeout.

prevote.

On a proposal for value $v$ (hash $\hat{v}\neq 0$) with valid-round $vr$, a node prevotes $\hat{v}$ iff

$$\mathit{lockedRound}=-1\;\lor\;\mathit{lockedValue}=\hat{v}\;\lor\;\big{(}vr\geq 0\,\land\,vr\geq\mathit{lockedRound}\,\land\,\mathrm{polka}(vr)=\hat{v}\big{)},$$

Visual explanationVote replay protection and lock safety31 sec

Accessible transcript

Signed bytes. Every vote signs one fixed-width, domain-separated 58-byte preimage.

Replay barriers. Chain, height, round, phase, nil flag, and block digest are all authenticated.

Local lock. A validator only changes value when its own tally proves a sufficiently recent polka.

Intersection. Strict two-thirds stake quorums intersect in honest voting power.

Security property. Honest validators cannot finalize two conflicting blocks at the same height under the stated Byzantine-stake assumption.

where $\mathrm{polka}(vr)=\hat{v}$ means the node has locally observed, in its own tally, prevotes for $\hat{v}$ at round $vr$ from validators holding strictly more than $2/3$ of total stake. The polka check is local by design: no quorum certificate attached to a proposal is trusted on the wire; the proposer’s $vr$ is only a pointer telling the node where in its own tallies to look. Note $vr\geq\mathit{lockedRound}$ (with equality unlocking) is required for liveness, and $vr<\mathit{lockedRound}$ must not unlock for safety. Otherwise the node prevotes nil.

precommit.

On observing a polka for $\hat{v}$ at the current round, the node sets $\mathit{lockedValue}\leftarrow\hat{v}$, $\mathit{lockedRound}\leftarrow r$, records $\hat{v}$ as its valid value, and precommits $\hat{v}$. Otherwise, on timeout, it precommits nil.

commit.

A block commits at a node when the node observes precommits for one non-nil $\hat{v}$ at any single round from validators holding strictly more than $2/3$ of total stake. The committing node materializes the quorum certificate (Section 4.5), applies the block, and advances to height $h+1$ unlocked.

All thresholds are stake-weighted with strict inequalities: a set $S$ of distinct validators meets the $2/3$ threshold iff $3\sum_{v\in S}\mathrm{stake}_{\mathrm{eff}}(v)>2\cdot T$ where $T$ is total active stake, and the $f{+}1$ threshold iff $3\sum_{v\in S}\mathrm{stake}_{\mathrm{eff}}(v)>T$. Duplicate voters count once; per-round anti-equivocation tracking refuses to tally two different-hash votes of the same type from one validator at one $(h,r)$ and retains both signatures as slashing evidence (Section 4.8). (For bootstrap configurations whose validators have placeholder keys, the implementation falls back to head-count thresholds; any set containing a real key uses stake weighting. This is a development convenience, not a protocol mode.)

Phase timeouts escalate linearly with the round number ($\mathit{timeout}(r)=\mathit{base}+1000\,\mathrm{ms}\cdot r$), the standard partial-synchrony device for eventually exceeding the unknown network delay.

Commit skew creates one additional delivery case: a node still applying height $h$ can receive the proposal and votes for $h{+}1$, and gossipsub need not send those messages a second time. The reactor therefore keeps a bounded, liveness-only one-height look-ahead buffer. A future proposal is not acted on early; after entering $h{+}1$ it is removed and replayed through the full proposal-validation path against the committed parent state and the epoch-frozen active set. Future votes are retained only after their ML-DSA-65 signatures verify, with a cap of $1024$ entries, and are replayed in prevote-before-precommit order through the normal signature, equivocation, quorum, and round-synchronization checks. No buffered message bypasses a safety predicate, and messages more than one height ahead are dropped. [IMPLEMENTED, TESTNET-VALIDATED]

The QC is deliberately not folded into the block hash (the votes are over the hash; including them would be circular), so attaching it never perturbs app_hash. Its role is to make finality portable: a node syncing from block data alone, a light client, and the zkVM consensus guest all run the same check against the same bytes, with no trust in the serving peer. The QC is also the protocol’s main scalability liability — one full ML-DSA-65 signature per signer — quantified and addressed in Section 8.

The cross-round case is precisely the scenario that was reproduced as a fork on an earlier, single-phase iteration of the implementation and is now closed by the lock rule; the reproduction is retained as a regression test, and an independent re-audit of the live code (June 2026) confirmed the two-phase logic and that the guest-verified preimage matches the live 58-byte precommit. [IMPLEMENTED, TESTNET-VALIDATED]

A faithful two-phase protocol is safe unconditionally, but three further mechanisms proved necessary on a real lossy network to obtain liveness; all three were added in response to observed stalls in load/chaos testing, and all three preserve the safety argument because none touches the lock rule.

• •

  $f{+}1$ round synchronization. If a node observes votes (either phase) at a round $r^{+}$ greater than its own from validators holding strictly more than $1/3$ of total stake, then at least one honest validator is at $r^{+}$ (Byzantine stake cannot reach $1/3$), so the node fast-forwards to $r^{+}$, preserving its lock and all tallies and re-entering propose. Without this rule, nodes whose timeouts fire at slightly different moments drift into different rounds and no proposal ever gathers a quorum — a livelock observed empirically under load.

• •

  QC-gated catch-up. A node that falls behind buffers out-of-order blocks and applies a buffered block only if it carries a QC that verifies under Construction 4.4; a bare gossiped proposal is never applied. Two subtle wedges in this path were found and fixed by the chaos suite: a buffered QC-less copy of a height must not suppress re-fetching a QC-bearing copy, and the buffer eviction policy must evict far-future heights rather than the next-needed one (the naive evict-lowest policy permanently wedged any node that fell more than the buffer size behind).

• •

  Consensus-envelope block budgeting. The proposer’s transaction budget is the apply-time block-size ceiling (4 MiB) minus the consensus envelope it will add: the proposer key and signature and the QC, which carries one 3309-byte signature per potential signer. A builder that counts only transaction bytes emits a block that every node rejects at apply time and then re-proposes forever — a deterministic halt observed in testing and eliminated by reserving the envelope.

Because every vote is a position-bound ML-DSA-65 signature, misbehaviour is self-evidencing: two verified precommits from the same validator at the same $(h,r)$ with different block hashes constitute complete, transferable evidence of double-signing, with no additional context needed. Evidence is applied deterministically in a later block. As implemented today, the slashable on-chain evidence path is consensus double-signing, with a $500$ bps ($5\%$) burn from the offender’s effective stake; downtime is enforced as jailing. Additional penalty constants for committee equivocation, invalid bridge batches, and downtime burns are reserved in code but are not yet wired as launch-grade evidence types. The mainnet release gate is to either wire and test those evidence paths end-to-end or keep the public economics limited to double-sign slashing plus downtime jail. [IN PROGRESS]

The round-$r$ proposer at height $h$ is selected deterministically from the top 64 validators of the canonical active pool by a stake-weighted permutation without replacement. Let $N$ be the eligible count, $c=\lfloor r/N\rfloor$, and $j=r\bmod N$. For draw $k=0,\ldots,j$, the implementation hashes u64le(h) || u32le(c) || u32le(k) under sos:weighted-proposer:v2, reduces the first 128 digest bits modulo the remaining effective stake, walks the canonical cumulative-weight intervals, selects that validator, and removes it before the next draw. If all remaining weights are zero, the same digest selects an index among them. The first draw is therefore exactly stake-proportional and splitting one stake interval does not increase its aggregate primary-proposer probability; without-replacement fallback also guarantees that no validator occupies two slots in one cycle. Consequently, if any eligible validator is online, an online proposer appears within at most $N$ rounds from the start of a height. From an arbitrary point inside a cycle the conservative bound is fewer than $2N$ rounds, because the remaining online slots may already have passed and the next independently permuted cycle may place them late. This closes the unbounded repeated-offline-proposer streak observed under the v1 independent-round lottery. Selection remains communication-free. [IMPLEMENTED]

The consensus and value path were exercised on a four-node local testnet driven by a load/chaos harness, with a 200 ms consensus tick. Headline results (all [IMPLEMENTED, TESTNET-VALIDATED]): hundreds of concurrent transparent transfers commit with zero supply drift and byte-identical app_hash across nodes; a double-spend race (the same funds raced to two recipients via two nodes) settles exactly one output, never both; killing more than $1/3$ of stake halts the chain without forking and restoring quorum resumes it; floods of invalid and overspending transactions are rejected without a node panic; a reproduced cross-round fork scenario is closed by the lock rule (regression-tested); a $2$–$2$ sub-quorum vote split that livelocks a single-phase design converges; and the happy path commits in approximately $600$ ms per block. On the July 2026 fresh public testnet, a three-validator deployment finalizes with $3/3$ precommits and a measured interval still around the sub-second range; because this is a small co-located deployment, it is not directly comparable to the four-node chaos latency above. The validators first completed a one-at-a-time rollout of a pure --no-default-features --features verify-only binary. Activating the consensus-visible proposer-v2 schedule then used a coordinated stop/install/start on all three validators, without replacing or copying a data directory. The nodes had stopped at height 35642 with a v1 vote already persisted for 35643; the vote WAL refused a conflicting re-sign after restart, synchronized that already-finalized block, and made height 35644 the first full proposer-v2 height. The active binary has SHA-256 9f58f038…8789b; all three independently reported height 35732, block hash a04c61bb…b2d2c0, and application hash 2529c923…ead8a. Expected and actual supply both remained $210{,}000{,}000{,}000{,}000$ sats. Stopping node 0 caused the public HTTPS RPC to serve the finalized chain through a backup validator in 321 ms; node 0 then restarted and all three reconverged at height 35823. Separately, a clean deterministic proposer-v2 four-validator-plus-observer chaos run lasted 723.5 s, made 720 invariant checks, injected 22 kill/restart/partition/delay/flood events, accepted 1,489 mixed transfer/stake/undelegate operations, and ended at height 113 with no fork, state divergence, supply drift, or liveness violation. The genesis slot_time_secs of $5$ is a nominal parameter that the current reactor does not enforce as a block interval: block production is tick-driven at $200$ ms and paced by quorum formation, while the $\approx 5$ s timeouts in the reactor are round/view-change timeouts that bound a round before a view change, not the inter-block time. These are functional and adversarial results on small networks, not throughput claims.

The unit of account is the SOS; amounts are integers in sats ($1\,\mathrm{SOS}=10^{8}$ sats). The hard supply cap is

deliberately echoing Bitcoin [1]. The cap is not a social convention: it is enforced every block by the supply invariant of Section 5.6, whose violation halts the node.

The launch genesis (genesis-v2, chain id 0x534F53) mints a fixed genesis supply of $2{,}100{,}000$ SOS — exactly $10\%$ of the $21{,}000{,}000$ cap — and leaves the remaining $18{,}900{,}000$ SOS ($90\%$) in an emission pool issued over time by the bounded emission of Section 5.5. The genesis supply is partitioned into six categories, each with an explicit on-chain vesting schedule in epochs of $7$ days; every figure below is taken directly from the authoritative genesis file and is reconciled against the supply invariant (Invariant 5.2) from block zero. [IMPLEMENTED, TESTNET-VALIDATED]

Vesting is linear per epoch after an optional cliff and is tracked on-chain, so an account’s spendable balance at epoch $t$ is its genesis-liquid amount plus the matured fraction of its scheduled total. Two categories carry liquid supply at block zero — the liquidity allocation (fully liquid) and part of the airdrop allocation — totalling $210{,}000$ SOS; a further $40{,}000$ SOS is bonded at genesis as the self-bond of the initial validators, and the remaining $1{,}850{,}000$ SOS is vesting-locked.¹¹1For the team and treasury categories the total exceeds the vesting-schedule total by $20{,}000$ SOS each; that $40{,}000$ SOS is the genesis validators’ self-bond (each of the four initial validators self-bonds $10{,}000$ SOS, two funded from team and two from treasury), which is staked rather than placed on the linear release. The July 2026 fresh public testnet used for the privacy round-trip rehearsal runs three active validators; the published genesis-v2 allocation defines four.

The project also implements the tooling for a post-quantum Merkle-drop used by the beta-testing campaign [IN PROGRESS]: contribution-weighted allocations are computed off-chain and committed as a single Merkle root with domain-separated SHA3-256 hashing (leaf $=H_{\texttt{sos:airdrop-leaf:v1}}(\mathit{address}\,\|\,\texttt{":"}\,\|\,\mathit{amount})$, node $=H_{\texttt{sos:airdrop-node:v1}}(\mathit{left}\,\|\,\mathit{right})$, leaves sorted by address, odd nodes promoted), and a claim binds an ML-DSA-65 signature over $H_{\texttt{sos:airdrop-claim:v1}}(\mathit{address}\,\|\,\texttt{":"}\,\|\,\mathit{amount}\,\|\,\texttt{":"}\,\|\,\mathit{root})$. The campaign computation, root construction, and proof serving are implemented in the campaign application; the on-chain verification of airdrop Merkle paths in the node is in progress. The authoritative genesis allocation for genesis-v2 is the table above; the Merkle-drop is an optional distribution mechanism whose activation is a launch parameter of any future genesis.

Each category’s genesis allocation unlocks on the schedule of the allocation table: a cliff of $c$ epochs delays the start of a linear release over the following $\ell$ epochs, so the matured fraction of a scheduled total at epoch $t$ is $\mathrm{clamp}\big{(}(t-c)/\ell,\,0,\,1\big{)}$ (liquidity is fully liquid at genesis; the airdrop carries $52{,}500$ SOS liquid at genesis plus a scheduled $157{,}500$ SOS). The circulating, non-vesting-locked supply at time $t$ is the genesis-liquid $210{,}000$ SOS, plus the $40{,}000$ SOS initial validator self-bond (active stake), plus matured vesting, plus emission issued to date — equivalently, total issued minus the still-locked vesting balance, so the projection reconciles to Invariant 5.2 exactly. Table 2 samples it at year boundaries ($52$ epochs/yr). [IMPLEMENTED, TESTNET-VALIDATED]

Validator and delegator incentives are funded by transaction fees plus a bounded, cap-respecting emission [IMPLEMENTED]:

• •

  Emission proceeds at $210{,}000$ SOS per year, divided into $7$-day epochs ($52$ per year; $403{,}846{,}153{,}846$ sats, approximately $4038.46$ SOS, per epoch).

• •

  Emission continues only while $\textsf{issued}<\textsf{SUPPLY\_CAP}$; the final epoch’s emission is truncated to land exactly on the cap, after which emission ceases permanently. With the $18{,}900{,}000$ SOS emission pool released at the fixed annual rate, the emission horizon is approximately $90$ years.

• •

  Each epoch’s emission is split $70/20/10$: $70\%$ to stakers pro rata by effective stake, $20\%$ to operators pro rata by blocks proposed in the epoch, and $10\%$ to the treasury. Fee revenue collected during the epoch is distributed alongside emission through the same channels.

• •

  A fixed $30\%$ of every transaction fee is burned (fee_burn_bps $=3000$) rather than distributed, so fee pressure is deflationary against the cap; the burn flows through the burned term of Invariant 5.2.

Every boundary crossing (shield, unshield, bond, unbond, bridge lock, bridge release, slash-burn, fee flow) is routed through tracker transitions that preserve the equation, and finalize_block re-verifies it before computing app_hash. On violation, a release-build node logs the divergence and aborts the process before persisting or propagating state (the abort is unconditional — not a catchable panic), so a node whose accounting has diverged can never silently extend a corrupt chain; because app_hash binds the supply tracker, such a node is by definition already off-consensus and restarts from its last flushed good state. [IMPLEMENTED, TESTNET-VALIDATED]

Stake is bonded to a validator either as the operator’s self-bond or as a delegation; effective stake is their sum and is the unit of voting power, reward weighting, and slashing exposure. Unbonding enters a queue with a $21$-day maturity; entries in the queue remain slashable for offences committed while bonded (Section 4.8) and count in the unbonding bucket of Invariant 5.2. Validator membership changes (join with pending activation, jailing, unjailing) are deterministic state transitions bound into app_hash, so the quorum denominator can never differ between honest nodes at the same height. Delegation records, reward accrual, and the unbonding queue are persisted and snapshotted with the rest of the chain state. [IMPLEMENTED]

A fixed $10\%$ of annual emission (line 1514) is allocated to the treasury, accumulating in a separately tracked SOS account. The governance mechanism for treasury spending is currently under definition and is a pre-mainnet decision point. Two candidate architectures are being evaluated: (i) ML-DSA-65 voting, in which treasury spending is authorized by a fixed set of multisig keyholders (e.g., protocol developers, ecosystem participants) whose ML-DSA-65 signatures are verified by the blockchain itself, achieving full post-quantum consistency with the protocol layer; (ii) Soft-governance via fork-choice, in which spending is proposed as a transaction and the validator community signals acceptance by their block-proposal choices, with rejection triggering a hard-fork. The former is simpler to audit but requires managing a multisig key set; the latter avoids key custody but distributes governance implicitly. In the interim, the treasury account exists on-chain with no spending authorization implemented, so accumulated SOS remains locked. This is a known limitation (Section 10.5) and must be resolved before mainnet; the choice will be disclosed in the genesis release notes.

Two failure classes drove the scheme’s central decision. The first is the quantum break of Section 1.1: elliptic-curve commitments and DH note encryption are retroactively de-anonymizable, and homomorphic value commitments are retroactively counterfeitable. The second is classical: algebraic shielded-pool designs have repeatedly suffered under-constrained-circuit bugs in which a missing constraint on algebraic structure allowed counterfeiting. A scheme in which every binding is a domain-separated SHAKE-256 hash of fixed-width fields has no algebraic structure to under-constrain: every attack on the note scheme reduces to a preimage, second-preimage, or collision attack on SHAKE-256 (Assumption 3). The cost is the loss of homomorphism — conservation of value must be proven by explicit checked integer arithmetic inside the proof — which the per-action STARK absorbs (Section 6.5).

The scheme is implemented as a single no_std library (btp-note-core) compiled identically into three execution environments — the node (x86-64), the zkVM guest (rv32im), and the wallet (WASM) — so host, circuit, and client compute byte-identical commitments by construction, and golden-vector tests pin the bytes as consensus law.

The position binding in $\mathit{nf}$ makes nullifiers unique per leaf even if two notes were ever created with identical $\rho$; the inclusion of $\rho$ (committed inside $\mathit{cm}$) fixes a note’s nullifier at creation time; and the inclusion of $\mathit{nk}$ makes computing $\mathit{nf}$ — hence spending — impossible without the secret key (Definition 2.2).

Two counterfeiting vectors, found by the project’s internal adversarial review of an earlier design, dictate the exact shape of Construction 6.2; we state them because they generalize to any hash-based shielded pool.

Vector 1: spend-authority decoupling. If the commitment binds only public data (say $\mathit{ak}$) and the nullifier binds the secret $\mathit{nk}$, with nothing tying the two together, then a proof system that checks “$\mathit{cm}$ is in the tree” and “$\mathit{nf}$ is correctly formed from some $\mathit{nk}$” accepts a spend by anyone who knows the note’s plaintext — ownership reduces to data possession, not key possession. The fix is the weld: $\mathit{cm}$ commits to $\mathit{npk}=S(\mathit{nk}\,\|\,\mathit{ak})$, and the spend circuit takes $\mathit{nk}$ (never $\mathit{npk}$) as witness, re-derives $\mathit{npk}$ in-circuit, rebuilds $\mathit{cm}$, and proves Merkle inclusion of that rebuilt $\mathit{cm}$. A valid spend therefore forces knowledge of the very $\mathit{nk}$ that also (in the same circuit) produces the nullifier. Binding $\mathit{ak}$ inside $\mathit{npk}$ additionally prevents mixing a victim’s $\mathit{ak}$ with an attacker’s $\mathit{nk}$.

Vector 2: recipient-authority gap. The sender authors the recipient’s output note and could choose $\mathit{npk}$ freely — e.g. set $\mathit{npk}=S(\mathit{nk}_{\mathrm{attacker}}\,\|\,\cdot)$, encrypt the note to the recipient, and retain spend power over a note the recipient believes is theirs. The fix is to make $\mathit{npk}$ part of the recipient’s address (Construction 6.1) and to require the scanning wallet to accept a note as received only after (i) re-deriving $\mathit{npk}\stackrel{{\scriptstyle?}}{{=}}S_{\texttt{sos:npk:v1}}(\mathit{nk}_{\mathrm{self}}\,\|\,\mathit{ak}_{\mathrm{self}})$ and (ii) recomputing the full $\mathit{cm}$ from the decrypted plaintext and matching it against the on-chain commitment. A note whose $\mathit{npk}$ is not the recipient’s is provably not theirs and is ignored.

Binding the AEAD’s associated data to $\mathit{cm}$ ensures a ciphertext cannot be re-attached to a different note. Scanning (scanMyNotes) decapsulates each candidate blob with the wallet’s KEM secret, derives the key material, and compares the one-byte view tag before attempting the AEAD decryption and commitment recomputation: the tag rejects $\approx 255/256$ of foreign notes after the (unavoidable) decapsulation but before the more expensive steps. Acceptance requires the AEAD tag to verify and the recomputed commit_v3 to equal the on-chain commitment and the recipient-authority check of Section 6.3. Fresh encapsulation per note provides forward unlinkability across notes; KEM keys are registered on-chain via a consensus-visible registration transaction. Confidentiality of every note recorded today rests on Assumption 2 — this is the harvest-now-decrypt-later guarantee.

Each private action carries a STARK receipt from a single pinned guest program; the action is selected by the witness type and echoed in the journal. The journal type (fixed across host, guest, and verifier) is

Let $\mathrm{MAX}=2^{51}$. The three proven relations are:

A shielded pool is only as sound as its binding to consensus. An internal audit of an earlier iteration found the decisive gap: the then-current voted block hash bound nothing about the pool, so validators could finalize blocks while disagreeing about (or ignoring) the private state. The remedy is structural and now part of the definition of finality: the extension block’s contents are committed by ext_root, which is inside the v4 block hash (Construction 4.1) that every vote signs; and the pool’s full contents — commitments, tree root, nullifier set, anchor window, and the reserve bucket — are folded into app_hash, which the next block’s signed hash chains via prev_app_hash. Finality of a block therefore certifies the private state transition, not merely the transparent ledger. The supply turnstile (Invariant 5.2) closes the loop in value terms: the reserve bucket must always equal the value absorbed by the pool, so even a hypothetical circuit defect cannot silently inflate transparent supply without tripping the per-block invariant.

The wallet proves; the node only verifies. This is not merely an engineering preference — it is forced by ownership: the spend witness contains $\mathit{nk}$, whose holder can spend every note of that authority, so handing the witness to a shared proving service is equivalent to custody. The deployment model is therefore:

• •

  Shield witnesses contain only the new note’s randomness (no spend authority); delegating a shield proof leaks at most that note’s amount.

• •

  Spends are proved on hardware the user controls. Unshield binds the recipient, amount, and fee by an ML-DSA-65 authorization checked by the node. Private transfer binds its public effects by an ML-DSA-65 spend authorization verified inside the STARK: nullifiers, outputs, ciphertext hashes, anchor, fee, chain id, and expiry height are all signed. The implementation ships a hardened prover service (TLS 1.3 only, bearer authentication, witness never logged, core dumps disabled, loopback-only unless explicitly configured otherwise) that a browser or mobile wallet calls over the user’s own machine; the wallet computes all commitments and encryption in WASM and sends only the proving witness.

• •

  Trustless delegated spend-proving for phone-only users (witness-private delegation) is an open problem [RESEARCH]; SOS does not claim it.

Measured proving costs for the smallest action (shield; one commit_v3 and range checks): $\approx 0.70$ s on a single consumer GPU (RTX 5090 laptop, CUDA, $\approx 4.4$ GiB VRAM), $6.3$ s on CPU (release build). Spend proofs add the 32-level Merkle path and are correspondingly heavier but remain in the interactive range on consumer GPUs. Verification on the node is tens of milliseconds and is the only privacy cost on the consensus hot path; block time is therefore decoupled from proving time. [MEASURED PROTOTYPE]

The scheme provides object-level confidentiality — amounts, identities, and linkage inside the pool are hidden behind Assumptions 3–4 and 2 — and integrity for enabled actions (no inflation, no double-spend, no foreign unshield spend, and no accepted private transfer whose public effects are not covered by the spend authorization) per Claim 6.3 and the conservation circuits. The scheme does not by itself provide strong anonymity: as in every opt-in shielded pool, practical unlinkability depends on the anonymity-set size and on metadata the cryptography does not hide — shield/unshield timing and amounts at the transparent boundary, fee fingerprints, bridge-flow correlation, and network-layer data. Operational mitigations (denomination uniformity, batching, timing jitter, sufficient pool flow) sit above the protocol; we state plainly that cryptographic note privacy is necessary but not sufficient for behavioral privacy.

To mint wrapped SOS (wSOS, an ERC-20) on Ethereum [2], an Ethereum contract must be convinced that a specific lock transaction was included in a finalized SOS block — under a few hundred thousand gas. Existing bridge designs answer this with trusted parties (multisigs, MPC committees, oracles), with optimistic challenge games, or with on-chain light clients; for a post-quantum chain the light-client route has a unique obstacle: SOS finality is $N$ ML-DSA-65 signatures of 3309 bytes each, far beyond plausible calldata and gas budgets, and lattice signatures do not aggregate. The SOS answer is to verify the entire quorum certificate inside a STARK and hand Ethereum a single succinct object whose public outputs the contract can reconstruct.

Replay is excluded at three layers: chain_id inside the signed hash (cross-chain), the epoch inside the signed hash (cross-validator-set generations), and lockId/height monotonicity in the contract (cross-batch).

Everything on the SOS side of Figure 4 is hash-based STARK verification of ML-DSA-65 signatures over SHA3-256 preimages — post-quantum throughout. Ethereum, however, cannot affordably verify a FRI transcript on-chain, so the relayer wraps the final STARK receipt into a Groth16 proof over BN254 [24] — the standard RISC Zero on-chain pattern — and that pairing-based seal is what the contract checks. This is the first of the two enumerated external-chain compatibility modules of Definition 2.3. Its failure domain is precisely scoped: a quantum (or classical) break of the wrap forges wSOS on Ethereum; it cannot touch the SOS ledger, whose own verifiers never accept wrapped receipts. Symmetrically, SOS-internal verifiers are required to reject non-STARK receipt kinds; hardening this rejection explicitly everywhere is tracked as an open item in Section 10.3.

The reverse direction mints native SOS against a proven burn of wSOS. The construction is an Ethereum light client inside a guest [44]: a proof that (i) the Ethereum sync committee’s BLS12-381 aggregate signature (the second enumerated non-PQ module) covers a recent beacon-chain header with a $\geq 2/3$ supermajority; (ii) the header whose execution state holds the burn is the finalized checkpoint under that signed header — reorg safety, so a head that later reorganizes cannot have released — proven by a finality Merkle branch; and (iii) the burn record exists in the bridge contract’s storage, via Merkle–Patricia trie account and storage proofs (keccak256) against the execution state root, with the burn’s amount and SOS recipient hash extracted from the proven storage words (never trusted from an input). The burn’s parameters are committed in the journal; the SOS node verifies the receipt and credits the recipient, debiting bridge_locked.

Status [IMPLEMENTED]: the guest performs real BLS12-381 aggregate signature verification of the sync committee over the signed header — a $\geq 2/3$-of-$512$ supermajority, not a participation-count or length check — together with the finalized-header, execution-payload, and MPT account/storage proofs that extract the released amount and recipient. This has been demonstrated end-to-end against live Ethereum Sepolia: a wSOS burn on Sepolia was proven by a GPU-generated STARK and verified on-node, after which the node minted the released amount from bridge_locked, with the locked-backing accounting conserved (a release debits exactly what it mints). The eth-burn verifier and the release mint are enabled by default (the default privacy-stark feature); a node built without that feature — and without the opt-in insecure-bridge feature — fail-closes and refuses to mint, so no unproven path can create SOS. Each proof is anchored to a per-node-deterministic trusted set of sync-committee roots (seeded at genesis from a pinned constant and extended by proven Altair committee rotations applied identically on every node, and persisted) and to the pinned bridge address. The trusted committee-root set is folded into app_hash, so nodes that disagree on the reverse-bridge trust anchor cannot continue with the same application hash. The remaining gap to [IMPLEMENTED, TESTNET-VALIDATED] is exercising this path under the multi-node load/chaos harness.

The contract tracks one validator-set hash; following its evolution is the classical weak-subjectivity problem of proof-of-stake light clients [47]. Rotating it requires an epoch-transition proof — a guest proving that set $V_{e+1}$ is the legitimate successor of $V_{e}$ under SOS’s staking rules — with the same journal-reconstruction discipline as deposits. The valset-transition guest and updateValidatorSet entrypoint are implemented and image-id pinned, so the on-chain path is no longer intentionally fail-closed. [IMPLEMENTED] The public rehearsal completed this lifecycle: a V0 deposit was processed, a canonical receipt proved the transition from epoch 7 hash 2d0c961c…c1b1e to epoch 226 hash 59024532…4de2, and Sepolia transaction 1ee99775…b93ff rotated the contract. A new V1 deposit was then processed in transaction 491ddd6e…5f2c; transition replay, V1 lock replay, and a stale-V0 deposit all reverted. Wrong-overlap inputs remain covered by the guest/host negative suite. The PCF epoch chain of Section 8.4 (whose checkpoints already bind validator_set_hash per epoch and chain contiguously) is the intended long-term substrate for this proof. Mainnet still needs automated churn campaigns and a deployment-domain migration protocol; these are catalogued in Section 10.3.

Light clients verifying finality without full state face a complementary weak-subjectivity problem on the SOS side: an exited validator, slashed or naturally unbonded, is no longer in the active set and therefore not part of the quorum denominator, but may sign forks of the chain’s history at heights where they were still bonded. A light client must therefore commit to a sufficiently recent checkpoint (a finalized block header and its QC) to ensure that the validator set cannot have been substituted without the client’s knowledge. The protocol’s active-set epoch is only 100 blocks and is an implementation cadence, not by itself a defensible maximum-offline or weak-subjectivity period. The public testnet therefore requires mobile wallets and explorers to re-sync the validator set and quorum denominator against live peers; it does not claim that one epoch supplies an hours-long trust window. For the longer-term PCF certificate of Section 8.4, the epoch-chain proof embeds validator-set transitions contiguously, allowing a client to verify them with one STARK artifact per segment. Before mainnet, an operational policy must fix independently distributed checkpoint sources, publication cadence, maximum offline time derived from unbonding and evidence windows, restart behavior, and user-visible bootstrap rules. Until that policy and consumption path are live, clients rely on explicit recent-checkpoint discipline.

What exists and is tested [IMPLEMENTED]: all three guests (consensus with FIPS-204 verification, inclusion, batch) build reproducibly and are embedded with pinned image ids and drift tests; the recursive composition round-trips end-to-end in host tests (a real $>2/3$-stake ML-DSA-65 quorum proven inside the consensus guest; sub-quorum, tampered-tx_root, and wrong-set inputs rejected); the ABI encoder is cross-checked against Solidity; and the hardened SOSBridge contract passes its Foundry suite including digest-binding, tamper, replay, and fee-bound tests.

What has been demonstrated on a live network [IMPLEMENTED]: the full relayer pipeline fetches real (block, QC, validator set, Merkle path) data from a node, composes the three proofs, wraps the result to a Groth16 seal, and submits it against a SOSBridge deployment pinned to the batch image id on Ethereum Sepolia. The active TVL-limited contract is 0x862Bc5c5…79e93, deployed at Sepolia block 11244918 with a 10,000-SOS global outstanding cap and 1,000-SOS per-deposit cap, mirrored by SOS consensus. A 1,000,000-sat V0 lock at SOS height 1640 was processed in transaction 581b1105…a22fc; the reverse direction then burned 500,000 sats in transaction db13a1d8…4c4be, and a 224,442-byte real succinct STARK receipt proved Ethereum finality before every SOS validator persisted the release. The public V0-to-V1 rehearsal subsequently rotated the contract and processed a 200,000-sat V1 lock at SOS height 26257. At the end of the rehearsal the contract reported 1,200,000 sats minted, 500,000 burned, and 700,000 outstanding. Deposit and transition replays were rejected, stale-V0 proofs failed after rotation, burn replay was idempotent, restart rebuilt the bridge RPC view, and a relayer with empty local state reconciled all operations from chain truth without duplicate submission. An unattended relayer, sync-committee-root maintainer, and fail-closed monitor remain live; the monitor compares the finalized SOS validator-set hash with the contract on every run. The repository’s dated E2E record preserves the full image ids and transaction identifiers.

What remains [IN PROGRESS]: the full cross-chain pipeline has not yet been run as a sustained bridge/privacy workload inside the multi-node fault harness; the tested fresh-cutover image policy still needs a consensus-defined bridgeDomain and activation/drain protocol for mainnet; the beta caps need an externally reviewed economic relation to slashable stake before they can be raised; and validators, relayers, provers, monitoring, and alert ownership need independent operators and failure domains. The SOS-side timeout refund path remains disabled until claim/refund exclusivity is proven under the chain’s timing and finality assumptions (Section 7.6). The current Foundry and live negative checks still need promotion to reproducible release CI and independent review. Theorem 7.1 applies to this implemented and demonstrated construction under those launch gates.

A quorum certificate carries one 3309-byte ML-DSA-65 signature per signer, and the bridge’s consensus guest re-verifies each in-zkVM at $\approx 5.87$M cycles. Both grow linearly in the signer count $N$ (Table 5):

Pre-quantum chains hide this with BLS aggregation: hundreds of signatures over one message compress to 96 bytes and one pairing check — which is exactly the primitive the post-quantum setting removes. The problem is to recover an aggregation-like property without leaving the PQ regime, under the project’s non-negotiables: full PQ internally, privacy untouched, the bridge non-custodial and proof-authorized, the staking set unbounded economically, and BFT safety under Assumption 5.

Three candidate routes were investigated to a decision and rejected; we record them because the reasons are load-bearing for the chosen design.

Given (a)–(c), SOS launches with a bounded active validator set ($N\leq 128$), the full raw QC in every block, plain FIPS-204 ML-DSA-65, and the complete $<\!1/3$ Byzantine margin — zero new cryptographic assumptions, QC within the block budget, and the validator-set binding of Construction 4.1 already in place. Delegation keeps economic participation unbounded while the signing set is bounded; the linear-QC constraint binds above roughly 150–200 validators and is thus a scaling road-map item rather than a launch blocker. The two tracks below are the road map.

The consensus guest of Section 7.2.1 already verifies a full stake-weighted ML-DSA-65 quorum inside a hash-based STARK. PCF’s observation is that this proof, built for the bridge, is the portable finality object the rest of the system wants: one succinct receipt can replace $N$ raw signatures for every consumer that is not the real-time consensus path itself.

Consumers: mobile light clients check one constant-size STARK per epoch instead of $N$ ML-DSA-65 signatures per block; syncing full nodes replace $N$ verifications per block during catch-up; and the bridge shares the same artifact, aligning bridge security with consensus security. The chain-segment property — at most one quorum block per height, each building on the previous — holds because consensus safety (Theorem 4.6) guarantees it for quorum-certified blocks.

Honest scoping, per the project’s own review: PCF is finality compression, not validator scaling — the block still carries the raw QC, which remains authoritative for real-time finalization (the certificate trails by proving latency and ships as an epoch checkpoint, in the spirit of Algorand’s state proofs [32], never as a gate: a missing certificate withholds a reward, never halts the chain). The $\approx$150–200-validator ceiling stands until the per-verification cost falls (Section 8.5 and the native-AIR program of Section 9). Before the certificate can become consensus-law for any consumer, identified gaps must close: an image-id rotation protocol (the on-chain id is immutable today), the epoch-transition guest of Section 7.6, explicit rejection of wrapped (non-STARK) receipts by internal verifiers, and a differential-check/disable switch so a hypothetical guest soundness bug is a recoverable liveness event rather than a forgeable finality certificate. Measured: a 4-block, 4-validator checkpoint proves in $\approx 76$ s on one lab GPU; sharded composition across 2 GPUs achieves $1.91\times$ (near-ideal) scaling on the verify-dominated portion.

The lever that shortens PCF epochs — and eventually unbinds $N$ — is the per-verification zkVM cost. Table 6 summarizes the stack with measured results (4$\times$RTX 3090 lab, real proving mode unless noted).