Privacy model
Hushd hides who traded and how much. It does not hide that money entered or left the pool, or that a deal happened. Here is the whole picture, including what can leak.
Who sees what
| What | Who can see it |
|---|---|
| A deposit: your NEAR account, the token and the amount | Anyone |
| A cash out: the receiving account, the token and the amount | Anyone |
| That a private transfer happened: a pool call from the relayer with two new notes | Anyone |
| Who paid whom inside the pool, and how much | The two sides only |
| Your private balance | You only |
| A claim link, and so its amount and the right to claim it | Whoever holds the link |
| Your request: your limit, the deal's one-time address, your words | You and the matcher enclave |
| The ask: the package kind, the pair, the side and the size | Each registered maker |
| Quotes, including the ones that lose | The maker that made each, and the enclave |
| That a deal happened: its maker, class, expiry, bond, outcome and evidence | Anyone |
| A hedge order: the coin, the side, the size and the limit | Anyone, on the desk and on Hyperliquid |
| The agreed amounts, and the address the maker pays: one made for that deal alone | The trader and the winning maker |
| That a deal room message was sent: its deal, size and time, and the key it is sealed to | The API, until the deal settles or closes, and a day at most |
| Your words to the intake | You and the attested model |
| The fact a proof shows | Whoever holds the proof |
What is public, and why
Deposits and cash outs. Tokens move between a NEAR account and the pool, so the token contract records the transfer like any other: the account, the token and the amount. That is the boundary of the private balance.
Desk deals. A deal is a public record on the desk, so that both sides, and anyone else, can see it was matched by the enclave, settled by the pool and closed with a receipt. The record holds the maker, the settlement class, a hash of the terms, the expiry, the bond and the outcome with its evidence. It does not hold the amounts or the trader.
Hedges. A hedged deal carries its Hyperliquid order in the deal record, because the desk rebuilds and signs that exact order. The order is public on Hyperliquid too. It is signed from an address derived for that deal, but that address trades for the maker's own Hyperliquid account, so all of one maker's hedges show together on that account.
Makers. Makers are public, like any market maker: their account, name, style, bond, deal count and anything slashed.
What is private
Inside the pool, a note is a Poseidon commitment to an owner, an amount and a token. Spending one reveals a nullifier, which cannot be linked to the note it spends without the owner's key. A private transfer shows two new commitments and two nullifiers, sent by the relayer: not the sender, the recipient or the amount. A desk settlement shows four of each, the same way.
Word of a payment goes on the board as a ciphertext sealed to the recipient. The board never records who posted, and every recipient reads every post and keeps what opens for it, so nobody learns who a post is for.
Sanctions screening
Hushd screens public addresses only: the NEAR account a deposit comes from, the NEAR account a cash out pays, and the address on another chain that a deposit or a cash out through NEAR Intents uses. It never screens a note, a hushd1… address or an amount.
The list is a dated snapshot of the digital currency addresses on OFAC's SDN list, kept in the SDK as hashes and rebuilt from OFAC's own file by a script. The app checks before you sign, so the check needs nothing from a server; the API answers POST /v1/screen for agents and other clients; and the relayer checks a cash out's recipient again before it sends it. A listed address sees one line, “This address can't be used with Hushd.”, and nothing else.
Claim links
Paying as a link pays a one-time note and puts what opens it in the link itself, after the #. Browsers never send that part to a server, so neither the app nor the API sees it. On chain, paying into a link and claiming it are two private transfers sent by the relayer, like any other.
The link is the payment: whoever opens it first can claim it, so share it the way you would share cash. Claiming moves it into a new note made in the claimer's browser for their own key, so once it is claimed the payer cannot take it back. Until then, the payer can. Anyone who opens a spent link sees only that it was already claimed, not by whom or whether it was taken back.
What can leak
- Timing and amounts. A deposit of an odd amount followed soon after by a cash out of the same amount links the two, whatever happened in between. Waiting, and moving round amounts, helps.
- A small crowd. On testnet, few people use the pool, so the set of notes you hide among is small.
- A hedged deal's size. The desk takes a bond only in fixed steps (its minimum times 1, 2, 5, 10, 20, 50 and so on), so a public bond says only which step the trade falls in. The hedge order is different: it runs on Hyperliquid, a public venue, so its size is in the deal record and on Hyperliquid. A spot deal has neither a bond nor a hedge. On Hyperliquid, every hedge a maker places shows on that maker's account, whichever per-deal address signed it.
- Your receive address. The winning maker never learns your hushd1… address. Your sealed request names an address your wallet made for that deal alone, the maker pays your note to it, and your wallet then moves the note into your balance with a private send. The maker cannot tell from the address that two of its deals came from you; it still sees each deal's pair, size and time, which can hint at it.
- Deal rooms. The two sides of a deal swap sealed messages through the API. It files the maker's under the maker's public key, and the trader's under a key the trader's wallet made for that deal alone, so nothing it holds says which deals a hushd1… address took part in. It sees each message's deal, size and time, and deletes a room once its deal settles or closes on the desk, and any message after a day.
- Request metadata. The API and the relayer see the network side of your requests: when they arrive and from which IP address. Use a VPN or Tor if that matters to you.
- Proofs you share. A proof can be forwarded. It says who it was made for, but whoever holds it learns the fact it shows, and for a deal leg, which deal it was.
Who you trust, and with what
| Who | Trusted with | Never trusted with |
|---|---|---|
| The relayer | Sending your actions, and not logging their metadata | Your keys, your notes, or what a proof binds (recipient, fee, refund note) |
| The matcher enclave | Keeping your request, your limit and the quotes private, and picking the best quote (your client refuses one below your limit) | Your notes: it never sees a spending key |
| The intake model | Keeping your words private inside its TEE | Anything that moves money: it only drafts |
| The API | Passing sealed messages on, deleting deal rooms once their deals are done, and not logging their metadata | The content of any request, quote or deal room message, or which deals a hushd1… address took part in |
| The matcher client | Putting every sealed quote from the API's database into the enclave's batch: the enclave cannot tell if one is left out | The content of a request or a quote, or forging a match |
| The keeper | Reporting truly whether a hedge order filled: the desk releases or slashes the maker's bond on its word | Changing a hedge order, or moving a note |
| The desk owner | Proposing desk settings (the keeper, the pinned matcher build, the minimum bond), which apply only after a public one-day timelock | Your notes, your deals' terms, or a pool rule change without the pool's own timelock |
The enclave's privacy rests on the TEE it runs in: an Intel TDX worker on OutLayer running the matcher code the desk pins. The model's rests on NEAR AI Cloud's attested TEE. Both are stated in full in the threat model.
On your device
- Your notes are kept in your browser's storage, encrypted with AES-GCM under a key from your seed. Every note you make for yourself is also on the board, sealed to you, so the seed alone recovers your balance.
- With a NEAR wallet, the seed is a signature your wallet makes again each time you open the balance. Nothing secret is stored.
- With a passkey, the seed comes from the passkey itself, and the browser remembers only which account it opens.
- Links you paid are kept only in that encrypted store, not on the board. If it is cleared, you can no longer take back an unclaimed link, though the link still works for whoever holds it.