Search
Search for projects by name or address
Umbra Cash
About
A stealth-address payment protocol that hides the recipient behind a fresh address for every transfer.
About
A stealth-address payment protocol that hides the recipient behind a fresh address for every transfer.
Umbra Cash is a stealth-address payment protocol. A recipient registers separate viewing and spending public keys, and a sender uses them to derive a fresh address that only the recipient can control. The sender transfers ETH directly to that address or routes an ERC-20 payment through the immutable Umbra contract, which emits the encrypted data needed to access the payment.
Privacy considerations
Umbra is not a mixer and does not use zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information. proofs or an anonymity pool. The sender, amount, token, and fresh receiving address remain public. Privacy comes from hiding the identity of the person controlling that address.
Although not enforced by the protocol, Umbra Cash users register their public keys on StealthKeyRegistry. On one hand, this allows stealth transfers between the sender and the recipient without exchanging any data offchain. On the other hand, stealth transfer recipients are very likely to be among the registered addresses, which reduces recipient anonymity setIn privacy protocols, anonymity set denotes all users, to which a particular withdrawal could be plausibly attributed. Anonymity set depends on a particular withdrawal, the size of the anonymity set is a metric for level of user's privacy..
What the protocol promises: Hides which registered recipient a stealth payment is for. The payer knows; sender, asset, amount and where the funds go next are public.
On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note.
Announcements mark each stealth payment but not the recipient whose keys were used. The registry publishes the candidate recipients and their key history.
Advice: Withdraw to a fresh address with no ENS name or prior activity, through the token relayer so your known wallet never funds the stealth address for gas. Keep funds from different stealth addresses apart.
Protocol use is public once a payment is announced, which narrows the anonymity set to registered recipients. Withdrawals to registered addresses, round trips back to the sender and a shared collecting address reveal or cluster recipients; membership alone does not identify them. The client withdraws one stealth address at a time and never merges them.
Advice: Keep withdrawal destinations separate across payments and chains, and check that timing, amounts or recurring counterparties do not reconnect them to an identified account.
On the payer's side the wallet RPC resolves the recipient, reads their registry entry and broadcasts the stealth payment seconds apart, so that provider can pair the payment with the recipient. On your side the wallet RPC receives the matched stealth-address balance batch, while a build-configured mainnet RPC looks up your connected wallet and the senders of matched payments, and withdrawal destinations are checked against ENS, POAP and Gitcoin APIs.
Advice: Run an inspected local build with every RPC pointed at your own node and the external name and safety lookups disabled. Send broadcasts and relay requests over Tor.
The contracts are immutable and give no administrator a viewing key or a way to replace registered keys without the registrant. The client matches announcements locally, so no indexer or relayer has a protocol-wide view.
Advice: Run an inspected local build of the client instead of the hosted frontend.
Each announcement stores the ephemeral public key and the encrypted scalar. A quantum computer that breaks secp256k1 decrypts the scalar against every registered viewing key and checks which spending key yields the stealth address, identifying the recipient of every past payment.
Asset | Deposits 7D | Deposits 30D | Deposits Total |
|---|---|---|---|
 DAI | 0 $0.00 | 0 $0.00 | 173 $804.10 K |
 ETH | 149 $4.48 M | 328 $10.24 M | 23.73 K $118.69 M |
 USDC | 0 $0.00 | 10 $130.08 K | 707 $4.60 M |
 USDT | 0 $0.00 | 20 $387.91 K | 646 $6.49 M |
 WBTC | 0 $0.00 | 0 $0.00 | 162 $11.22 M |
