How the desk works

The parts

1. The request

Your request says which package you want, what you sell and how much, what you buy and the least you accept of it (your limit), how long a quote must hold once matched, and, for a hedged package, which Hyperliquid perp to use. It also carries your hushd1 address, the note a slashed bond would be paid to, and a public key made for this deal alone (the owner key, which closes a hedge). If you used the intake, your words are in it too.

The request is sealed to the matcher's X25519 key, which the desk fetched from the enclave through OutLayer. The relayer then calls open_rfq on the desk with the sha256 of the sealed box and the quote window. The API stores the sealed box only after checking that its hash is the one committed on chain, and it cannot open it.

2. What makers see

Each active maker gets its own copy of the ask, sealed to its key: the package kind, the token and amount you sell, the token you want, and the hedge coin. Never your limit, your address or your words: nothing in the ask says whose request it is.

3. Quotes and the match

A maker that wants the trade prices it and signs its consent to the exact terms with its quote key: the request id, the hash of the terms, the bond it puts up and the quote's expiry. It seals the signed quote to the enclave and posts it. Nobody but the enclave can read it, other makers included.

When the window closes, the matcher client hands the enclave the sealed request and every sealed quote. The enclave:

1. opens the request and checks it is the one committed on chain,
2. opens each quote and drops any the maker did not really sign,
3. keeps the quotes for this exact pair and size that meet your limit and are still valid,
4. picks the one that gives you the most, and
5. returns a match signed with its own key, with the agreed terms sealed to you and to the winning maker.

Losing quotes and your limit never leave the enclave. The desk accepts a match only from OutLayer's on-chain callback (yield and resume) or signed by the enclave's key. It then checks the maker signed these terms with its registered quote key, is active, and has enough free bond, and records the deal: its maker, settlement class, terms hash, expiry and bond. The amounts are not in it.

4. Settlement

Both sides settle the spot leg the same way, through a sealed deal room on the API:

1. Each side picks its notes and makes two outputs: a note for the other side, and its own change.
2. Each sends the other its two output commitments and the opening of the note it made for them, sealed to them.
3. Each checks the note it was sent opens to the agreed token and amount under its own receive key (the trader's is the deal's one-time key), and that it is the output the other side committed to.
4. Each proves its own leg, bound to the deal id and all four outputs. Neither leg can be replayed alone or paired with another.
5. Each signs hushd.settle.v1:<desk>:<deal id>:<the four outputs>: the trader with the deal's owner key, the maker with its quote key. A proof only says a leg belongs to this deal, and anyone can prove empty legs; the two signatures say both parties agreed to exactly these outputs.
6. The maker submits both legs and both signatures through the relayer to desk.settle, which checks the signatures, and the desk calls pool.settle_swap: both proofs and both bindings are checked, and all four spends and four new notes are applied in one receipt. Both happen or neither does.
7. The maker paid your note to an address your wallet made for this deal alone, named in your sealed request instead of your hushd1… address. Your wallet moves that note into your balance with a private send through the relayer, at no gas, and tries again on its next sync if the move does not go out.

The relayer checks both proofs and both signatures off chain, and that every note is unspent, before it sends anything. A bad submission does not end the deal: the two sides can try again until it expires.

Last look

You prove your leg first and hand it to the maker, and the maker submits both. Until the deal expires, the maker holds a leg it can use or drop: it can wait and settle only if the price still suits it. Walking away costs it no bond: a spot deal has none, and a hedged deal's bond is released when a deal expires unsettled. Nothing of yours moves unless both legs settle together, but the quote is firm for you and an option for the maker.

The lapse is public, and it costs the maker future requests. Every deal ends with a receipt on the desk that names its maker. Before a request goes out, openRfq in the SDK (which the app and the MCP server use) counts each maker's last 20 deals that ended in the past week: settled, or lapsed (expired without settling, or a hedge it missed). A maker that let more than 25% of them lapse is not asked. A maker is judged only once 5 of its deals have ended, so a new one is asked from the start, and a skipped maker is asked again once its lapses are more than a week old. Each maker's record is on the makers page, and readMakerRecords counts it for anyone.

The desk cannot tell which side let a deal expire, so a deal the trader walked away from counts against the maker too; the threshold leaves room for that. The rule is the client's, not the contract's: code that does not use openRfq can still ask any maker.

5. The receipt

Every deal ends with a receipt on the desk, graded by its evidence. A spot deal is settled once the pool applies it, with the pool's leaf index and root as evidence. A hedged deal stays unresolved until its hedge leg is done: settled with the Hyperliquid fill, or recovered when a missed hedge pays the bond to you. A deal nobody settles before its expiry is marked failed, and its bond is released. On a hedged deal the keeper reports the hedge leg, and the desk settles or recovers it on that report. See packages.

Plain-language intake

On the desk you can describe a deal in your own words. A model on NEAR AI Cloud turns them into a draft request, and the draft fills the form for you to check.

• The API fetches the model's attestation and verifies it with @nearai/inference-sdk: an Intel TDX quote and NVIDIA GPU evidence. The browser gets the model's signing key from that attestation.
• Your browser encrypts the instructions and your words to that key (X25519 from its ed25519 key, HKDF-SHA256, XChaCha20-Poly1305). The API only adds its API key, and neither it nor the NEAR AI gateway can read the text.
• The answer comes back encrypted to a one-time key in your browser, which then checks the TEE's ed25519 signature over the exact request and response.

You can check a model's attestation yourself at cloud.near.ai/verify. If the API has no NEAR AI key, the intake is off and the form works as usual.

Who can do what

What that rests on, and what it does not cover, is in the threat model.