How it works
Threat model
Who UMBR defends against, what each party can and cannot do, and the gaps we know about.
- Protects
- Amounts, links, balances
- Trusts
- Your device, the circuits
- Status
- Testnet, unaudited
What we protect#
- The amount of each payment made inside the pool.
- The link between sender and recipient inside the pool.
- Your private balance and history.
- Your funds: only the holder of a note's spending key can move it.
- The scope of a proof: a reader learns its statement and nothing else.
We do not try to hide that you use UMBR, what you deposit or withdraw at the boundary, or network metadata from the services you connect to.
Who can do what#
| Actor | Can | Cannot |
|---|---|---|
| Public observer | Read every transaction: deposits, withdrawals, gas payers, timing, commitments and nullifiers | Read amounts or links between notes inside the pool, or your balance |
| RPC provider | See your IP, which contracts and blocks you query, and transactions you broadcast directly | Decrypt notes or forge state the contract will accept |
| Relayer | See your IP and timing; refuse or delay a submission | Change the destination or fee, which are bound inside the proof, or learn your balance |
| Frontend host | See your IP and page loads; serve modified code to you | Read your keys or notes, as long as the code it serves is honest |
| Recipient | See the payment and memo you sent them, and share it | See your balance, other payments or where your funds came from |
| Proof reader | See the one statement in the proof, its audience and its expiry | See anything the proof does not state |
| Contract admin or upgrade | If the pool is upgradeable, change rules for future transactions or pause it | Read past notes; spend notes without the owner's key under the published rules |
| Compromised device | Read your keys, notes and history, and spend your funds | Nothing UMBR does protects you here |
Details that matter#
The frontend is part of the trust base
The browser app holds your keys while it runs. A host that served altered code could steal them. Proof generation on the client protects you from a curious server, not a malicious one. Builders who need more assurance can run the SDK from their own code and pin its version.
The relayer can censor, not steal
The recipient address and the relayer fee are public inputs to the proof. Changing either makes the proof fail. A relayer can still drop your transaction. If it does, submit from your own wallet, accepting that the wallet then appears as gas payer.
Root history
The contract accepts proofs against a recent window of Merkle roots. A proof built against a root that has fallen out of the window is rejected with UNKNOWN_ROOT, and the app rebuilds it. Nothing is spent.
Trusted setup
Groth16 needs a one-time setup per circuit. If every participant in it were dishonest and kept their secret, they could forge proofs. Testnet keys come from a development setup; a multi-party ceremony is a condition of the production gate.
What we assume#
- Your device and browser are not compromised.
- The circuits correctly encode the rules, and the setup was not fully corrupted.
- The cryptographic primitives (Groth16 over BN254, Poseidon) hold.
- The underlying chain orders transactions and does not reorganize deep history.
- Enough other people use the same pool for your activity to blend in.
Known gaps#
- No external audit of the contracts or circuits yet.
- Testnet pools are small, so the anonymity set is small.
- The relayer is a single operator today. It can see IP addresses and delay transactions.
- Notes live on one device by default. Backup is manual; losing the device without one loses the funds.
- Note scanning grows with pool size and may be slow on low-end phones.
- Sealed trade is switched off; its public swap step would reveal amounts.
Out of scope#
- Attacks on the underlying chains, their sequencers or bridges.
- Malware, phishing or a stolen unlocked device.
- Global network observers correlating traffic across the internet.
- What recipients or proof readers do with information you gave them.
- The sealed trade path while it is switched off.
Reporting a problem#
Send a direct message to @umbrtrade on X starting with security. Keep exploit details out of public replies. Include what you found, how to reproduce it and which network you used. Please give us reasonable time to fix it before you publish. We will reply, credit you if you want, and say plainly what we changed.
Testnet only