TECHDOCS

ShieldSwap is a non-custodial swap interface that converts transparent assets (BTC, ETH, SOL, USDC) into shielded Zcash (ZEC). The defining property: once your funds enter the Zcash shielded pool, the public trail ends. There are no accounts, no KYC, and no custodial balance — you send from your own wallet and receive directly into a shielded address you control.

The system has three layers:

• Interface layer — this site. Builds the swap order, validates your destination address and displays the one-time deposit address. It never touches your keys.
• Routing layer — watches for your deposit, executes the conversion into ZEC through liquidity sources, and constructs the shielded payout transaction.
• Settlement layer — the Zcash network itself, where the payout lands as an encrypted note in the Orchard shielded pool.

Zcash is a Bitcoin-derived blockchain with an optional privacy layer. Transactions happen in one of several pools, and the pool determines what an outside observer can see:

ShieldSwap pays out exclusively into the Orchard pool. Every shielded transaction hides three things at once: the sender, the receiver and the amount. The blockchain only records that some valid note was spent and some new note was created — nothing more.

A zero-knowledge proof lets a prover demonstrate that a statement is true without revealing why it is true. In Zcash, every shielded transaction carries a proof that convinces the network of all of the following, while revealing none of the underlying data:

• The spender actually owns the input notes (they know the spending key).
• The input notes exist in the pool and have never been spent before (a nullifier is published to prevent double-spends, but it cannot be linked to the note).
• Inputs equal outputs — no ZEC is created from thin air. The balance check happens on encrypted values using homomorphic commitments.

Orchard uses Halo 2, a proving system built on the Pasta curves (Pallas and Vesta). Two properties matter for swaps:

The destination field on the swap page accepts addresses starting with u1 (unified) or zs1 (Sapling). A unified address is a container: it bundles receivers for multiple pools — Orchard, Sapling and optionally transparent — into a single string.

When ShieldSwap pays out to a unified address, it always selects the Orchard receiver. This means you can paste the default address from any modern Zcash wallet (Zashi, Ywallet, Nighthawk) and the funds land in the most private pool automatically.

Viewing keys: every shielded address has a corresponding full viewing key that can decrypt incoming notes without being able to spend them. Only you hold these keys; ShieldSwap never sees them and cannot inspect your balance after payout.

Each swap moves through five stages:

The design is non-custodial by construction: there is no account balance to hack, no withdrawal queue, and no hot wallet holding user funds between sessions. Each swap is an isolated, atomic pipeline.

Even inside a shielded pool, timing and amount can leak information. If 0.05 BTC goes in and 4.7123 ZEC comes out sixty seconds later, an observer watching both chains can guess the link. The three privacy modes trade speed for unlinkability:

The segmented bar in the swap panel shows the hop count of the selected mode — each hop is an additional shielded transaction between your deposit and your final balance.

• No keys, ever. The interface runs entirely in your browser. It never asks for a seed phrase, private key or wallet signature.
• One-time addresses. Deposit addresses are single-use and derived per swap, preventing address-reuse clustering.
• Encrypted memos. Payout notes carry an encrypted memo only your wallet can read, used for swap receipts.
• What we can see: the deposit transaction (it is public on the source chain) and the fact that a payout occurred. What we cannot see: your balance, your other transactions, or any link between your swap and your future spending.

This is currently a demonstration interface. The rates shown (BTC 98,000 · ETH 3,600 · SOL 180 · ZEC 52 USD) are fixed sample values, and the deposit address displayed after a swap is a placeholder — do not send real funds to it.

A production deployment additionally requires:

• A live rate oracle and liquidity routing backend.
• Real per-swap deposit address generation on each source chain.
• A Zcash node infrastructure constructing Orchard payouts.
• Per-swap and daily limits, plus expiry and refund handling for failed deposits.

The architecture documented above is the target design; the demo implements the full user-facing flow so the experience can be evaluated end to end.