SaturnSwap/market making
Mainnet

Put a real bid and ask on your token — without handing anyone your bag.

Pick your token, set two prices, sign three times. Our bot quotes both sides on SaturnSwap's order book from an address only your wallet can empty. We take 0.20% of what a fill pays out, and nothing when nothing fills.

You can leave whenever you like. We exercised the exit on mainnet on a pilot book we funded with our own ADA — the close and deposit-back below are signed by that book's own owner key alone. Our wallet signed them because the book was ours; check the witness set on cexplorer and you will not find the ADAM bot key, which is the property that matters: close ↗ deposit back ↗ total cost 0.93 ₳

0.20%
our cut

Of what a fill pays out. Nothing fills, nothing charged.

2 ₳
deposit

Refundable. You get it back when you close.

0 ₳
gas you pay

We pay it every time the bot moves your price.

1 · Choose the token to quote

Connect the wallet holding the token. Everything else on this page is read from it.

Already have an instance?

Your instances are read from the chain — the ceremony's own validator carries the numbers it was built with, so there is nothing for you to look up or type. The manual entry below is only for the case where a registration transaction cannot be read.

Connect the wallet that owns the instance. Its address is one of the ceremony's own parameters, so a different wallet derives a different instance.

Never send funds to this address with an ordinary wallet transfer. It is a script address: a plain send arrives without the datum the validator requires and is permanently unspendable — by us, by you, and by the wallet you own it with. The only safe funding is the transaction this page builds for you, which attaches the beacons and attaches its price datum.

What it normally costs, and what it costs here

Desk pricing is contractually private, so the only reliable figures are the ones token DAOs have had to publish to pass a governance vote. Those show market-making retainers running from $3,500 to $12,500 a month for a single project, and industry reporting puts mandates that maintain active quotes at $15,000 to $50,000 a month. The retainer is not the whole bill either: the issuer also funds the inventory the desk quotes with, commonly tens of thousands of dollars per venue.

What you give upRetainer modelLoan + call modelSaturnSwap
Cash up front$3.5k–$50k / monthNonePrepaid ADA fee balance; no retainer
Your tokensYou fund the inventory1–5% of circulating supply, 12–24 monthsNone
Your upsideNoneA call struck 25–100% above TGENone
OngoingFixed, whatever volume you getThe option is the feeDefault 0.20% of eligible settled ADA notional
CustodyYou fund a venue accountTokens leave your treasuryInventory in your validator; fees in a separate channel

The structural difference is that a retainer is fixed and ours is not. At 0.20% of settled volume, a $12,500-a-month retainer is only the cheaper deal once you are settling around $75 million a year. Below that — which is most of Cardano — you are paying a six-figure annual fee for liquidity you may not be getting. We charge a fraction of what settles, so if we quote badly and nothing fills, we do not get paid.

The loan model has no cash fee at all, which is what makes it attractive, and the cost shows up somewhere harder to see: you hand over a slice of supply for a year or two and sell the desk an option on your own recovery. If the token runs, they exercise. If it falls, they hand the tokens back. We never take your tokens, so there is no option to sell.

Retainer figures are from published DAO governance proposals and industry reporting; desks do not publish rate cards, and we are not quoting any specific firm's price to you. Loan terms are the ranges disclosed in DAO votes. Our default rate is 0.20% of eligible settled ADA notional, subject to your billing grant. Known operator fills are excluded; an unfamiliar signer is labelled unattributed, not independent.

Prepaid fees are separate from your trading inventory. You fund an ADA fee channel. In the two-operator-key channel, both operator keys together can spend that balance; your own key can reclaim it without them. Legacy channels allow one operator key to spend. Check your channel before funding it. Billing rates, invoice eligibility and collection caps are enforced by our billing software and co-signer policy, not by this native script. The inventory validator's 500 basis-point limit does not cap channel withdrawals. Collection network fees also come from the channel. See fee details.

Tell us your token — or ask in Discord.

If you want the detail

Everything below is optional reading.

Can you run off with my tokens?short answer: no

What our bot can do

  • Move your price up and down, inside the range you set.
  • Cancel your order — back to your wallet, never ours.
  • Pay itself one bounded fee leg. That leg can only be ADA, can only land at the published fee address, and the rate is a parameter of your instance that the validator refuses to build above 500 basis points.

