ZKTX DOCUMENTATION · ROBINHOOD CHAIN

A private ownership layer for public tokens.

ZKTX is a shielded-note protocol designed for standard ERC-20 tokens launched through PONS. It keeps the original token and market intact while allowing balances to move through a separate zero-knowledge vault.

Protocol previewNo production vault is deployed. The current interface cannot accept funds. Development proving keys must never secure real user funds.

01 · STATUS

What works today

Implemented

Domain-bound private notes and nullifiers
Poseidon incremental Merkle tree
Deposit, private-transfer, and withdrawal circuits
Verifier-compatible Solidity vault
Encrypted local note storage
Persistent event indexer
Simulation-first relayer
Multi-destination withdrawal planner
Reserve caps, pausing, and replay protection

Still gated

Production verifier ceremony
Independent security audits
Final CRCL contract configuration
Vault and verifier deployment
Funded production relayer
Two-party atomic swap authorization
Batched PONS matching and settlement

02 · OVERVIEW

The simple model

A user deposits a public ERC-20 balance into the vault. The client creates a secret note representing ownership of that balance. The blockchain stores only a commitment to the note. Later actions consume existing notes and create new notes while a zero-knowledge proof demonstrates that all protocol rules were followed.

Public tokendepositVault reservecommitmentPrivate notesproofNew notes or withdrawal

The vault never creates underlying tokens. Its public token reserves must always cover the total value represented by unspent private notes.

03 · ARCHITECTURE

Protocol components

Browser wallet

Creates secrets, commitments, nullifiers, proofs, and encrypted note backups. Sensitive note data remains in the browser unless the user explicitly exports it.

Shielded vault

Custodies supported ERC-20 assets, verifies proofs, tracks roots and nullifiers, enforces reserve caps, and releases tokens during valid withdrawals.

Circuits

Prove note membership, ownership, correct nullifiers, asset and amount binding, conservation of value, and valid output commitments.

Indexer

Reads vault events, rebuilds the commitment tree, records spent nullifiers, and supplies Merkle paths required to create proofs.

Relayer

Simulates and broadcasts approved private transfers and withdrawals so users do not need a separate public gas-paying wallet for each action.

Swap services

Planned components for two-party atomic authorization and privacy-aware batches executed against the public PONS market.

04 · PRIVATE NOTES

What a note contains

A note commits to the Robinhood chain ID, vault address, asset contract, amount, owner public key, and random blinding value. The chain stores the resulting Poseidon hash, not the private fields.

commitment = Poseidon(
  chainId,
  vaultAddress,
  assetAddress,
  amount,
  ownerPublicKey,
  blinding
)

Binding the chain and vault prevents a proof or note from being replayed in another deployment. The nullifier binds the commitment to the owner secret and identifies a spend without revealing which commitment was spent.

nullifier = Poseidon(commitment, ownerSecret, chainId, vaultAddress)

Back up note secretsLosing the encrypted note data or its password can make the shielded balance unrecoverable. The operator cannot reconstruct a user secret from an onchain commitment.

05 · TRANSACTION FLOWS

Deposit, send, and withdraw

Shield
The user approves the vault and submits a deposit proof. The proof binds the deposited asset and public amount to the hidden note. The vault transfers the tokens, checks its reserve cap, appends the commitment, and records a new Merkle root.
Private send
The owner proves membership and knowledge of the note secret. The circuit consumes the note, creates a recipient note and a private change note, and proves that the output amounts equal the input amount. The vault records the nullifier and two new commitments.
Withdraw
The owner proves an unspent note exists under a known historical root and binds the proof to the public asset, recipient, and amount. The vault marks the nullifier spent and releases the original ERC-20 tokens.

06 · WITHDRAWAL PLANNING

Reducing simple boundary correlation

A single deposit followed by an equal withdrawal to one wallet is easy to correlate. ZKTX therefore plans withdrawals across two to four user-controlled destinations, uses standard denominations, applies independent delay windows, and retains unmatched value as private change.

Example

A shielded balance of 12,347 units could produce standardized withdrawals totalling 12,000 units across several destinations. The remaining 347 units stay shielded. The number and timing of outputs should vary across users.

The vault recognizes historical Merkle roots, allowing a proof created for a valid earlier root to remain usable after unrelated commitments are appended. Every root accepted by the vault must have been created by a verified state transition.

Not anonymity by itselfSplitting and delaying withdrawals weakens basic amount-and-time matching. It cannot guarantee anonymity, especially when pool activity is low or a user follows a distinctive pattern.

07 · SWAPS

Two planned execution modes

Atomic private swaps

Two owners exchange private assets in one state transition. A safe design must obtain authorization from both owners without requiring either party to reveal its note secret. The authorization circuit and negotiation protocol remain under development.

Batched PONS execution

Private orders are combined and settled through larger public trades against PONS. The external PONS trade remains visible. A production batch must enforce asset conservation, limits, deadlines, maximum slippage, matcher authorization, and fair allocation in the proof system.

Neither swap path is enabled in the live preview. The interface labels them as protocol phases rather than operational features.

