STSH Whitepaper

STSH (Stealth Cash) is a privacy pool protocol built on the Internet Computer. It allows users to shield STSH tokens, transact privately inside the pool, and withdraw, with cryptographic proof of validity but no public record of who sent what to whom.

STSH is not a mixer and not a tumbler. It is a fully on-chain, ZK-powered shielded pool that preserves the auditability of the underlying ledger while giving users genuine financial privacy. Tokens move into the pool publicly, so the ledger stays honest. Activity inside the pool is private. Withdrawals are publicly valid (the math proves it) but privately yours.

Most privacy protocols, including Zcash, treat the shielded pool as part of the monetary supply. That means a flaw in the zero-knowledge circuit could, in theory, allow counterfeit private notes to exist, invisibly inflating the total supply.

STSH is architecturally different. The public ICRC-1 ledger is the canonical source of truth for supply. The shielded pool holds real tokens in escrow; nothing more. A ZK circuit flaw cannot create new STSH. The worst-case scenario is that it could allow someone to drain pool escrow beyond their legitimate claim: a serious problem, but a bounded and detectable one.

Shielded pool accounting must never increase total token supply. It can only move ledger-held escrow between public and private claim states. A ZK circuit failure cannot inflate base supply; it can at worst enable drain of affected pool escrow, which the on-chain solvency monitor makes immediately visible to anyone.

Bounded exposure: the pool deposit cap

At launch the pool operates under a governance-set total-value cap of 60,000,000 STSH. Even in the worst theoretical failure, exposure is bounded to the capped escrow, never the token supply. The cap is raised by governance as operational confidence accumulates (audits, the multi-party re-ceremony, sustained clean operation).

Fixed-denomination deposits

Deposits are locked to five note sizes: 1,000 · 10,000 · 100,000 · 1,000,000 · 10,000,000 STSH. This is the foundation of the privacy guarantee, not a limitation. The anonymity set is the group of depositors a transaction could plausibly have come from, and fixed denominations are what make that set meaningful: if deposits were variable amounts, the amount itself would become the fingerprint. With fixed denominations, a withdrawal of 100,000 STSH could have come from any of the identical 100,000-STSH deposits in the pool. The decade-spaced ladder covers everyday amounts through treasury-scale positions, and the full ladder is frozen into the circuit from day one; no future ceremony is needed for the pool to serve larger or smaller users as the protocol grows. The larger and more active the pool, the stronger the privacy.

Two withdrawal options

STSH offers two withdrawal modes. Standardized withdrawals (matching the note denominations) provide the strongest privacy: standard sizes mean your withdrawal looks identical to every other withdrawal of that size, giving you the largest possible anonymity set. Custom amounts give you flexibility to withdraw any exact figure; your identity remains private but the amount itself is visible on-chain. Users choose based on their priorities.

The asymmetry (fixed in, flexible out) is intentional: fixed deposits build the shared anonymity set; flexible withdrawals serve usability without breaking the core unlinkability guarantee.

STSH runs entirely on-chain. There are no servers, no hosted backends, and no off-chain dependencies. Every component (the token, the privacy pool, the nullifier registry, the proof verifier) is a canister running on the Internet Computer.

Component model

Why the Internet Computer

• Fully on-chain ZK verification: Groth16 proof verification happens inside a canister. There is no off-chain prover service to compromise or trust.
• Certified queries: smart contracts return cryptographically signed responses. The solvency monitor cannot be spoofed.
• ICRC-1/ICRC-2 compatibility: the STSH token follows the Internet Computer's standard fungible token interface, compatible with ICP wallets, DEXes, and the broader ecosystem.
• Cross-device note recovery: encrypted note backup via the IC's vetKeys threshold-encryption system; your shielded notes are recoverable across devices without any third party ever holding your keys.
• Upgradeable without state loss: canisters can be upgraded while preserving all stable state (notes, nullifiers, accounting) in place. Every canister's persistence layer has been through a dedicated upgrade-hardening campaign with independent adversarial review.

STSH uses a Groth16 ZK-SNARK circuit (BN254 curve) to prove that a withdrawal is valid without revealing the note being spent. The circuit was built from scratch for STSH and has undergone repeated rounds of adversarial security review, including dedicated ZK soundness review.

What the proof proves

