STSH Whitepaper

STSH is a privacy pool protocol built on the Internet Computer. It allows users to shield STSH tokens into private notes, spend them without revealing which note paid, and pay out to any public account, with cryptographic proof that every step is valid. STSH is the first asset the protocol shields; the same design is built to extend to other Internet Computer assets as isolated pools.

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. Deposits are public, so the ledger stays honest. Which note paid is private. A payout's recipient and amount are public, and your Internet Identity signs the transaction. Private send to another person and hidden-sender withdraw come later.

Many privacy designs 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 total-value threshold

The pool operates under a governance-set total-value threshold of 60,000,000 STSH. It is the level at which governance and operations act, not a hard cap enforced in the canister: no deposit is rejected for carrying the total past it. Even in the worst theoretical failure, exposure is bounded to pool escrow, never the token supply. The threshold 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.

One exit today

There is one exit path today: a private spend with a public payout. You choose the amount and the public recipient; the remainder returns as a fresh private note. Which note funded the payment stays private. The amount and the recipient are visible on-chain, as they must be for a payment to be a payment. Because the fee is paid out of the note, the largest payout a note can make is a little below its face value. Private withdrawals, to a shielded address, arrive in an update after launch.

A standardised fixed-size payout, matching the deposit denominations, comes later. The asymmetry (fixed in, flexible out) is intentional: fixed deposits build the shared anonymity set; flexible payouts serve usability.

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: your notes follow your Internet Identity. Sign in on any device and the wallet rebuilds them from the chain, without any third party 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.

What the proof does not reveal

• Which note is being spent.
• When it was deposited.

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.

Proving keys were generated in a ceremony with a public randomness beacon.

The multi-party 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.

Up to 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, so the figure cannot be spoofed or substituted in transit. What it certifies is a self-report of the pool's own books, not a reconciliation against the ledger; the ICRC-1 ledger and the escrow held on it remain the supply boundary. Anyone can read it at any moment, from anywhere, at reserves.stsh.fi.

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

Allocation at genesis

Fees

Pool fees are the protocol's economic engine:

• Shield (deposit) fee: 0.25% (25 basis points), charged on top of the deposit, with a flat minimum of 2.5 STSH.
• Public payout fee: 0.25%, with the same flat minimum of 2.5 STSH.
• Private spend fee: 2.5 STSH, fixed.
• Public STSH transfer: no pool fee. STSH ledger transfers are free.

Fees are set. Changes need a vote and are capped per change. Fee revenue flows to the protocol treasury.

Token utility

• STSH is the shielded asset: note denominations are 1,000 / 10,000 / 100,000 / 1,000,000 / 10,000,000 STSH.
• Staking: public staking, with governance voting weight and rewards, comes later.
• 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 a governance vote. It never collateralises 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 disclosure architecture is designed to be opt-in, user-controlled, and cryptographic; disclosure is always the user's choice, never the protocol's. It comes later.

Privacy viewing keys (roadmap)

Users and businesses will be able to 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 so note data is 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 (roadmap)

Users will be able to prove their deposit originated from a verified, non-sanctioned source, without revealing which deposit is theirs: 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 shipped binaries pinned by hash and reproduced under a sanitised build. The source is public at github.com/FutureProof101/stsh-protocol, so anyone can match a shipped binary to its source by hash.

The arc runs in six phases. Only the first is a launch commitment; the rest are stated so the direction is public, and each carries its status on the roadmap page.

1. 01Launch. Shielded STSH, a working privacy system, public documentation, a small initial float and community review. Start with STSH; prove the privacy layer.
2. 02Grow. Liquidity and participation incentives, a larger anonymity set, real protocol activity. Threshold raises by governance as operational confidence accumulates.
3. 03Expand. Isolated privacy pools for other ICRC and Chain Fusion assets. STSH is the first supported asset, not the last.
4. 04Integrate. A public wallet and application SDK, so privacy becomes a feature of the apps people already use rather than a destination.
5. 05Decentralise. SNS transition after proven operation, users, liquidity, multiple assets and mature security.
6. 06Institutionalise. Auditable private Bitcoin and treasury infrastructure: viewing permissions, audit exports, proof of backing, policy controls and separate enterprise pools.

V2: what comes next, in order

V1 hides your balance and your notes. V2 hides you. The first step needs no circuit change and no migration: notes made under V1 keep working.

1. 01Hidden spender. Spends can be submitted by anyone (a throwaway identity, a relayer or the recipient), so the pool stops asking who is spending.
2. 02Spam control without identity. Prepaid, unlinkable verify tickets and a pool-wide budget replace per-account limits.
3. 03Private-to-private sends. Value moves between users' private balances without leaving the pool.
4. 04Viewing keys and audit tools. Read-only disclosure to an auditor, and after-the-fact proof of payment when you choose to (see Section 8).
5. 05Withdraw with a hidden sender, and payouts to fresh addresses.
6. 06Timing protection. Spends finalised in batches, so order and timing are blurred.
7. 07Live anonymity-set stats per note size on the reserves page.
8. 08ckBTC shielded pool, launched directly on the V2 model with a multi-contributor ceremony, and optionally a multi-party ceremony for STSH in the same sitting (see Section 4). Native zkBTC follows only if external audit strength supports it.
9. 09External audit, ICRC-3 and governance delay. An external audit, ledger transaction history for explorers and DEX listings, and a timelock with a public proposal feed.

Additional liquidity pools and duration-tiered LP incentives follow as demand develops.

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: 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 after the STSH pool is live and stable.

Where the protocol is

Known limitations of V1

• Your account signs every spend. Signing was the simplest safe defence at launch against spam floods that would drain the proof verifier. It costs sender privacy: the spender is visible, and with a single deposit a payout can be linked to it. V2 removes it.
• No private-to-private sends or withdraw yet. Value leaves the pool only by public payout.
• A young crowd. The anonymity set started at zero on launch day and grows with every note.
• Single-contributor trusted setup. One operator plus a public randomness beacon; a multi-party ceremony is planned.
• Controller cutover in progress. Governance runs on the 2-of-3 multi-sig; removing the founder's deploy key completes in the next release.
• No external audit yet. Review today is a continuous adversarial AI red-team; an external audit is planned.

Sequence

1. 01Launch: public token and privacy pool together (live). The public token and the shielded pool launched together, with initial liquidity of 30M STSH on ICPSwap. Vesting and token utility are live. Public staking comes later.
2. 02Grow: liquidity and the anonymity set. External review, liquidity-provision pools open to the community, and real protocol activity deepening the anonymity set.
3. 03Expand and integrate: other assets, then wallets. Isolated pools for additional Internet Computer assets follow, then a public SDK so wallets and applications can offer private settlement without rebuilding privacy.
4. 04Decentralise: the SNS handoff. After proven operation, control of all canisters (upgrade authority and treasury) transfers to the SNS DAO, and future upgrades, including circuit upgrades and re-ceremonies, become governance votes. Until that handoff completes, operational controls remain with the initial team.
5. 05Institutionalise: treasury infrastructure. Auditable private Bitcoin and treasury infrastructure as a later product line: viewing permissions, audit exports, proof of backing, policy controls and separate enterprise pools.

STSH's thesis is that financial privacy and public auditability are not opposites. Private spends 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.