Privacy Track · Grant Overview
A shielded pool for sBTC where amounts and the sender-to-recipient link stay private, double-spends are blocked by nullifiers, and viewing keys allow lawful disclosure. The confidentiality engine is swappable, a zero-knowledge proof, a threshold committee, or secure hardware.
What the chain sees
state root
0x9f3a·c1d7·...·40e2
nullifier
0x77c1·8b2a·...·9fa3
output commitments
[ 0x2e...aa , 0xb4...07 ]
authorisation
valid ✓ (proof or signature)
What stays shielded
amount
0.0421 sBTC🔒
sender → recipient
SP3F... → SP9Q...🔒
which note was spent
note #1473🔒
spend key
nk · ········🔒
01 · The unit of value
Everything inside the pool is denominated in notes. A note is a private record that a specific amount of sBTC belongs to a specific owner. Notes are not fixed denominations: each one can hold any amount, so two notes are generally worth different sums. The chain never stores the note itself, only a one-way commitment to it, so those differing amounts and who owns them stay hidden while the pool can still prove it holds exactly what it owes.
A note is
(value, owner key, secret ρ)
On chain
cm = Poseidon2(value, pk, ρ)
When spent
nf = Poseidon2(nk, ρ)
Solvency
reserve = sum of live notes
Where a note comes from
Created. A note is minted in one of two moments. A deposit creates a note for the amount you put in, owned by you; the deposit amount is public, but the note that results is not. A confidential transfer creates new notes as its outputs, one addressed to the recipient and a change note back to the sender.
Found. Each output note is encrypted to its owner, so your wallet scans the public stream and trial-decrypts with your viewing key, keeping the notes that open. Holding a note means holding its secrets, its value and its ρ, which is what later lets you spend it.
Spent. Spending proves you own a note already committed in the tree, publishes its nullifier so it can never be spent twice, and emits fresh output notes. Splitting a spend across several outputs plus change stops amounts from lining up one to one, so the chain cannot match what went in against what came out.
02 · Architecture
Custody, the commitment-and-nullifier ledger, the wallet, viewing-key disclosure, and the indexer are built once. The box that authorises a confidential spend is the only thing that changes between the three directions, which keeps them interchangeable.
03 · The three engines
The engines differ only in how a confidential spend is authorised, and in what you trust to do it. Pick one; the rest of the system is identical. Each card below names what it is best for.
trustless, the proof
Each user proves their own spend. A Clarity verifier checks the proof on-chain using only hashing and field arithmetic. Nobody sees the witness.
Best for: trustless privacy, best ZK-fit
no single point, all-n
A committee secret-shares amounts and computes validity on the shares, so no node sees plaintext. Reuses the bonded sBTC signers, or stands up an independent committee.
Best for: trust-minimized committee
hardware, 1 break/batch
Matching runs inside secure enclaves on multiple vendors, each producing a hardware attestation. No novel cryptography, so it is the lightest to build.
Best for: fastest path to production
04 · How a confidential spend is authorised
Deposit, confidential spend, and withdraw work the same whichever engine you pick. Only the authorisation step differs, and all three paths end at the identical on-chain settlement.
05 · Cryptographic choices
The shielded-pool core is shared by all three. Each engine then brings its own cryptography for the one step that differs, authorising a confidential spend.
Shared core, all engines
Hash
Poseidon2
Commitment
Zcash-style
Accumulator
Merkle d=32
Double-spend
nullifiers
A · ZK-STARK
Field
BabyBear 31-bit
Proof system
classic FRI
Prover
Plonky3
Verifier
no pairings
B · Threshold MPC
Sharing
Shamir
Integrity
SPDZ MACs
Preprocessing
Beaver triples
Signature
WSTS threshold
C · Multi-vendor TEE
Isolation
Enclaves
Trust
remote attestation
Vendors
Nitro / SGX / SEV
Signature
WSTS threshold
06 · What the grant funds
Milestones 1-3, 5 and 6 are identical across all three engines; only Milestone 4, the engine, changes. Every milestone ships deployed contracts, passing tests, on-chain transaction hashes, or benchmarks a reviewer can check directly.
Clarity custody, the commitment and nullifier ledger, the reserve invariant, the depth-32 Poseidon2 Merkle tree, and Zcash-style notes with splitting, deployed and tested on testnet.
Note and key management, encrypted notes with trial decryption, split-withdraw, and the threshold-disclosure tooling.
A purpose-built indexer over the Stacks node event stream, the Postgres sync service, recovery, and the path API. Public data only, never a witness.
The confidentiality mechanism for the chosen engine: a STARK circuit with a Clarity verifier, an MPC committee computing on secret shares, or multi-vendor enclaves with attestation. Each ends in on-chain accept and reject with transaction hashes a reviewer can check.
Wallet connect and the deposit, spend, withdraw, and disclose flows, with charts, the simulator, and mobile.
A scripted testnet run end to end: deposit, a confidential spend authorised and verified on-chain, withdraw to a fresh address, plus privacy and invariant checks.