• The spender owns a real note that exists in the pool's commitment tree.
• The note has not been spent before: the nullifier is fresh.
• The values in and out are consistent: you cannot withdraw more than you deposited.
• The recipient is the one you specified.
• The fee charged is within the circuit-enforced bound: fees cannot silently exceed a hard in-circuit ceiling, no matter what any canister parameter says.

What the proof does not reveal

• Which note is being spent.
• Who deposited it.
• When it was deposited.
• The link between deposit and withdrawal.

The circuit is cryptographically bound to its exact deployment: the pool's canister identity is baked into the proving system itself, so proofs generated for STSH are valid only for STSH's pool; they cannot be replayed against any other deployment, and no other deployment's proofs work here.

Circuit internals, constraint structure, and implementation specifics are intentionally not published in marketing materials. Technical review artifacts are shared through the protocol's audit and community-testing process.

ZK-SNARK protocols require a trusted setup, a cryptographic ceremony that generates the proving and verification keys the protocol uses.

Disclosure

The setup has two phases:

• Phase 1 (powers of tau): the universal parameters, taken from an established public powers-of-tau ceremony.
• Phase 2 (circuit-specific key): conducted as a single-party ceremony initially. A multi-party re-ceremony is planned once governance and the community stabilise, in line with future roadmap additions.

The re-ceremony plan

1. 01The circuit (the math that defines the rules) does not change.
2. 02Each participant runs the contribution process on their own machine and destroys their randomness.
3. 03The result is a new verification key, installed through the protocol's governed verifier-update mechanism.
4. 04Users with existing shielded notes are completely unaffected; funds are safe throughout.
5. 05After the re-ceremony, users simply need an updated wallet to generate new proofs against the new key.

Notes inside the pool are cryptographic commitments: hashes stored in a Merkle tree. They are completely independent of the verification key. A verification key swap affects future proof generation only. No migration of funds is required.

2% of genesis supply is allocated to re-ceremony participants, a direct community incentive to participate in the cryptographic foundation of the protocol.

STSH operates an on-chain solvency monitor, a publicly queryable canister that anyone can call at any time to verify the pool's accounting is sound.

What it exposes

• Whether total escrow backing equals the pool's actual ledger balance (always exactly 1:1).
• Cumulative deposits vs. withdrawals (withdrawals can never exceed deposits).
• Any drift in the pool's accounting identity.

The monitor is powered by the IC's certified queries: the subnet cryptographically signs the response. It cannot be manipulated or taken offline without a visible governance action. Anyone (community members, researchers, competing protocols) can verify the pool is solvent at any moment, from anywhere.

STSH has a fixed genesis supply of 1,000,000,000 STSH and launches as a single-asset shielded protocol for STSH.

Token distribution

Float transparency. STSH reports circulating supply as three separate measures: day-one market float (the 30M AMM deployment), allocated-and-vesting, and locked/governance-gated; never one blended number. At genesis, everything outside the 3% AMM deployment and active vesting schedules is locked, multisig-controlled, or governance-gated.

Fees

Fees are live from launch and are the protocol's economic engine:

• Shield (deposit) fee: 0.25% (25 basis points), charged on top of the deposit, with a minimum of 1,000 STSH.
• Private spend fee: 0.1 STSH flat per in-pool transaction.

All fee parameters are governed within hard, pre-committed bounds: rates can only move within a fixed range, by limited steps, with a 24-hour cooldown between routine changes, so fees can never be silently spiked or zeroed by any single action. On top of the governance bounds, the circuit itself enforces an absolute fee ceiling cryptographically. Fee revenue flows to the protocol treasury under governance.

Token utility

• STSH is the shielded asset: note denominations are 1,000 / 10,000 / 100,000 / 1,000,000 / 10,000,000 STSH.
• Staking: staked STSH earns governance voting weight and staking rewards, with commitment periods from 30 days to 3 years.
• Fee economy: every shield and private spend pays fees in STSH, tying protocol usage directly to the token.
• Supply boundary: the ICRC-1 ledger is the canonical supply: the pool cannot create STSH, only move it.

Security & Recovery Reserve

The reserve (12% of genesis) is a capped, STSH-denominated protocol backstop designed to help remediate bounded accounting or proof-system incidents affecting pool liabilities. It is not an unlimited guarantee and does not insure fiat-denominated market value.

