Documentation

Introduction

ra:st is a privacy layer for on-chain money. It lets anyone move value on a public blockchain without broadcasting their financial life to the world, while still being able to prove, to anyone who requires it, that the money is clean. It is deployed on Robinhood Chain, it is non-custodial, and it holds neither your funds nor your keys.

The result is a system with three properties that were long thought mutually exclusive:

• Unlinkable. No on-chain observer can connect your deposit to your withdrawal.
• Provably clean. Every withdrawal proves, in zero knowledge, that it belongs to an approved association set. This is not a mixer.
• Self-custodial. No operator ever holds your funds or your keys. A single secret, your recovery phrase, is the only thing that can move your money.

This documentation explains ra:st first in plain terms and then in technical detail: what it is, whom it is for, how it works, and why its guarantees hold.

The problem

On a public blockchain, everything is visible: how much you hold, who pays you, what you buy, and when. That transparency is permanent and searchable by anyone, forever. When you receive value on-chain, the ledger records your address, the sender's address, the exact amount, and the precise time, for everyone, indefinitely.

No bank statement works this way. No cash transaction works this way. Yet every on-chain transfer does. This is not an incidental flaw; it is how public blockchains are built. Their integrity depends on every participant being able to verify the whole history, which means the whole history is legible to everyone.

Who this hurts

• The individual paid on-chain. Your salary, its source, and everything you do with it become public the moment you are paid.
• The business accepting crypto. Your revenue, suppliers, margins, and treasury movements are visible to competitors as they happen.
• The trader. Your positions and strategy are readable on a public ledger. Your edge disappears the moment it is on-chain.
• The counterparty who never consented. When someone pays you on-chain, the record ties their address to yours, whether or not they wanted that exposed.

A whole industry of chain-analysis firms exists to exploit this legibility. The question is not whether anyone is looking. On a public chain, everyone is always looking.

What ra:st is

ra:st is a non-custodial shielded pool with a compliance proof built in. Using it is three moves, and there is nothing else to learn.

• Deposit, in the open. You put value into the pool. This transaction is fully public. Before depositing, your device generates a secret note and publishes only its commitment, a hash. The secret never leaves your device.
• Prove, in zero knowledge. To take your funds out, you prove two things at once, revealing neither: that you own a note in the pool, and that your note belongs to an approved association set. The proof is generated locally, in your browser.
• Withdraw, in private. Your funds arrive at a fresh address with no on-chain link to your deposit. The chain shows that a deposit happened and a withdrawal happened; it cannot show they were the same person.

That is the entire protocol. No mixer. No custody. The note is the only key.

Who it's for

• Individuals who do not want their salary, savings, and every purchase to be a permanent public record. Privacy here is not secrecy; it is the ordinary financial confidentiality that every other payment system already provides.
• Businesses that cannot operate with their revenue and treasury movements broadcast in real time to competitors, but that also cannot use tools which would compromise their regulatory standing.
• Traders whose alpha evaporates the moment their positions are legible, and who need to move capital without signaling it to the entire market.
• Institutions for whom privacy and compliance are both non-negotiable. The association-set mechanism is precisely the primitive that lets an institution demonstrate clean provenance while retaining confidentiality.

Design philosophy

Three commitments shape every decision in the protocol.

We hold nothing

There is no operator account that custodies your deposit, no administrative key that can freeze or seize a position, and no upgrade button that can change the rules on funds already in the pool. Your recovery phrase is the sole authority over your money. This cuts both ways: because we built the system so that we cannot move your funds, we also cannot recover them if you lose your phrase.

Your secrets never leave your device

Every computation that touches a secret, generating your note or building your proof, happens locally in your browser. The servers in this system see only public data. Outsourcing proof generation would mean handing over your witness and defeating the entire purpose.

Trust as little as possible

We reduce what you must trust to a small body of auditable code and a few well-studied cryptographic assumptions. We do not ask you to trust us. We ask you to trust math.

Three moves

