# Managing your note Your **deposit note** is the single most important thing in this protocol from a user's perspective. This page covers what the note is, how to keep it safe, and what happens in various failure modes. ## What's in a note A note string looks like: ``` tonado-ton-1-testnet-0xa8b2...c4ef ``` It's a flat string with four parts separated by `-`: | Part | Meaning | | ------------------------- | ------------------------------------------------------------------------------- | | `tonado` | The protocol identifier. Always `tonado`. | | `ton` (or `jetton:EQ...`) | The asset. `ton` for native TON; for a Jetton it's `jetton:`. | | `1` | The denomination. Always exactly the pool's denomination. | | `testnet` (or `mainnet`) | The network. | | `0xa8b2...c4ef` | A 62-character hex string. The encoded `(nullifier, secret)` pair, your secret. | The last part is the only sensitive piece. It is **the key to your deposit**: anyone who has this string can withdraw your funds to any recipient they want. Anyone who *doesn't* have it cannot, even if they control the entire rest of the system. ## What the note proves The note encodes the pre-image `(nullifier, secret)` to your commitment `Poseidon(nullifier, secret)`. When you withdraw, you produce a zero-knowledge proof that says: *"I know a `(nullifier, secret)` whose Poseidon hash is in the pool's Merkle tree."* Without the note, you can't construct the witness for that proof, and the on-chain verifier will reject any forgery attempts. ## How to back it up Treat the note like cash, except cash that's worth exactly the pool's denomination and that anyone who finds it can spend. **Good options:** * A password manager entry (1Password, Bitwarden, etc.) under an entry like "TONado Cash 1 TON deposit, testnet, 2026-05-16". * An encrypted text file on a USB drive stored offline. * A printout in a safe. * A handwritten copy in two physically separate locations. **Bad options:** * Plaintext in your email or chat history. * Plaintext in a synced note-taking app. * A photo on your phone that backs up to cloud storage. * Anywhere accessible to a script with your shell history (the CLI does not log notes to disk, but if you paste it into something else, you might). ## What you give up if you lose the note Everything. The deposit becomes unrecoverable. Nobody can help you (not the project team, not the relayer, not the contract owner; on mainnet, there isn't one anyway because the admin key is burned). The deposit's commitment will remain in the pool's Merkle tree forever, eligible for withdrawal by anyone with the note. Since only you ever had it, the funds are stuck. This is the unavoidable tradeoff of non-custodial privacy. If a third party could recover your funds, they could also steal them. ## What you give up if someone else gets the note Everything. The thief can withdraw to any recipient they choose. Once the note is shared, you have no defense. If you suspect your note was leaked, **withdraw immediately** to your own address. Even at the cost of privacy, recovery beats theft. Use `tonado withdraw self` to skip the relayer (saves a fee, marginally faster) or use a relayer to a known recipient. ## Verifying a note (before withdrawing) You can decode a note without making any network calls: ```bash tonado note parse "tonado-ton-1-testnet-0xa8b2...c4ef" ``` This prints the asset, amount, network, and the derived commitment + nullifier hash. Useful for sanity-checking that the note string is well-formed and corresponds to the deposit you remember making. To verify the note is actually on-chain and unspent: ```bash tonado note check "tonado-ton-1-testnet-0xa8b2...c4ef" --network testnet ``` `note check` queries the pool's `is_spent` get-method directly. It does **not** require a relayer. ## When to withdraw A reasonable default: wait at least **24 hours after depositing** and at least **a handful of other deposits** between your deposit and your withdrawal, so the anonymity set has grown. There's no maximum; your note never expires. The only timing constraints are: * The pool keeps **30 most recent roots** in a ring buffer. A withdrawal proof has to reference a root in that ring. If 30+ new deposits land between when you build your proof and when you submit it, your proof becomes invalid. In practice the relayer rebuilds the proof against the latest root on submission, but if you build the proof yourself and sit on it for a long time, it can go stale. Solution: rebuild and resubmit. * Eventually, ancient deposits may be hard to recover if archive nodes prune their tx history. TON mainnet archives generally retain forever; testnet sometimes prunes after a few months. ## What if I deposited but the note is malformed If `tonado note parse` errors but you have a record of your `(nullifier, secret)` and `commitment`, you can manually reconstruct the note format using [`packages/core/src/notes.ts`](https://github.com/tonadocash/monorepo/blob/main/packages/core/src/notes.ts). The note string is just a serialization; the secret is the only thing that matters cryptographically. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tonadocash.com/using-tonado-cash/managing-your-note.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.