What it can never do

  • Send your value anywhere except your order address, your payout address, or that bounded fee leg. The per-asset conservation check fails the transaction, and our tests prove a one-lovelace skim is rejected.
  • Quote outside the two prices you set. A dust-priced order fails at the validator, whoever signs it.
  • Tear down your stake credential to pocket its deposit.

Your exit is unilateral. Your ceremony names an owner key that only your wallet can sign for — the setup reads its public hash from your connected wallet, and your signing key never leaves your wallet — so your own wallet can cancel every order and pull your funds back at any time, with no signature, cooperation, or notice from us. The mainnet transactions at the top exercised that path on a book we funded with our own ADA, so our own wallet signed them; their witness set carries only the owner key, not the bot key.

How we secure itweekly internal red team

We run a red team against this protocol every week, using Claude, Codex and Kimi models to attack the protocol, investigate findings and check for regressions. We choose ongoing adversarial review: a point-in-time audit records one review of one version, while the protocol continues to change.

  • Internal validator tests. The September 9 test record includes 122 unit tests and five property tests run with 1,000 generated cases each. These check conservation, pair preservation, reward-fee exclusion, client exit and modeled fill/reprice sequences for the tested validator generation.
  • Mutation checks. Removing the pair-preservation check or the reward-fee exclusion made the corresponding tests fail.
  • Defined scope. The fill-sequence properties model fills; they do not execute the separate DEX spend validator. Generated cases are not an exhaustive proof of every possible transaction.

No third-party audit. This is internal security evidence, not external certification or a guarantee that no vulnerabilities remain. We do not claim a formal proof for the active validator without a reproducible proof artifact tied to its exact hash. Read the test record and validator scope.

We ran it on our own money firstfour edge cases, closed

Before a single client book existed we ran four of these ourselves on mainnet, with our own ADA, specifically to find the sharp edges while it was still our money at risk. Four we found, and what we changed so you never meet them:

  • A brand-new order sits at the edge of your range. Until the bot's first move it quotes your outermost price, which is a gift to whoever trades against it. Cost us 14.6 ₳ to learn. Now: funding stays locked until your bot is live and quoting.
  • A book nobody re-quotes is not idle. It is a standing offer at a stale price. One of ours sat 5% above market for 89.8 hours before we noticed. Now: a chain-based health check runs every 30 minutes and pages us.
  • Closing in the wrong order strands your tokens. Retire the credential while tokens still rest at its address and they are stuck — for everyone, including you. Now: the page refuses to offer that step until the address is empty, and re-checks the moment before you sign.
  • The bot stops if it is having a bad day. Not a bug — a limit we set. If it loses more than its daily budget it stops quoting until we look. Your funds never move; your book just goes quiet.
What you still have to truststated plainly

The validator bounds where value can go. It does not bound everything, and the honest list of what remains is short but real:

  • Quote quality is off-chain conduct. The chain proves we cannot steal; it does not prove we quote well. The dashboard and the public book are how you judge that.
  • Quoting is continuous, and so is our access to move your orders. Repricing is the service, so the bot key touches your value constantly — every reprice spends your order and rebuilds it. What the validator fixes is not whether we touch it but where it can land.
  • The published constants are ours to publish and yours to cross-check. The verifier takes the DEX hash and beacon id as given. Check them against the public manifest, in a channel this page does not control.
  • Your keys are your own claim. The setup names your wallet's key and payout address; no tool can prove they are really yours.
  • The repo you verify against must be the real one. A doctored clone can pass its own checks. Clone from the public source and compare the printed commit hash.
  • No third-party client has exited on mainnet yet. The exit path is proven on our own pilot books, signed by our own wallet. The mainnet evidence shows the owner key alone can empty the address; it is not yet a record of an outside client walking away.
Check us, don't trust usit's all on chain

Five of the nine parameters behind your vault are ours to publish and yours to check. They are filled in for you so you cannot mistype one, and listed here so you can compare them against a source that is not this page.

