Disclosure
What we hide, and what we do not
Every row below names the adversary a claim holds against. A claim without a named adversary is not shipped, because the reader cannot check it and we cannot be held to it. The front page carries the featured rows as TABLE 01; this is all of them.
Read the status column first
Most of this is planned and not built. The rows are written now so the design is committed to in public before there is any incentive to soften it.
| Pillar | Status | Hides | Does not hide |
|---|---|---|---|
| Stealth receive | Live | The link between your public identity and the address that received the asset. Positions never aggregate into one readable portfolio. | Amounts, timing, and the sender. The caller recorded on the announcement is whoever paid the gas. Funding a stealth address from your own wallet re-links it, and consolidating several of them later re-links all of them at once. |
| Network layer | Planned | Your network provider cannot read or forge the lookups the app makes. The default endpoint operator never sees your address paired with your network address. | It is not a tunnel for your whole machine. The destination remains visible, and the server name is in the clear unless the connection encrypts it. It also makes us the party able to see that pairing. The only thing that limits us is architecture that never records it, plus this page telling you so. |
| Permit relay | Planned | That you paid the gas. The relayer is the on-chain payer, which is what makes a zero-gas address usable at all. | We see every request: the address, the asset and the amount, plus your network address unless you route around us. The resulting transfer is an ordinary public token movement with a public amount and timestamp. |
| Routing fee | Planned | Nothing on its own. Its privacy comes only from being composed with a stealth address. | The trade itself. A pool's reserve change is visible forever and the amount is derivable from it. There is no public pending-transaction pool on chain 4663, so protection from front-running is not something we can honestly claim here, in either direction. |
| Sealed quotes | Planned | Each counterparty from the other. Quote sizes and prices stay invisible to other participants until a fill. | Our server, which sees every quote and both sides. That is where the sealing lives, and it is a trust assumption rather than a cryptographic one. A chain analyst still sees two addresses trade, with the amount and the timing in the clear. |
| Staking | Planned | Nothing. This is an access mechanism, not a privacy mechanism, and it is listed here so it is never mistaken for one. | Staking is a public act tied to an address. A user who stakes from the same wallet they receive stealth payments into has linked the two themselves. The interface will say so at the moment of staking, not afterwards. |
Two things no design of ours can fix
The sequencer can refuse a transaction. A filtering mechanism is registered and real on chain 4663, and it can fail transactions including ones forced in from the settlement layer. Nothing we deploy changes that, so we will never describe this product as resistant to censorship, and no part of the design treats forced inclusion as an escape hatch.
The stock tokens are not ours and can change. They are upgradeable proxies over one shared implementation with one shared blocklist, controlled by their issuer. What is true today can change under the same address with no notice. We re-read them before every release and publish what we find.