Open Batching Pools

DAO Discussion
1

Sundae should have a seperate open batching pool type because execution risk greatly reduces the appeal of Sundae to DeFi, which may be limiting trade volume & liquidity.

Anecdote:

Currently, in the scenario of a synthetics protocol choosing where to place significant liquidity for synthetic assets, Sundae enforces execution risk in a way that competitors (e.g Splash) do not. In cardano’s transaction system, liquidations can happen in the same transaction as swaps, freely, and as liquidations are usually executed by permissionless agents, for this to be taken advantage of swaps must also be executed by permissionless agents. However Sundae and it’s batching disallow this because the set of scripts which may run in the transaction is limited, and also always must be executed by a batcher license. When a liquidator wants to use Sundae LP, they must always place an order into the pool, which breaks composability.

Proposal:

Here is my proposal for how to bring open batching without compromising existing LP:

  • new pool type, slight modifications to the existing swap scripts
  • remove the necessity for batchers at all
  • make all script inputs / mints / withdrawals allowed in the same transaction
  • in the UI, when such a pool is swapped against, the frontend can show text such as “This pool is open, there is still frontrunning protection but your order may be rejected.”
  • when you place an order in the frontend, those orders can still only be batched by the licensed scoopers, so instead of the scoopers having a monopoly over the AMM, they have one over orders,
  • to the order datum, we add a new field for the input ref that the client saw when placing order, this can be used by batchers to detect the difference between the user-price and the batch-price
  • when batchers detect frontrunning and/or large changes to LP, they can then reject orders via a new “cancellation” option in the order redeemer
  • optional: sensitivity to frontrunning can be set by users

With this functionality, I believe Sundae would be more attractive for emerging DeFi applications.

3 Likes
2

I like the idea! I’d make a few changes:

I’m not sure about the added complexity of cancelling a users order for them, or defining what it means to “detect” frontrunning, etc; I’d just leave the order unexecuted and let the user / other protocol cancel it at their leisure.

I’d add another redeemer to the pool to execute “directly”; i.e. the pool only enforces the AMM formula for what enters and leaves the pool, so it can be executed without orders or with orders with different datum formats;

I would also flip the condition: by default, an order can only be scooped by the list of scoopers in the settings datum; but it is also allowed to provide its own (including None);

I would also add a different protocol fee for orders that specify a different / unrestricted scooper set, or an additional fee that must be paid when you directly execute against the pool.

Given that the pool script is already close to the limit of what can fit in a tx to publish it, i’d probably also pull the logic into a staking script, and/or simplify some of the features it supports to fit the new logic.

And some thought and care has to be put into how to safely allow other scripts to execute; right now, we get the property that any script can be used as an order script so long as it has the right datum, and we get efficient processing of every order, but that only works because we count the number of script inputs and assume they’re all orders, and force the indexing set to process every order exactly once. As soon as other “unrelated” scripts can execute, then you have security risks where someone could provide an indexing set that processes less than all orders… but the order script is deferring to the pool script, and so the scooper can steal the unindexed orders.

@micah we’ve got a lot of different ideas for what the next pool type to build is (stablecoin, 80/20 pools, etc.); from a prioritization standpoint, can you help us understand the likely impact this would have for the protocol?

  • Would it still be worth it if direct execution cost slightly more, such as 1.5 ada instead of 1 ada (just as an example)?
  • How often do you anticipate these kinds of orders? a few times a day? hundreds of times a day? etc.
  • What kind of TVL would you guess these synthetics would generate for these kinds of pools, and how are you justifying that estimate?
1 Like