| Total | 149 $4.48 M | 358 $10.76 M | 25.41 K $141.82 M |
Funds can be lost if
- an unsupported ERC-20, such as a fee-on-transfer or rebasing token, causes the Umbra contract’s internal accounting to diverge from its token balance.
Privacy can be lost if
- a recipient sends funds from a stealth address to a publicly linked address or consolidates payments in a recognizable way.
- public timing, amount, token, or ENS registration patterns let an observer narrow down the possible recipient.
New payments can be stopped if
- the Umbra owner sets an arbitrarily high toll for contract-routed payments.
Umbra has no governance process or contract upgrade mechanism. The Umbra and StealthKeyRegistry contracts are immutable.
The Umbra contract has a permissioned owner that can immediately set the ETH toll charged on every contract-routed payment and change the addresses that collect and receive those tolls. Because the toll has no upper bound, the owner can effectively stop new payments through the Umbra contract at any time. The owner cannot change the payment or withdrawal logic and cannot prevent recipients from accessing payments already sent to them, so the exit windowThe amount of time that users have to exit a system before an unwanted upgrade. It takes into account upgrade delays, forced transaction delays and other time factors. To be considered Stage 1, a rollup needs to have an exit window of at least 7d if upgrades are initiated by a permissioned actor less decentralized than a Security Council. For Stage 2, a rollup needs at least 30d in all cases outside of onchain provable bugs. is infinite and the protocol passes the walkaway test.
2026 August 17, 09:44 UTCHigh severity3changes7702 delegation.
7702 delegation.
| EOA (eth:0xb4435399AB53D6136C9AEEBb77a0120620b117F9) { | |
| +++ description: None | |
| proxyType: | |
| - | "EOA" |
| + | "EIP7702 EOA" |
| sourceHashes: | |
| + | ["0x1f44812af62d28f019e30e8eb2af596fb36c7db9d34576972c0405e110a6ef45"] |
| values: | |
| + | {"$implementation":"eth:0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B","delegationManager":"eth:0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3","DOMAIN_VERSION":"1","eip712Domain":{"fields":"0x0f","name":"EIP7702StatelessDeleGator","version":"1","chainId":1,"verifyingContract":"eth:0xb4435399AB53D6136C9AEEBb77a0120620b117F9","salt":"0x0000000000000000000000000000000000000000000000000000000000000000","extensions":[]},"entryPoint":"eth:0x0000000071727De22E5E9d8BAf0edAc6f37da032","getDeposit":0,"getDomainHash":"0x9962d46a78b1e6906da83f5bd75621a608112e6b851709d6504888d73d532e1c","getNonce":0,"NAME":"EIP7702StatelessDeleGator","PACKED_USER_OP_TYPEHASH":"0xbc37962d8bd1d319c95199bdfda6d3f92baa8903a61b32d5f4ec1f4b36a3bc18","VERSION":"1.3.0"} |
| } | |
2026 July 31, 11:57 UTC2changesInitial discovery of Umbra contracts
Initial discovery of Umbra contracts
Initial discovery
| + | Status: CREATED |
| contract StealthKeyRegistry (eth:0x31fe56609C65Cd0C510E7125f051D440424D38f3) [N/A] | |
| +++ description: Public registry that maps an Ethereum address to its two secp256k1 stealth public keys: a spending key used to derive a fresh stealth address, and a viewing key used to encrypt the transfer metadata for the recipient. | |
| + | Status: CREATED |
| contract Umbra (eth:0xFb2dc580Eed955B528407b4d36FfaFe3da685401) [N/A] | |
| +++ description: Main entry point of the Umbra protocol, routing all ETH and ERC-20 stealth payments. On send, it emits an Announcement event that the recipient scans to detect the payment. ETH is forwarded directly to a fresh stealth address, ERC-20s are escrowed in this smart contract. | |
Ethereum
Actors:
- Can interact with Umbra
- set an arbitrary ETH toll that must be paid on every transfer routed through the Umbra contract
Ethereum
Public registry that maps an Ethereum address to its two secp256k1 stealth public keys: a spending key used to derive a fresh stealth address, and a viewing key used to encrypt the transfer metadata for the recipient.
Main entry point of the Umbra protocol, routing all ETH and ERC-20 stealth payments. On send, it emits an Announcement event that the recipient scans to detect the payment. ETH is forwarded directly to a fresh stealth address, ERC-20s are escrowed in this smart contract.
- Roles:
- owner: EOA 1