• Covers: bounded accounting or proof-system incidents affecting STSH pool liabilities, confirmed through the protocol's incident review process.
• Does not cover: market value losses, user trading decisions, external protocol failures, or events without a confirmed incident finding.
• Claims are assessed in STSH units, not fiat value, subject to available reserve and governance approval.
• The reserve cannot be sold or deployed without governance approval; locked under the same restrictions as treasury principal. It never collateralizes pools.

Treasury policy

The protocol treasury supports long-term development, future SNS/DAO governance, audits, grants, integrations, operations, and controlled liquidity programs. Treasury actions are transparent, governed, and subject to clear execution limits. Reserves may be diversified over time using protocol-earned fees and governance-approved treasury actions: gradual, transparent, slippage-limited, and capped relative to market liquidity. The protocol does not conduct discretionary market dumping.

Privacy that cannot coexist with legitimate oversight doesn't survive contact with the real world. STSH's compliance architecture is opt-in, user-controlled, and cryptographic; disclosure is always the user's choice, never the protocol's.

Privacy viewing keys

Users and businesses can generate a viewing key that allows a designated third party (an auditor, a compliance officer, a counterparty) to verify the details of their shielded transactions without the ability to spend. The initial version uses encrypted note storage (via the on-chain vetKeys system) so note data is recoverable across devices and shareable via key. A later version adds full ZK proof of viewing authority (cryptographically proving you hold a viewing key without revealing it), scoped to the multi-party re-ceremony circuit upgrade.

ZK association sets

Users can prove their deposit originated from a verified, non-sanctioned source, without revealing which deposit is theirs. Based on the "Privacy Pools" model (Buterin et al., 2023): the user generates a proof of membership in a "clean" set, which can be shown to a compliance party on demand. The transaction's privacy is preserved; only set membership is disclosed. This feature requires a new ZK sub-circuit and is scoped to the multi-party re-ceremony alongside the viewing-key upgrade.

Both features are additive: they extend what users can do without changing or breaking the existing privacy pool, shielded notes, or any existing funds.

Always-on public auditability

Independent of any user's choices, the protocol itself is permanently auditable: fixed supply on a public ledger, 1:1 escrow verifiable through the solvency monitor, all treasury and governance actions on-chain, and open-source release of the protocol code as the trust substitute during the pre-re-ceremony period.

Post-launch protocol features

• Viewing keys (initial encrypted-storage version, then full ZK viewing authority; see Section 8).
• ZK association sets (see Section 8).
• Multi-party re-ceremony (~3–6 months post-launch) with the 2% participant incentive.
• LP programs: additional liquidity pools and duration-tiered LP incentives, opening in the first weeks post-launch as demand develops.
• Deposit-cap raises by governance as operational confidence accumulates.

Multi-pool expansion

STSH V1 supports a shielded STSH pool. The same architecture is designed to extend to additional ICRC-compatible assets as isolated, independent pools under DAO governance: each future pool with its own canister, its own nullifier registry and Merkle tree, its own trusted setup, and its own verification key, with the pool's identity cryptographically baked into its circuit.

This means a vulnerability in one pool can never affect another. Cross-pool isolation is a design requirement, not an implementation detail. Specific assets and sequencing will be announced under DAO governance after the STSH pool is live and stable.

Where the protocol is

Launch sequence

1. 01Phase 1: Public Token Launch. STSH launches as a transparent, standard on-chain asset with initial liquidity of 30M STSH / $10,000 ckUSDC. Staking, vesting, and token utility are live. The privacy pool is not yet active; this phase establishes liquidity and distributes participation to the community.
2. 02Phase 2: Privacy Pool Launch. The shielded pool activates behind explicit entry conditions: the final circuit freeze and ceremony complete and disclosed, the solvency monitor verified against the live pool, cross-device note recovery (vetKeys) live and tested, the wallet built and tested, the deposit cap in force, and the re-ceremony timeline publicly announced.
3. 03Phase 3: SNS / DAO Handoff. Control of all canisters (upgrade authority and treasury) transfers to the SNS DAO. The protocol operates as a fully decentralised, community-governed public utility; all future upgrades, including circuit upgrades and re-ceremonies, are governance votes.
4. 04Phase 4: Multi-Pool Expansion. Additional asset pools follow under DAO governance.

STSH's thesis is that financial privacy and public auditability are not opposites. Private transfers can coexist with public solvency when notes are escrow-backed, double-spends are blocked by nullifiers, the supply boundary lives on a public ledger, and anyone can verify the pool's accounting at any moment. Privacy where it matters. Auditability where it counts. Disclosure where trust is required.