Shielded TOS

Private value.
Verifiable transactions.

The native-TOS shielded pool uses zero-knowledge proofs to validate private note transactions, with post-quantum spending authorization and encrypted note delivery.

A defined privacy layer for native TOS.

V1 has a fixed two-input, three-output transaction shape. Commitments represent notes; nullifiers prevent repeated spends. Real and dummy output payloads have the same length.

Deposit TOS

Public entry into the pool

Transfer notes

Private witnesses, verified on-chain

Withdraw TOS

Public payout from the pool

Three mechanisms.
Three separate protections.

GROTH16 · BLS12-381

Prove transaction validity

The circuit checks note membership, ownership witnesses, amount constraints, and value conservation. Poseidon2 supplies commitments and tree hashing.

ML-DSA-44

Authorize each spend

A one-time key per note signs the transaction intent, binding authority to the exact inputs, outputs, payout, and validity window.

ML-KEM-768 · XCHACHA20

Deliver notes privately

Encrypted chain-delivered payloads let recipients scan and recover their notes. Authentication binds encrypted data to its execution domain and output slot.

Know what is private.

Private note values and ownership witnesses are checked inside the proof. Deposits, withdrawals, public payouts, fees, commitments, nullifiers, and timing can still expose information or permit correlation. Network anonymity and wallet security require separate protections.

Implementation and activation.

The contract, circuit, wallet, and ceremony tooling are implemented. Public-network activation remains subject to the frozen profile’s acceptance gates. Development proving keys use a known seed and must never secure real funds. Production requires verified ceremony artifacts and matching deployment identities.