Running a gateway
devnet preview — all data is replayA gateway is anything that carries someone else's order to the market: a wallet, a terminal, an agent framework, an app. It charges a fee the buyer signed for, keeps all of it, and gets nothing else — no priority, no better price, no private access. There is no application to file and no permission to receive.
The mechanism
Two signed objects, both the buyer's. A relay fee approval is a spend budget: it names your address and the caps you may charge against, and the buyer signs it once. Each order then carries a relay attribution naming you, the rate it requests, and its own cap, bound into the order's signature.
Settlement pays you directly from the order's escrow, on success only, as cumulative deltas so a fee can never be charged twice. A failed or refunded order pays nothing.
What the buyer controls
Your fee is bounded four ways at once, all of them the buyer's signature, all enforced by the chain rather than by policy:
| cap | what it bounds |
|---|---|
| rate | max_fee_bps — the highest rate the gateway may request, in basis points of the order's gross. |
| per lease | max_fee_per_lease — the most any single order can pay it, whatever the rate implies. |
| in total | max_total_fee — the cumulative ceiling across every order sharing the approval. When it is exhausted, the gateway earns nothing more until you sign a new one. |
| per order | fee_cap on the attribution the order itself carries — your per-request ceiling, signed with the order. |
The buyer can also end the arrangement unilaterally. A signed revocation retires the approval from that block forward: orders already created keep the fee they reserved, and nothing new can reserve against it. You are not consulted, and there is nothing for you to release — the SDK's signRevokeRelayApproval is the whole procedure.
Why this is neutral
The address that collects a relay fee is an ordinary account. There is no gateway registry, no bond, no allow-list, and no approval step — the kernel checks a signature and a cap, not an identity. Two consequences follow, and both are structural rather than promised:
- The venue takes no cut of your fee. What the buyer approved for you is credited to you; the protocol fee is a separate, seller-side charge that exists whether or not a gateway is involved.
- Carrying an order buys no advantage. Orders clear in a per-block uniform-price auction at one price for everyone. A gateway cannot jump the queue, move the clearing price, or see an order book that others cannot — there is none to see. Every buyer can also walk up to the market directly, so a gateway competes on experience or not at all.
What you can run today
Devnet only, and not yet a way to serve other people. The relay you can run today (relay-server) embeds its own ephemeral chain: state resets when it restarts and is private to that process. Pointing it at a shared public network is the remote-node transport, which is tracked and unbuilt — so nobody can operate a gateway for real buyers yet, including us. What is real now is the settlement mechanism above: it is exercised end to end on every devnet order, and the fee arrives where the buyer's signature said it would.
The reference relay this site runs charges 1% of gross, capped, on the orders it carries. That number is a starting reference, not a floor or a ceiling for anyone else: it is the rate our own quotes request, and the buyer's approval is what makes it collectible.
Where to start
The API reference is the whole surface a gateway speaks: quote, sign, retry, read. The quickstart runs the loop locally, and the fees page places the relay fee beside the others so you can see exactly what a buyer pays and to whom.