08 · PROOF SYSTEM

Groth16 over BN254

The current circuits use Circom, Poseidon hashes, a depth-20 commitment tree, and Groth16 proofs on BN254. Separate verifiers are used for deposits, transfers, and withdrawals because each circuit has a different public-signal layout.

Circuit	Public information	Private witness
Deposit	Roots, commitment, index, asset, amount, chain, vault	Owner key, blinding, insertion path
Transfer	Roots, nullifier, output commitments, indices, chain, vault	Input note, membership path, recipients, amounts, blindings
Withdrawal	Root, nullifier, asset, recipient, amount, chain, vault	Owner secret, blinding, membership path

Development proofs have been generated and verified end to end. Those development keys are server-local and excluded from source control.

09 · CONTRACTS

Vault controls and invariants

Only explicitly supported assets can enter or leave.
Every supported asset has an owner-configured reserve cap.
Commitments cannot be inserted twice.
Nullifiers cannot be spent twice.
State transitions must start from the current root.
Withdrawals may reference only roots previously recorded by the vault.
Token reserves are tracked and checked before release.
Deposits and transfers can be paused by the owner.
External token transfers use return-value checks and reentrancy protection.

The pilot owner is an encrypted server-held wallet. Control should be transferred to a multisig before broader usage.

10 · SERVICES

Indexer and platform-funded relayer

The indexer reconstructs the commitment tree exclusively from verified vault events. It persists commitments, nullifiers, the last indexed block, leaf count, and current locally derived root.

The relayer accepts strictly validated transfer or withdrawal payloads, simulates the contract call, applies per-IP limits, and broadcasts only if simulation succeeds. Its signing key is loaded from server configuration and is never sent to the browser.

Platform-funded gas improves usability and avoids forcing the recipient to acquire RH gas before withdrawing. It also creates abuse and availability risks, so production requires quotas, monitoring, multiple relayers, and a defined shutdown policy.

11 · PRIVACY MODEL

What is hidden and what remains public

Hidden inside the pool	Visible at the boundary
Note owners Private balances Internal transfer amounts Sender-to-recipient relationship	Depositor and deposit amount Withdrawal recipient and amount Asset contracts Transaction timing Aggregate public PONS trades

Privacy depends on the anonymity set. A vault with one active user provides little practical privacy even when its proofs are cryptographically correct. Larger shared activity, standard denominations, private change, batching, and varied timing improve resistance to correlation.

12 · SECURITY

Threat model

Protected against

Commitment forgery, unbalanced private transfers, cross-vault replay, cross-chain replay, double spending, unsupported assets, reserve-cap overflow, and invalid proof submission.

Not automatically protected against

Device compromise, password loss, malicious browser extensions, traffic analysis, IP logging, timing correlation, unique amounts, coercion, compromised setup parameters, or contract/circuit implementation bugs.

Trusted setup

Groth16 requires a setup. A multi-party ceremony ensures security if at least one contributor destroys its secret contribution. The requested direct-mainnet pilot currently skips this ceremony, so its development setup remains trusted and unsuitable for uncapped public funds.

Audit requirement

Passing tests is not an audit. Circuit constraints, generated verifiers, token behavior, upgrade assumptions, client cryptography, operational security, and relayer behavior require independent review before real value is accepted.

13 · OPERATIONS

Capped mainnet pilot

Configure
Set the final token contract, small reserve cap, owner, audited verifier addresses, deployment block, RPC endpoint, and dedicated relayer.
Deploy paused
Deploy verifiers and the vault, verify bytecode, register the token and cap, then reconcile the genesis root before enabling deposits.
Canary testing
Perform small deposit, transfer, split withdrawal, delay, and recovery tests. Compare the onchain root with the independent indexer after every step.
Monitor
Alert on root divergence, failed simulations, unusual relay volume, cap pressure, RPC disagreement, and token reserve discrepancies.
Expand carefully
Raise caps only after audits, a production ceremony, stable reconciliation, and a published incident-response process.

14 · LIMITATIONS

Important realities

ZKTX does not make deposits or withdrawals invisible.
Small anonymity sets allow strong statistical inference.
Standard denominations and delays reduce correlation but do not eliminate it.
A relayer can observe request timing and network metadata unless additional transport privacy is used.
Public PONS transactions remain visible and may reveal aggregate strategy.
Local encrypted storage is only as safe as the device and password.
The current atomic and batched swap systems are not enabled.
The current proving setup is for development validation, not trust-minimized production.

15 · GLOSSARY

Key terms

Commitment: A hash representing a private note without revealing its contents.
Nullifier: A unique value published when a note is spent, preventing reuse.
Merkle root: A compact fingerprint of every commitment currently recorded in the tree.
Witness: The private information supplied to a circuit to generate a proof.
Relayer: A service that submits a valid transaction and pays public network gas.
Anonymity set: The group of plausible users or notes among which activity may be hidden.
Private change: Unwithdrawn value returned to a new private note controlled by the user.
Trusted setup: The parameter-generation process required by Groth16.