SaturnSwap fee address
addr1v9wr69p2tx8dx2lat8rzznahxh4xhfl075yzm8uxmth4tvcf3lx47 An enterprise mainnet address (header 0x61), payment key hash 5c3d142a598ed32bfd59c6214fb735ea6ba7eff5082d9f86daef55b3. It receives this fee and nothing else — no change, no payouts, no treasury.
Our fee, in basis points
20 The validator declares its own ceiling, const max_fee_bps = 500, and refuses to build above it whatever we ask for.
SaturnSwap bot key hash
cea98dfce26e0ffbf5ab892edcb8f8ab8b794d5390f80ec0b9aafed3 Check it on chain: the key funds its own enterprise address addr1v882nr0uufhql7l44wyjah9clz4ck72d2wg0srkqhx40a5c6g5gjp, whose payment credential IS this hash, and whose transaction history on mainnet is entirely this key signing for itself. The count moves every day the keeper runs, so check the credential rather than a number we would have to keep up to date.
DEX validator hash
11928a3ac3b65edbf103ea6bb3362e39b879a36f02897df31c40917b You do not have to take this from us — the beacon policy below commits to it. Fetch that policy's script from any mainnet indexer and this hash appears inside it as an applied parameter. The two values check each other.
Beacon policy id
8a199a17ef4517215945aaf3c8c5204c60fd94d34c46d341e99c8fcf Fetch the script for this policy id from any mainnet indexer and read the error strings inside it: they say "Two-way swaps must have exactly three kinds of beacons", "Wrong asset1_beacon" and "Wrong asset2_beacon". A one-way policy says "One-way" and "Wrong offer_beacon" instead — that is how you tell the two deployments apart, and they are otherwise indistinguishable.
Already set up? Check what your vault boundpaste your file

Paste the params file or ceremony receipt you were given. This panel echoes back what it claims — the bound script hash, your floors, your payout address, your escape-hatch key — and hands you the command that turns those claims into checked facts. The check runs on your machine against the public source; this page plays no part in it.

Set this up by hand, from a cold keyexpert

Nine parameters define your instance of the validator. The guided flow fills in seven of them — five are ours and published, two are read from your wallet — and asks you only for your prices. This form assembles the same nine by hand, which is what you want if the key that can pull your funds back lives somewhere this browser will never see it. Either way the setup is identical and the independent verifier is the thing that settles it. Nothing you type here leaves your browser.

Step 1 — your wallet

Connect the wallet holding the token you want quoted. We read your key hash and payout address from it — you do not need a terminal or a key file.

Want the escape hatch on a different key than the wallet you connected? Derive its hash yourself with cardano-cli address key-hash --payment-verification-key-file payment.vkey and replace the value above — the payout address must be controlled by that same key.

Step 2 — the prices you are agreeing to

Step 3 — the five values we publish (already filled in)

These are prefilled from our published manifest below so you cannot mistype one — a transcription error here is permanent. Cross-check them against the manifest, and against a channel this page does not control, before you run the ceremony.

Questions people actually ask
  • What am I actually paying for? A bot that keeps a live buy and sell order on your token so people can trade it without a 30% spread. You supply the inventory; we supply the quoting and pay the gas.
  • How much do I need to put in? Enough that a fill is worth someone's while — a few hundred ADA of depth is a reasonable floor. Below that the network fee eats the trade and nobody bites.
  • Can I change my prices later? Yes, in one signed transaction that moves your whole book across at the new range. Nothing is closed and re-opened, and your inventory never passes through a wallet.
  • What if SaturnSwap disappears? Your wallet closes the order and takes everything back without us — the transactions at the top exercised that path on our own pilot book, and the tool that does it is public.
  • Do I keep my staking rewards? Tokens in your vault are not delegated, so no rewards accrue there. Only move in what you want quoted.
SaturnSwap · Market Making as a Service

Market Making as a Service

Real limit orders on Cardano L1, quoted by our keeper, on liquidity the client never hands over. Every fill is a public transaction, so a client can re-derive their own volume numbers straight from the chain.

The number that matters

0.0496%network gas, before any fee of ours
0.2496%all-in, including our 0.20% operator fee

On our own book, on preprod — our own taker filling our own maker — 3,419,141 ₳ of settled volume cost 1,696 ₳ in network fees. Applying a 0.20% service fee as an illustration adds 6,838 ₳, for 8,535 ₳ all-in. The working capital behind it was about 13,000 ₳, recycled in place 385× over. For comparison, a conventional DEX charges 0.3% in protocol fees alone, before its own gas. Our earlier one-way approach cost 0.35%.

Why more clients make it cheaper for everyone

Gas per fill depends on a single variable: how many fills share a transaction. The token makes no difference and neither does the owner; we measured both, below. That makes pooled order flow the pricing mechanism itself. Every client who joins deepens the batches every other client is already riding, and the cost per fill falls for all of them at once.

