DAOs need to interact with a range of apps and protocols. As we think about what infrastructure, primitives, and features to build, we’ll be grappling with a really challenging problem space and make a number of trade-offs.
I’d like to share a framework for thinking about ACE (eg minion) transactions.
Multi-dimensional problem space
- Security (capture-resistance)
- Time
- UX & Abstraction
- Batching
- Breadth
1. Security and capture-resistance
Any DAO’s top priority is resisting capture of its resources. If it weren’t, then its members shouldn’t be organized as a DAO!
DAOs can be allowed/encouraged to carve out small portions of their resources for lower security / higher efficiency activities, we should not make compromises on security at the main DAO treasury level.
2. Time
One such security measure is time, typically used in DAOhaus in the context of voting and grace period for proposals.
The Safe Minion’s early exec capabilities get around this, but it does require moving funds out of the purview of ragequit. In MolochV2, there’s not really an alternative. But MolochV3’s ability to handle minion-style ACE from its own treasury means that there will be a trade-off between security created by ragequit and the ability to do early execute.
This is especially important for actions involved DeFi, where elapsed time often results in the potential for significant slippage and/or transaction failure. It may be necessary to offer tools for assessing acceptable slippage, or potentially even make an opinionated choice to restrict DeFi actions to early execute-enabled minions.
3. UX & Abstraction
We don’t want to require DAO users to be highly technical. Rather, we want to abstract away as much of the technical nitty gritty as we can (without, of course, abstracting away the sense of control and ownership that DAOs and web3 uniquely provide).
4. Batching
Having multiple proposals related to the same end goal or basic action is not ideal. Its not the end of the world, but it creates coordination overhead that may reduce collective appetite for taking such actions.
Additionally, in the context of a MolochV3 treasury, multiple proposals would take quite a lot of time. This is less of an issue in the context of an early execute-enable minion.
Ideally, we can enable multiple connected transactions to be batched together into the same proposal.
5. Breadth
It’s valuable to support as wide a range of interactions, apps, and protocols as possible. We don’t want to restrict what DAOs can do if we can help it.
Other Challenges
Many protocol front ends have UX tailored for Metamask (or similar) users. Their flows are sequential, only revealing subsequent steps once initial steps are complete. A common example is the approve ==> swap flow on most DEX apps, but there are many others.
This creates a trade-off between breadth (5) and batching (4), since breadth solutions like WalletConnect can only send tx messages back to the DAO one at a time.
Potential Solutions
We must recognize that there is no single solution that optimizes all of these dimensions. Instead, I suspect we will need a constellation of solutions, each of which addresses a subset of the problem space.
For example:
- WalletConnect helps with (3) and (5), but fails at (4).
- Tx Builder helps with (4) and (5), but fails at (3).
- Custom-built boosts help with (3) and (4), but doesn’t scale for (5).
One interesting approach that would resolve the trade-off between breadth (5) and batching (4) is to trick apps into revealing subsequent phases of their UX flows by making them think that the preceding transactions have been completed. This would allow DAOhaus to receive multiple tx data messages in sequence via something like WalletConnect, and then batch them together to be executed in a single multicall proposal.
One way to trick the app would be to inject a simulation RPC rather than a real mainnet RPC. Perhaps the Tenderly Simuation API could help here?