Background

For inspiration: a twitter thread about a $16m milkman order executed by ENS DAO

https://twitter.com/CoWSwap/status/1623680760522612738

If you’re not familiar with the milkman smart contract, here’s the repo

Milkman allows to defer the choice of the limit price from order initiation (pre DAO vote) to order execution time (solver settling the trade). It does so by using ERC1271 signatures and considers a proposed execution price valid if it’s within a predefined range from an external oracle (price checker)

Here’s a short tutorial with code example for creating an execution payload deploying a TWAP/DCA strategy using multiple milkman orders

General requirement

• User should be able to define all relevant parameters for deploying a milkman order:
  • amountIn: an amount of tokens to sell
  • fromToken: ERC20 you're swapping out of
  • toToken: ERC20 you're swapping into
  • to: the intended receiver of the bought tokens
  • priceChecker: the address of a price checker, or address(0) for none (should produce a warning if none); Ideally it suggests choosing from a list of deployed price checkers
  • slippageTolerance: allowed slippage below the expectedOutAmount . Or 0 if price checker not defined.
    • priceCheckerData: encoded data to pass to the price checker; should be generated automatically for popular price checkers like UniV3
  • Allow chaining a validFrom price checker
    • validFrom timestamp
• Batching transaction
  • Allow batching multiple approve to save manual execution overhead
  • Allow batching multiple milkman orders to sell multiple tokens or to construct TWAP/DCA strategies
• View order deployment history
  • Show history of deployed orders (this is important because orders are not seen in CoW Explorer until they become valid and picked up by the watchtower)
  • Link to CoW Explorer with the correct addresses to watch order execution (each milkman order has a unique execution address)
• Cancel milkman order
  • Allow cancelations and withdraw of order funds back to the deploying Safe

Defaults:

• Frequency / Start times: Consideration should be given to UI defaults as these will create a natural tendency for orders to align at specific times and maximise the potential for CoWs.
  • Start time: Top of the hour +5 mins (?) to minimise block space costs.
  • Frequency: Default to daily, but provide option for hourly. To encourage CoWs to converge on a specific timing, fee analysis could also be used to show that higher frequency incurs higher fees.

Bonus:

• Liquidity pool analysis to determine the most suitable price checker and pool for the order
• Market analysis to determine if splitting an order to “TWAP” is preferable