Fills sharing one transactionGas per fillGas as % of volumeAll-in with our 0.20%
1 — a maker running alone (n=260)0.4088 ₳0.213%0.413%
4 — a thin book (n=22)0.1785 ₳0.093%0.293%
16 — a pooled book (n=906)0.0861 ₳0.045%0.245%

A maker running alone pays 0.413% all-in. Inside a pooled book the same maker pays 0.245%, our fee included, which still comes in under what a conventional DEX charges in protocol fees before it has paid a lick of gas. The gas itself is 4.75× lower for identical volume.

The mechanism is a fixed floor. Every Cardano transaction pays roughly 0.29 ₳ in base fee, Plutus bootstrap and reference-script overhead, however little it settles. A pooled transaction pays that floor once for sixteen fills instead of sixteen times, and past the floor an additional fill costs 0.063 ₳: about six cents of ₳ to settle another ~192 ₳ of volume. At scale, 5,000,000 ₳ of volume costs 2,244 ₳ pooled and 10,655 ₳ settled one fill at a time.

Percentages use the measured average fill size of ~192 ₳ and measured per-fill gas. The 0.20% service fee is an illustrative overlay at the default rate, not evidence of a paid invoice from this operator-run rehearsal. Current billing excludes known operator fills. The fee overlay is flat across the table; movement in the all-in column comes from measured gas. Actual billing follows the client's grant and eligible flow.

Measured on our own multi-token book, on preprod

The table above comes from that book: our own maker, filled by our own taker agent, on preprod. Every figure is a settled transaction, and none of it is third-party flow. Across 17,823 settled fills in 1,405 transactions quoting five tokens (ADAMMKT, iUSD, RISE, AGENT, TEST), the keeper settled 3,419,141 ₳ of volume for 1,696 ₳ of network fees: 0.0496%, the gas figure in the headline.

What makes the batches deep is worth spelling out. A transaction carrying one token averages 3.6 fills at 0.210 ₳ per fill. Carrying three tokens, it averages 16.0 fills at 0.086 ₳ per fill, 2.4× cheaper purely from mixing tokens into the same transaction. A fourth token held steady at 0.087 ₳ per fill.

Token in the shared bookFillsVolumeGas per fillFee as % of volume
iUSD4,118815,364 ₳0.0862 ₳0.0435%
RISE3,012602,400 ₳0.0863 ₳0.0431%
AGENT40380,580 ₳0.0867 ₳0.0434%

Three tokens with very different volumes, and the cost per fill agrees to within half a percent: 0.0862, 0.0863, 0.0867 ₳. Gas belongs to the fill. A client's cost is independent of which asset they bring, because their fills ride transactions the book was already paying for.

At the measured rate that is 4.75× cheaper, a saving of ~8,410 ₳ on 5,000,000 ₳ of settled volume.

Depth has a limit. 16 fills is the measured optimum; the deepest transactions we observed (25 fills, small sample) cost more per fill as script execution units outgrew the amortization. The keeper tunes to the optimum.

The evidence for the multi-client claim

Everything above rests on the claim that pooling clients costs nothing, so we settled it on chain. Each client is its own stake credential and their orders rest at different script addresses, the same way two real clients' orders would. Every hash below is live on preprod and opens in cexplorer.

Sixteen fills across two clients settled for 2.5695 ₳ in one transaction. As sixteen separate transactions they would have cost 6.3184 ₳, which makes the shared transaction 2.46× cheaper. Every figure comes from the same wallet on the same pair, so the comparison carries no hidden difference.

The last row settles the question. We ran the identical transaction with all sixteen fills under a single client as a control, and it cost exactly the same: 2.5695 ₳, byte-for-byte identical at 9,834 bytes. An order address differs between clients only in its stake credential, which has the same length either way, so the fee cannot move. Crossing clients costs nothing.

Billing holds up at the same depth. Our indexer read that sixteen-fill transaction back from chain data and attributed eight fills and 41.3466 ₳ to each client on its own. One transaction becomes two invoices with no manual reconciliation, which is what makes per-client billing on shared transactions operable.

The ladder is best read for its ratios. The test wallet holds a long tail of native assets that every change output has to carry, which inflates its per-fill cost above the 0.086 ₳ the production book runs at. The control isolates the one variable under test, one client versus two, and that difference measured zero.