The whole protocol is a round trip: value enters the pool publicly, and later leaves privately, carrying a proof that it is clean. Nothing links the exit back to the entry.

The sections that follow walk each move in order, then open up the machinery underneath.

Core concepts

A handful of objects recur throughout ra:st. Understanding these five makes everything else straightforward.

The note secrets are derived from a single recovery phrase, so one backed-up phrase reconstructs every note you have ever created. The secrets never leave your device.

Deposit

Depositing is fully public. Its privacy contribution is prospective: your deposit enlarges the anonymity set into which a later, unlinkable withdrawal will blend.

• Your device derives the note secrets and computes a precommitment, a hash of the secret material. Only this hash is submitted.
• The contract charges a small vetting fee, assigns a public label, forms the full commitment, and inserts it into the state tree.
• Your client reads the emitted event and records the completed note locally.

The association set

The association set is what separates ra:st from an indiscriminate mixer. It is a curated collection of approved deposit labels, published on-chain as a Merkle root by an association-set provider (ASP).

To withdraw with privacy, your note's label must be in the published set. You prove membership in zero knowledge, without revealing which member you are.

What the ASP can and cannot do

• Can: decide which deposits are withdrawable with privacy, by choosing which labels to include.
• Cannot: hold, move, freeze, or seize any funds. Withdrawal still requires your note secrets, which the ASP never learns.
• Cannot: forge membership, alter a published set (the registry is append-only), or deanonymize a withdrawal.

Prove

Withdrawal is where privacy is produced. Before any funds move, your browser builds a single zero-knowledge proof that establishes several facts at once, revealing none of the underlying secrets:

• You know a well-formed note whose commitment is in the state tree.
• That note's label is in the published association set.
• You have correctly computed the note's nullifier hash.
• Value is conserved: the amount out plus any change equals the note's value.

The proof reveals only the nullifier hash, the withdrawn amount, the tree roots, and the context. It is generated locally against the served proving key and circuit. No secret crosses the network boundary.

Withdraw

With the proof built, the withdrawal is submitted and the pool verifies it before releasing funds. The contract checks, in order:

• the caller is authorized and the context matches the submitted parameters;
• the referenced state root is known and the association root is the latest;
• the nullifier hash has not been spent before;
• the zero-knowledge proof verifies.

On success the contract marks the nullifier spent, inserts any change note, and transfers the funds to the fresh recipient. The chain now shows an unrelated deposit and an unrelated withdrawal, with no link between them.

Partial withdrawals

You do not have to withdraw a note's full value. The withdrawal enforces a strict accounting identity:

A full withdrawal sets the residual to zero. A partial withdrawal retains the remainder in a new, unlinkable change note under fresh secrets. The circuit range-checks both amounts, so value can never be created through underflow or field wraparound.

Discovery & recovery

Because every note derives deterministically from your recovery phrase, finding your notes is a local operation. The client walks deposit indices, re-derives the secrets for each, and checks whether the resulting commitment appears among the pool's deposits. Matches are your notes; their spent status is read from the on-chain nullifier set.

On any device, the same recovery phrase reconstructs every note. There is no support desk to call and no reset to request, because there is nothing for anyone else to reset. The phrase is the account.

Cryptographic primitives

ra:st rests on three well-studied building blocks, used as mature components rather than new inventions.

Poseidon

An arithmetic hash function designed for efficiency inside zero-knowledge circuits. Every commitment, nullifier, and Merkle node is a Poseidon output. The protocol uses three fixed arities, and the on-chain evaluators are verified to match the in-circuit and client-side computations bit-for-bit.

Lean incremental Merkle tree

An append-only accumulator that commits to a growing set of leaves under a single root, with cheap insertion and compact membership proofs. It grows its depth dynamically instead of padding to a fixed size.

Groth16

A pairing-based zk-SNARK with constant-size proofs (three group elements) and constant-time verification, which is what makes on-chain verification economical. It requires a one-time trusted setup whose ceremony is public and auditable.

The two trees

