Sundaeswap: DeFi Uses and Order Limits

The SundaeSwap v3 Protocol Specification defines separate orders for exchanging assets, adding liquidity and redeeming a liquidity claim. Contract support and the features exposed by a particular interface can differ.

A minimum output constrains the amount an executed swap must deliver. If available execution can't satisfy that amount, the order can't validly fill on those terms. Increasing tolerance changes the acceptable output; it doesn't establish a completion time.

The v3 design separates the order owner from its destination. Owner authorization can use signature or script conditions and controls cancellation or updating. The destination identifies where execution proceeds are sent, so a receiving address alone doesn't establish cancellation authority. Cancellation acts on an unexecuted order; it doesn't reverse a completed swap.

Open full-size image

V3 also permits an order to omit a pool identifier. That allows a compatible pool to fill the order while preserving its required assets and output conditions. This flexibility helps when a trader accepts execution through another suitable pool; an explicitly selected pool remains appropriate when the pool itself matters to the order.

Farming participation adds program conditions to a liquidity position. SundaeSwap Labs' Yield Farming V2 temperature check, published May 31, 2023, proposed using SUNDAE votes to direct emissions toward selected pools and locking eligible LP tokens to earn those rewards. The author later clarified that staking SUNDAE to vote would earn no direct reward. Under the proposal, owners could reclaim locked assets at any time, but rewards had to be claimed within six months of being earned. Its author reported on June 21, 2023 that it had passed its on-chain vote. Approval alone doesn't establish deployment or the terms of every farm.

SUNDAE governance can also concern protocol settings. The v3 specification assigns settings changes to configured administrator authorization conditions. Casting a vote and applying its result to the protocol are separate actions, with different responsibilities.

Sundae Labs' July 30, 2026 announcement, Introducing Sundae v4 , described a rolling feature deployment. The v4 uses below concern that announced design; the announcement alone doesn't confirm which features a particular implementation has enabled.

V4's routing design lets a trader specify the offered asset, the desired asset and a minimum output, leaving the scooper to split execution across pools and routes. An explicit route remains possible. The contracts direct any routing surplus to the user, so the minimum is an acceptance floor rather than a cap on the amount received.

V4 partial fills address a different task: executing a larger limit order over time. The user's fee budget determines how aggressively the scooper can divide the order into smaller executions, with additional ADA fees for those executions. A displayed pool price reaching the limit doesn't guarantee that the entire order can execute at that price, because the order's size affects its execution price. Partial fills allow smaller executions as conditions permit, without guaranteeing full completion.

Linear swaps

The announced v4 design lets selected stablecoins in a linear pool exchange at a 1:1 ratio plus a predictable fee. The requested asset must remain available in the pool. Imbalanced demand can exhaust one reserve, preventing the pool from serving that order flow. A standard pool can then provide another route where liquidity exists, under its own pricing conditions.

Concentrated liquidity

V4 describes pools with individual price ranges. A provider chooses where to allocate liquidity and earns fees while trading occurs within the relevant range. A position earns no fees while the market is outside its range, making range selection an ongoing responsibility.

Multi-asset pools

A v4 liquidity provider can take exposure to a basket of pool assets. Combining their trading activity may help offset impermanent loss, but the provider remains exposed to every asset in the basket. Greater combined activity doesn't guarantee a profitable position.

In v3, a strategy order locks assets and identifies a signing key. The user or a delegated signer later supplies signed execution instructions for a scooper. Those instructions preserve the user's destination and any specified pool, but a delegated signer can still authorize disadvantageous trades. The specification also notes that some contract features require later support in off-chain software. A strategy therefore depends on the execution software supporting its instructions as well as suitable liquidity.

The v4 announcement retains Strategies as a builder tool and describes custom vaults whose curators configure how deposited reserves are used. A vault using other protocols or an external oracle also depends on those components. A reserve claim alone doesn't explain the vault's allocation policy or establish its exit terms.

Protocol composition serves another task: combining compatible operations within one atomic route. V4 describes routes that can include another protocol's minting or redemption alongside a swap. Such a route requires the relevant integration and must satisfy the user's order terms; modular pool support doesn't make every possible asset route available.