Every client makes the next one cheaper

Per-fill gas is token-agnostic and fills for different tokens batch into the same transactions, so the fee ratio holds near 0.04% at the margin however many tokens we serve, while volume scales with the capital each client brings. Three client projects produce roughly three times the volume at the same cost ratio.

A custodial desk cannot copy this. Its marginal client adds cost; ours adds fills to transactions we were already paying for, and the shared transaction gets more efficient as the book gets busier.

AI agents work both sides of the book

Resting orders only become volume when something fills them, so we run the taker side too: an autonomous agent that reads the live book, decides what is worth taking, and composes the multi-fill transactions the economics above depend on. The same agent family quotes the maker side, repricing as the market moves, skewing on inventory, and standing down when the spread is too thin to justify a fill.

Appetite is a setting. Each client gets their own parameter set on a shared brain: target pairs, order size and ladder shape, spread and skew targets, per-token caps, a ceiling on outflow per window, and how aggressively to chase depth. We tune those numbers per client and keep re-tuning them against measured results. Running one brain over many parameter sets also means whatever we learn tuning one client transfers to the next.

Autonomy is bounded in two independent places. The agent enforces its own risk configuration, and beneath it the on-chain validator bounds what any keeper-signed action can do at all, so even a misconfigured agent cannot move value anywhere except the client's own payout address. Every agent runs paper-first before it is allowed to sign, and a kill switch halts it without touching client funds.

Status: the taker agent is built and dress-rehearsed end to end on preprod (paper, live and kill), including a real on-chain fill, aea3d325537d7afdcdb31803088304e681404951430abc08e72970883e459edd. It ships behind an operator control with two-layer auth. Running it on mainnet is gated on that client's onboarding and on the mandate it will run under; a preprod rehearsal is not a mainnet record.

The client keeps custody

  • Trading inventory stays in the client's validator. The client's liquidity sits at their own instance of a source-available validator, parameterised with their own key. We hold only a bot key whose authority the validator itself bounds.
  • The validator bounds inventory actions. A keeper-signed action can reprice an order, return value to the client's payout address, and include the validator's bounded ADA fee leg. Internal tests include rejection of a one-lovelace skim. Guarantees depend on the book's validator generation; the prepaid billing channel is separate.
  • Exit is unilateral. The client can cancel and reclaim at any time with their key alone, needing no cooperation or notice from us.
  • Billing is metered against the chain. The default rate is 20 basis points of eligible settled ADA notional, subject to the client's billing grant and any configured cap. The software checks consent, grant timing and finality, excludes known operator fills, and holds fills missing signer evidence. Public transactions support verification; they do not establish independent demand.

Known limitations

  • No third-party audit. We run an internal red team weekly with Claude, Codex and Kimi, supported by regression and property tests. This is not a formal proof or a guarantee of no remaining vulnerabilities. The fill-sequence properties model fills; they do not execute the separate DEX spend validator. See the test record and validator scope.
  • The preprod volume above is our own two-sided liquidity on a public order book — our maker filled by our taker — so it measures gas, batching and billing, not demand. Mainnet fills will be published as they settle, each attributed to who took it.
  • Fees are drawn from a separate prepaid ADA channel. Both operator keys together can spend a two-key channel; a legacy channel permits one operator key. The client can reclaim with their own key. Its native script does not enforce the invoice, billing rate or collection cap, and the inventory validator's 500 basis-point bound does not apply to it. Collection network fees also use this balance.
  • Token-to-token pairs with no ADA leg earn no fee under the current model, because the meter values a fill by the ADA that moved and a token-for-token fill moves none. The next version closes this, and the gap sits in measurement alone: fees are already drawn from the client's prepaid ADA channel, never skimmed from the swap, so collection was never tied to the pair's composition. What is missing is an ADA-equivalent notional for the fill. The keeper already quotes both sides against a live price feed, so the fix is to value the fill at that feed's rate for the settling slot, record the rate on the fill so the client can re-derive and dispute the number, and bill it from the channel exactly as an ADA-leg fill is billed today. The billing rail, the cap, and the finality gate carry over unchanged.
  • Batch depth is bounded by transaction execution limits. On the live book the practical ceiling sits around 16 fills; pushing past it raises the cost per fill.

Figures are measured from settled preprod transactions on our own book; the ladder above links to each one. Anything forward-looking is labelled as projected.