The protocol maintains two Merkle accumulators with different leaf types, and the distinction is load-bearing for privacy.

A single tree cannot serve both roles without leaking. Keying the association set on labels, which are public per-deposit identifiers carrying no ownership information, lets the approved set be published in full without revealing anything about who owns what. A withdrawal proves state-tree membership of its commitment and association-tree membership of its label, simultaneously and without cross-leaking.

Not a mixer

A mixer hides everyone the same way: clean funds and illicit funds in one pool, indistinguishable. That uniformity is both its strength (strong unlinkability) and its fatal weakness (no honest user can distinguish herself, and it gives equal cover to illicit value). That indiscriminate design is why such systems were sanctioned.

ra:st breaks the uniformity in a privacy-preserving way. Every withdrawal proves membership in an approved set, so honest users keep full privacy while funds that cannot prove clean provenance are excluded from the anonymity set altogether.

Relayers

Submitting a withdrawal directly requires the receiving address to hold gas, which can itself create a link. A relayer removes that friction: it pays gas and submits the withdrawal on your behalf, for an optional fee bounded by protocol parameters.

Relaying adds no trust. Because the recipient and fee are bound into the proof's context, a relayer cannot redirect funds or overcharge, and because the proof is zero-knowledge, it learns none of your secrets. The worst a malicious relayer can do is decline to submit, in which case you route to another.

Security guarantees

The protocol's guarantees are stated and proven in the whitepaper. In plain terms:

• Unlinkability. No observer can correlate a withdrawal with the deposit that funded it, beyond the unavoidable leakage of public amounts and anonymity-set size.
• Balance soundness. The pool cannot be drained beyond what was deposited. No one can withdraw value they did not deposit or manufacture value through malformed proofs.
• Double-spend resistance. No note can be spent twice. The revealed nullifier hash is recorded and re-checked on every withdrawal.
• Compliance soundness. No withdrawal is accepted for a note whose label is outside the published association set.

Integrity guarantees (balance, double-spend, compliance) rest only on standard-model assumptions plus the one-time setup. Privacy guarantees additionally rely on modeling the hash as a random oracle, in line with the literature on note-based privacy systems.

Anonymity set

Cryptographic unlinkability is necessary but not sufficient for privacy in practice. The anonymity you actually get is bounded by how many indistinguishable deposits could plausibly have funded your withdrawal.

Two things erode it:

• Value fingerprinting. A distinctive amount, matched by few deposits, shrinks your anonymity set regardless of pool size. Round, common denominations maximize it.
• Temporal correlation. A withdrawal issued immediately after a single fresh deposit points straight back at it. A delay decorrelated from deposit timing restores cover.

Trust & threat model

The adversary is assumed to see all on-chain state and network traffic, submit arbitrary deposits and withdrawals, act as many users, reorder or delay transactions, and corrupt the relayer. Against this, the guarantees above hold under a small set of assumptions.

Explicitly out of scope

The protocol does not defend against compromise of your device or seed, network-level deanonymization by IP or timing, statistical linkage when amounts are distinctive or the anonymity set is small, or the legal consequences of an ASP's curation policy. These are addressed, where possible, by operational guidance rather than by cryptography.

Fees

The pool charges a small vetting fee on deposit, expressed in basis points and enforced by the contract. It is deducted at deposit time; your note's value is the deposited amount net of the fee, and this net value is what is later withdrawable.

Fees fund the protocol's operation, including the association-set service and ongoing development. The exact rate is a configured parameter, published as part of the deployment metadata so it can be governed transparently rather than hard-coded here.

$RAST token

The protocol's native token is $RAST. Its purpose is to decentralize control over the protocol's few points of human discretion and to coordinate the actors who operate its infrastructure.

Governance covers discretionary parameters such as fee rates, association-set policy administration, and the schedule of progressive decentralization. Infrastructure coordination aligns the incentives of relayers and the association-set service. The quantitative parameters are being finalized and are marked below as to-be-determined rather than stated prematurely.

Roadmap

