stealthPRIVATE is a fully dedicated private sidechain where sender, receiver, and amount are hidden by mathematics, not by policy. No transparent fallback. No opt-in privacy. Every transaction inside the sidechain operates under zk-SNARK guarantees — always.
A deposit is recorded on stealthCORE as a CBridgeDeposit. It locks XST transparently into a multisig address and instructs stealthPRIVATE to mint an equivalent shielded note. The record is minimal by design — only what is needed for custody and withdrawal is persisted.
Deposits and withdrawals do not pair per-user. The bridge tracks two counters only — nTotalMinted and nTotalBurned — and enforces a single invariant: the shielded pool must always net to a non-negative, Core-collateralised supply. Every user's withdrawal consumes some unspent deposit UTXO. Which one is immaterial and unlinkable to the withdrawer.
A shielded note is a cryptographic commitment stored on-chain. It binds an amount and an owner — but reveals neither. The chain cannot tell you what a note is worth or who holds it, only that a valid note was created.
To spend a note, the owner publishes a nullifier — a one-way derivative of the note that marks it consumed, without revealing which note it was — and a Halo 2 zk-SNARK proof attesting that the note existed, was not previously nullified, and that the output balances check out.
A global nullifier set prevents double-spending. Observers see that a nullifier appeared; they cannot tell which note produced it. Sender, receiver, and amount are not obfuscated — they are mathematically absent from the public record.
Inside stealthPRIVATE, value moves freely: B → C, C → D, split, merge, relay. Every step is shielded end-to-end. Only the size of the nullifier set and the size of the note commitment tree grow — neither reveals anything about who moved what, or when.
Payment Disclosure is a planned feature that lets a sender selectively prove a single shielded payment to a third party, using their Outgoing Viewing Key (OVK).
The disclosure reveals only what is needed for the recipient party to verify: the receiver address, the amount, and the memo — for one specific note. Nothing about the sender's wallet state, balance, other transactions, or history leaks.
This preserves the global privacy property while giving senders a surgical tool for the narrow cases where proof-of-payment is useful — audit, refund, dispute, or merchant verification.
The stealthPRIVATE sidechain has no rich list, no visible transactions, and no searchable explorer — by design. The rich list RPC (getrichlist) only tracks transparent addresses on stealthCORE. Shielded transactions cannot be viewed, searched, or listed. Not "not yet"; not "for now" — not ever. The explorer does not and cannot exist for the shielded chain.
Both schemes were designed to protect transaction privacy on public blockchains. They achieve this through radically different mechanisms — with dramatically different security properties.
Ring signatures provide plausible deniability: one signer in a group, statistically hidden. zk-SNARKs provide cryptographic certainty: a mathematical proof that nothing was revealed. One is obfuscation. The other is proof.
The distinction is not academic. It determines whether privacy strengthens, holds, or degrades as chain data accumulates.
A transaction is signed by one member of a predefined group — the "ring." The signer selects n − 1 other public keys as decoys. An observer cannot definitively tell which member signed.
The privacy is statistical, not mathematical. The set of candidate signers — decoys included — is publicly visible on-chain. Every ring member, real and fake, is recorded forever. Monero is the canonical user of this scheme.
A zero-knowledge succinct non-interactive argument of knowledge. The prover generates a proof encoding the entire validity of a transaction — inputs, outputs, balances — without revealing any value.
No decoys. No candidate set. No statistical model to attack. The privacy is encoded in the mathematics of the proof itself — and it does not weaken as chain data accumulates.
Because every ring member is visible on-chain, each address will eventually appear in another ring, in another transaction, either as real spender or as decoy. This creates a graph of probabilistic relationships that chain-analysis firms actively exploit. Privacy is not static; it degrades.
Early Monero transactions used ring size 1 (no decoys). These transactions are trivially traceable. Any output that passed through that era of the chain carries a permanent on-chain record of its travel path — even if its current transactions use larger rings.
When a ring member is confirmed as a spend (e.g., via a zero-decoy transaction), it can be eliminated from every other ring it appears in. Each elimination narrows other rings — cascading to unmask senders across chain history.
Outputs have ages. Newly created outputs rarely appear as decoys in the same transaction that creates them. Statistical models of "typical" selection assign higher probabilities to certain ring members — narrowing plausible deniability below claimed levels.
Each additional decoy adds data. A ring-16 transaction is roughly 16× the size of a trivial one. As chains mandate larger rings for stronger privacy, throughput suffers and storage grows proportionally.
A zk-SNARK proof is a few hundred bytes — regardless of what it proves. Hiding sender, receiver, and amount produces the same compact proof as hiding only one. The "succinct" is in the name.
Verifying a ring signature checks the relationship across all n members. A ring-16 transaction verifies roughly 16× slower than a trivial one. On high-throughput chains, the overhead compounds.
zk-SNARK verification is O(1) — same time regardless of the size or complexity of the underlying statement. This is compatible with high-throughput chains that must validate thousands of transactions per second.
| Privacy property | Ring Signatures | zk-SNARKs |
|---|---|---|
| Sender identity hidden | Probabilistic | Provably complete |
| Receiver identity hidden | Partial (stealth addresses) | Provably complete |
| Transaction amount hidden | Only with RingCT add-on | Native & complete |
| Resistant to chain analysis | Degrades over time | Permanent guarantee |
| On-chain decoy records | Yes — all visible | None |
| Proof size | Scales with ring size | Constant (~200 bytes) |
| Verification overhead | Scales with ring size | Constant time |
| Privacy guarantee type | Heuristic / statistical | Cryptographic / mathematical |
Early zk-SNARK constructions required a trusted setup to generate cryptographic parameters. If the ceremony's "toxic waste" is not destroyed, an attacker could forge proofs — a genuine and important consideration.
Modern practice addresses this with multi-party computation (MPC) ceremonies. Hundreds or thousands of independent participants contribute randomness. The ceremony is only compromised if every single participant is — an essentially impossible condition at scale.
stealthPRIVATE uses Halo 2 / Orchard — a proof system that eliminates the trusted setup requirement entirely. There is no ceremony, no toxic waste, no multi-party trust assumption to preserve.
Ring signatures also require no setup — but that advantage is paid for with a fundamentally statistical privacy model. Halo 2 gives you both: no setup, and mathematical proof.
"Ring signatures say: 'it could have been anyone in this group.' zk-SNARKs say: 'I can prove everything is valid without telling you anything at all.' One is obfuscation. The other is mathematics."Stealth R&D LLC
| Architecture | Dedicated sidechain | stealthPRIVATE runs alongside stealthCORE. Fully shielded by default — no transparent pool, no opt-in. |
| Proof system | Halo 2 / Orchard | Zero-knowledge succinct non-interactive arguments of knowledge. No trusted setup. |
| Bridge record | CBridgeDeposit | Stores core_txid, amount, p2sh_address, staker_keys, spent. Does not store sender or receiver XSS address. |
| Custody model | 2-of-3 P2SH multisig | Three staker public keys govern unlock; any two constitute a valid quorum for withdrawal. |
| Privacy set | Pool · mint-burn | nTotalMinted − nTotalBurned = net supply. Anonymity set is every historical depositor. |
| Spend bundle | spend · output · change · proof | One spend action, one output action, one optional change output, one Halo 2 proof. Constant-size, O(1) verification. |
| Note model | Commitment + nullifier | Notes are on-chain commitments. Nullifiers prevent double-spending with zero disclosure of which note was consumed. |
| Payment Disclosure | Planned · OVK-based | Sender-originated proof of a single payment: recipient, amount, and memo only. Selective transparency; does not leak wallet state. |
| Explorer visibility | None — by design | Public data: block height, net supply, note commitment tree size, nullifier count. No rich list. No transaction explorer. |
| Fees | Feeless | Inherits Stealth's feework model. No per-transaction fees inside the shielded pool. |