- As someone who's sold a lot of tokens through a multisig, my ideal interface is pretty close to the UniV2 `swapExactTokensForTokens(amountIn, amountOutMin, path, to, deadline)`. I call it with no special structs or data encoding and it just works. Conversely, I would notice that we swapped fewer times through pools with complex interfaces (e.g., Balancer, with all its custom structs). Kinda makes sense since all DAO & multisig actions need to be reviewed; complex interfaces hurt auditability and thus security
- you can kinda get around complex interfaces with an SDK, but then you need an SDK in each language. This is non-optimal given that Rust, Go, Python, Typescript, and Javascript all are used. Better to just use basic types
- Deploying a custom safe just for swapping feels cumbersome. We considered this for original Milkman, but decided against it and instead pursued the [ERC-1167](https://eips.ethereum.org/EIPS/eip-1167) route
- Assuming you want to go the same route here, it would probably make sense to build dutch auctions as a price checker rather than an independent project
- Any contract would pretty much need to do what Milkman does, including
- storing hashes
- ensuring that orders are valid
- EIP-1271 stuff
- ERC-1167 stuff
- Probably better just to use an existing audited contract rather than do a new one
- The main benefit of doing this as an independent project is that you would cut down on an `approve` and `transferFrom`, so less gas
- Probably not enough to justify it, given that (based on my understanding) the expected user is a DAO or a multisig, less price-sensitive on gas
- How can you build dutch auctions as a Milkman price checker without having users deal with raw byte encoding?
- Add a dutch auction price checker, shouldn't be too far what [Felix has implemented](https://github.com/charlesndalton/milkman/pull/7/files).
- No matter what way we go, we need to sort out some details like how fast the price of the dutch auction should decline
- Add a wrapper contract, like the one discussed in milkman 2.0 grant, that calls `transferFrom`, `approve`, and then calls Milkman internally
- The idea here is that users wouldn't need to do any byte encoding, they could have an interface like `function requestSwapExactTokensForTokens(uint256 amountIn, IERC20 fromToken, IERC20 toToken, address to, uint256 minOut, uint256 startingPrice)`
- On dutch auctions themselves,
- a single solver defecting can't screw over the user
- solvers can collude to screw over the user
- users will at least get their `minOut`
- it's 1/n security. If we expect to have more than 10 solvers, *n* is probably high enough, and I would personally feel comfortable swapping tokens through this protocol
- from a game-theoretical perspective, solvers have no incentive to screw over a user unless the profit they can get by doing so is greater than the profits they expect to get in the future + any stake they would lose.
- a corollary of this is that the bigger the trade and the smaller the `minOut`, the higher the incentive to screw over the user. So big trades should probably set high `minOut`s
- a problem here is that the users most likely to do these high-value trades are DAOs, and DAOs probably don't want to set a high `minOut` because then if the price goes out of range (which is completely possible, given the typical 5-15 days between governance proposal and execution) they have to cancel and re-start
- so maybe (> $10M) swaps like the one ENS did are poor candidates for dutch auctions
- the security benefit of a dutch auction depends on two factors: (1)
- obviously, dutch auctions are non-instantaneous
- a borrow-lend protocol probably wouldn't want to use a dutch auction to liquidate collateral
- I don't think most DAOs & multisigs care about this though. DAOs and multisigs are already non-instantaneous, so as long as the auction takes less than 1 day to complete, should be okay
-