Thanks for contributing @jacobdcastro
- The driver seems a bit opinionated and centralized. What exactly is it? Can anyone build a driver implementation with different ordering algos?
The driver in this architecture is managed and governed by the solver DAO. We retained the driver for the initial iteration of this architecture to place a stronger emphasis on the solvers’ end of the structure. Certainly, our roadmap includes plans to make it increasingly permissionless and decentralized. We are indeed considering the possibility that, in the future, anyone could code their own logic for ATO distribution among solvers. Since an intent comprises multiple ATOs, the routing and distribution of these ATOs also present an optimization challenge. Better approaches from the community could enable quicker resolution of the ATOs.
How does the driver’s role differ from SUAVE’s MEVM smart contract mechanisms?
In SUAVE’s MEVM, smart contracts are primarily used to construct builders, relays, and searchers. These entities mainly deal with building blocks and identifying MEV opportunities from the order flow, which, in the case of SUAVE, are user preferences. In the context of SUAVE, the driver functions more as a mempool management entity where user preferences are received. Executors (as solvers here) can then listen to these preferences and solve them.
How do solvers guarantee block inclusion for the client? Will txns be routed through MEV-boost, or through private order flow?
Solvers operate at a layer above the order flow layer of the EVM. Their primary task is to determine the best route for the user’s optimizable ATO. Once the path is identified, it is sent and executed from the user’s wallet as a UserOperation.
How do you plan on deciding which solver reward mechanic to use? Is there a way to implement many reward solutions here, and/or allow solvers to create/enforce their own reward mechanisms depending on order type specialty?
For now, the reward mechanism we are considering is largely based on the type of ATO a solver addresses. However, we are definitely open to discussions and suggestions regarding the implementation of a flexible solver oriented rewards mechanism.