Sundaeswap scoopers

The v1 design used an approved scooper list and one-week license tokens. V3 holds its authorization settings in a settings UTxO, an unspent transaction output containing protocol configuration. With an authorization list enabled, a scoop requires an approved transaction signer. Setting that list to None permits anyone to execute a scoop.

Authorized scooping provides an accountability mechanism for harmful reordering. The specification describes revoking a malicious operator's permission and forfeiting recently earned protocol fees. The pool contract lacks global information about order arrival times, so those controls depend on the authorization arrangement.

V3's market_open field adds a specific launch rule. A scoop's validity interval must start at or after the pool's opening time. Orders placed before opening have priority over orders placed afterward, with the pre-opening group processed in random order. Submitting earlier within that group doesn't secure the first fill.

The v3 specification's execution comparison reports a v1 limit of 8 orders per batch, with an average of 2-4 in practice because the ledger's sorting of transaction inputs constrained processing order. V3 changes how the validator reads and checks those inputs, allowing up to 35 orders per batch under suitable conditions. Mixed order types or low trade volume can produce smaller batches.

These figures measure orders per transaction. They aren't an orders-per-second rate or a promised waiting time, and greater batch capacity doesn't remove an order's output constraints.

V3's protocol charge combines a base fee collected once per scoop with a separate fee paid by each order. Batch participants share the base component. More participants can reduce each one's share, while the applicable per-order component remains payable in full.

Simple orders and Strategies have separate per-order fee parameters because Strategies require additional execution infrastructure. These ADA-denominated protocol charges are distinct from the pool's liquidity-provider percentage fee on the trade. V3 collects protocol fees in the pool UTxO for treasury withdrawal; the v1 design directed its protocol fees to scoopers.

V3 Strategies introduce a signing role alongside the scooper's execution role. A designated key signs execution details later, and scoopers present those details when executing the order. Through those signed details, a strategy provider can't change the destination or any pool the user fixed in the order. It can still authorize highly unfavorable trades, so the provider's discretion remains a separate consideration from scooper authorization.

Open full-size image

New order contracts can extend v3 pools, but their use also requires scoopers to index and include them. Contract support alone doesn't establish whether a particular interface or operator handles a new order type.

Sundae Labs' July 30, 2026 announcement, Introducing Sundae v4, describes a larger execution role for scoopers. A user may specify a route or leave the executing scooper to split an order across pools and routes. The contracts direct any routing surplus to the user.

Partial fills divide a limit order's execution over time. The order's fee budget determines how aggressively the scooper can split it into smaller executions, which carry extra ADA fees. The announcement specified a staged rollout; feature availability needs to be checked for the interface in use.

• For an unfilled swap, distinguish confirmed order placement from execution and examine the minimum output the order requires.
• For a v3 pool opening, check market_open before relying on submission order; the pre-opening group is processed in random order.
• For a v3 fee comparison, distinguish the shared batch charge from the applicable per-order charge and the pool's percentage fee.
• For a new order type or v4 feature, confirm the relevant scooper software and interface support it.