> For the complete documentation index, see [llms.txt](https://docs.sectoral.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sectoral.xyz/privacy-and-cryptography/encrypted-amounts.md). # How Amounts Stay Encrypted The whole design turns on one idea: Sectoral hides how much, not who. Your address is visible on Robinhood Chain, while the figures attached to it are not. Every payment can be verified by the network, and none of them can be read by it. The rest of this page explains the mechanics. *** ## The building block Confidential transfers are not something the EVM offers out of the box, so Sectoral wrote and deployed its own confidential token contracts instead of borrowing an existing layer. They implement an ERC-20 with encrypted balances, following the research line that began with Zether. Two techniques do the heavy lifting: * **ElGamal encryption** keeps balances and transfer amounts as homomorphic ciphertext, so the contract can add to and subtract from values it is unable to see. * **Zero-knowledge range proofs**, checked by a verifier contract on-chain, demonstrate that a transfer is sound (the sender can cover it and the amount is not negative) without revealing anything about the amount. The result: the chain accepts a payment as valid and adjusts two encrypted balances accurately, yet never learns the figure involved. *** ## A standard ERC-20 transfer ``` Sender Address [PUBLIC] → Amount [PUBLIC] → Receiver Address [PUBLIC] ``` With nothing more than an RPC URL, anyone can see every amount you have ever sent, for as long as the chain exists. Sectoral exists to end that default. *** ## The same transfer on Sectoral ``` Sender Address [PUBLIC] → Amount [ENCRYPTED] → Receiver Address [PUBLIC] Proof: zero-knowledge evidence that the ciphertext encodes a valid transfer, revealing nothing about how much it moves ``` *** ## Step by step 1. You set up a transfer in the Sectoral app. 2. On your device, the Privacy Engine uses your decryption key to build a ZK proof. The plaintext amount never leaves the device. 3. The ciphertext and proof are submitted to Robinhood Chain as a call to the confidential token contract, with the proof passed in calldata. 4. Within that one transaction, the verifier contract validates the proof and the token contract updates both encrypted balances, with final security inherited from Ethereum via the rollup's settlement. The addresses are public; the amount is opaque and stays that way. 5. The sender and the recipient each hold a private decryption key and can read the amount. No one else can. 6. If someone has a legitimate reason to see a particular payment, you create a disclosure proof covering only that payment. Details are in [Showing Proof of a Payment](/privacy-and-cryptography/proving-a-payment.md). *** ## Why it matters Public ledgers achieved verifiability by exposing everything. That suits analysts and fails the people holding the accounts: a stranger can follow your paycheck coming in, your rent going out, and your company's cash running down, live and permanently. Sectoral holds on to what is valuable (the network still checks and permanently records every transfer) and drops the surveillance that used to come with it. Once software is transacting around the clock, full exposure stops being an acceptable starting point. *** ## What the privacy costs you Proof generation happens on the client, in WASM, inside the browser or the mobile app. Modern hardware finishes it in under a second before submission, which you will barely notice. On devices that cannot keep up, a server-assisted path takes over, working only from proof inputs derived on the client; in no configuration is the plaintext amount ever sent. *** ## Read next * [Showing Proof of a Payment](/privacy-and-cryptography/proving-a-payment.md) * [Keys and Account Recovery](/privacy-and-cryptography/keys-and-recovery.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.sectoral.xyz/privacy-and-cryptography/encrypted-amounts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.