Architecture
The parts of ephemeral, who runs each one, what each can and cannot do, and how a payment moves through them.
Status: the client beta opens to partners and early testers first, then to everyone.
ephemeral adds no contract between the sender and the receiver. A payment uses two public contracts that already exist on Ethereum and four other chains, plus software that runs on your device. Everything else is optional.
Components
| Component | Runs where | Can | Cannot |
|---|---|---|---|
| Client | Your browser | Derive your keys, scan announcements, build and sign your transactions | Send your keys anywhere; act without your wallet's signature |
| ERC-5564 Announcer | Ethereum, Arbitrum, Base, Optimism, Polygon | Emit an Announcement event for anyone who calls it | Hold funds, block a caller, read anything private |
| ERC-6538 Registry | Same chains | Store the meta-address an address chose to publish | Change an entry it does not own; hold funds |
| Name gateway next | Our server, behind an ENS resolver | Answer a name lookup with a fresh stealth address and publish its announcement | Hold keys, move funds, see what you do with a payment |
| RPC provider | Your choice | Serve chain data to your client | See your keys; learn which announcements are yours from scanning |
| Gas tank next | Contracts and a sponsor service | Pay gas for a withdrawal from a stealth address | Move the funds it sponsors gas for |
| Contract | Address on every listed chain |
|---|---|
| ERC-5564 Announcer | 0x55649E01B5Df198D18D95b5cc5051630cfD45564 |
| ERC-6538 Registry | 0x6538E6bf4B0eBd30A8Ea093027Ac2422ce5d6538 |
Both contracts are shared infrastructure of the ERC-5564 ecosystem, not ours.
No upgrades, no operator
- The client never sends a private key, the viewing key included, off your device.
- No contract of ours sits in the payment path, so nothing of ours can be upgraded, paused or drained to affect a payment.
- If ephemeral disappears, payments that already landed stay yours: any ERC-5564 client with your keys can find and spend them.
Flow 1: register
- You connect a wallet. The client asks it to sign one fixed message.
- The client derives the spending and viewing keys from that signature, in the browser. See Key concepts.
- Optionally, you send one transaction that writes your meta-address to the ERC-6538 registry. It reveals only that your address accepts stealth payments.
Flow 2: send
- The sender enters a meta-address, a name, or a normal address that has a registry entry.
- The client draws a fresh random key, computes the stealth address and the view tag. See Stealth address math.
- One transaction pays the stealth address and calls the Announcer, so the payment and its announcement can never be separated.
- Before signing, the client shows what will be public: the sender, the amount and the new address.
Flow 3: receive
- The client fetches
Announcementevents from the chain through your RPC provider. - For each one it computes the shared secret with your viewing key and compares the view tag. For an announcement that is not yours, that stops 255 times out of 256.
- On a tag match it derives the expected address and compares it with the announced one. A match is your payment.
- Balances are read for your stealth addresses only.
Flow 4: withdraw
- You choose a payment and a destination.
- The withdrawal policy engine checks the move against the known leaks, H1 to H5, and blocks or warns. See Withdraw without leaking.
- The client derives that stealth address's private key, signs the transfer locally and broadcasts it.
What this design trusts
Read the trust model for every party in detail. In short: the cryptography of secp256k1 and keccak256, your own device and wallet, and the honesty of chain data your RPC returns. Nothing else is needed to receive and spend, except for payments to a private name, which rely on the gateway to publish the announcement.