The protocol develops in stages, each strengthening either its guarantees or its usability. We describe direction rather than fixed dates.

• Core protocol on Robinhood Chain. Deposit and withdrawal live, client-side proving, an ETH pool, and the association-set mechanism. Operational today.
• Association-set automation. Moving root publication from a manual step to a continuously running service, so new deposits become withdrawable without intervention.
• Relayer network. Gasless, origin-unlinked withdrawals, eventually across a decentralized relayer set.
• Multi-asset pools. Extending beyond the native-currency pool to fungible tokens.
• Governance and $RAST. Progressive decentralization of discretionary parameters.
• Independent audit. Security review of contracts and circuits, and publication of the setup ceremony transcript, ahead of scaling to significant value.

Operational security

The cryptography is necessary but not sufficient. A few habits protect the privacy the protocol gives you.

Preserving unlinkability

• Withdraw into a mature pool. Prefer a populous pool and a common amount; avoid being the sole recent deposit of your denomination.
• Decorrelate timing. Introduce a delay between deposit and withdrawal, drawn independently of deposit timing.
• Break network linkage. Use a relayer so the withdrawal and its gas originate independently of you, and consider network-level anonymization.
• Use fresh destinations. Withdraw to an address with no prior history, and do not consolidate it with identified funds.

Protecting the secret

Your recovery phrase is the account. There is no server-side copy, no reset, no recovery. Back it up offline and redundantly, and treat its compromise as equivalent to loss of all associated funds. Obtain the client from a trusted source, since a tampered client could exfiltrate the secret at derivation time.

FAQ

Is this a mixer?

No. A mixer hides everyone indiscriminately and offers no way to distinguish clean money. ra:st requires every withdrawal to prove, in zero knowledge, that it belongs to an approved association set. It is a shielded pool with compliance built in.

Can you freeze or seize my funds?

No. The protocol is built so that no operator, and no administrative key, can move a specific user's funds. Only the note secret, derived from your recovery phrase, can do that.

What happens if I lose my recovery phrase?

Your funds become permanently inaccessible. There is no recovery mechanism, because a recovery mechanism would mean someone other than you could access your funds. Back up your phrase.

Does the deposit reveal my identity?

The deposit reveals that a particular address deposited a particular amount, which is public. It does not reveal your note secret and cannot be linked to your later withdrawal. Your practical privacy depends on the anonymity set and on avoiding timing and network correlation.

Do I have to trust the association-set provider?

Only for one thing: to include your deposit so you can withdraw with privacy. It cannot take your funds, deanonymize your withdrawal, or alter a published set. Its influence is confined to privacy, never to ownership.

Risk disclosures

• Loss of secret. Losing your recovery phrase means losing your funds, irreversibly. This is inherent to self-custody.
• Small anonymity sets. Early in a pool's life, or for unusual amounts, the set may be too small to provide meaningful privacy despite the cryptography.
• Metadata linkage. Timing and network-level observation can link a deposit and withdrawal outside the protocol's cryptographic guarantees.
• Trusted setup. Soundness depends on at least one honest participant in the setup ceremony. The transcript is public and independently verifiable.
• Smart-contract risk. As with any on-chain system, undiscovered bugs could affect funds. Independent audit is on the roadmap and should precede scaling to significant value.
• Regulatory risk. The choice of association-set curation policy carries legal significance that varies by jurisdiction and is the responsibility of the deploying operator.

Nothing in this documentation is financial, legal, or investment advice.

Deployment

The reference deployment targets Robinhood Chain (an Ethereum-compatible execution environment, chain identifier 4663). The instantiated pool is a native-currency (ETH) pool with a configured minimum deposit and vetting-fee rate.

The deployment comprises the Entrypoint proxy and its implementation, the ETH pool, the withdrawal and commitment Groth16 verifiers, the Poseidon evaluator contracts, and an association-root registry administered through the ASP role. Concrete contract addresses, the pool scope, and current configuration parameters are published separately as deployment metadata, so this documentation stays valid across redeployments and parameter updates.

Glossary