Market Making as a Service

The number that matters

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.

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 the measured per-fill gas at each depth. The 0.20% is our standard contracted rate (OperatorFeeBps = 20). It is charged on volume, so it is flat across the table by construction; all the movement in the all-in column comes from gas. Every figure comes from settled on-chain transactions.

Measured on a live multi-token book

The table above comes from a running book. 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.

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; the engineering is done.

The client keeps custody

• Funds never move to us. The client's liquidity sits at their own instance of an audited validator, parameterised with their own key. We hold only a bot key whose authority the validator itself bounds.
• The validator enforces the bound; no contract needs to. A keeper-signed action can only reprice an order or return value to the client's own payout address. Anything else fails the validator's per-asset conservation check, which we prove with a test where the bot tries to skim a single lovelace and is rejected.
• 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. Fees accrue in basis points of settled volume, capped, and only from volume deep enough to be final. Every billed line resolves to a public transaction the client can check independently.

Known limitations

• Volume here is real two-sided liquidity on a public order book; nothing is printed. Orders genuinely fill, against each other and against the market.
• Non-custodial billing cannot compel collection the way a custodial desk can, because we draw fees from a prepaid channel instead of holding client funds. We accept the weaker collection leverage as the price of the client keeping custody.
• 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.