Bot Design
Closed this issue · 3 comments
Psyf commented
The initial design:
- assumed there will be a bot that uses
checkTrigger(ruleHash)
for every activated ruleHash for every roboCop created. - initially, we'd run our own custom bot,
- but overtime we'd use the
incentive
and expect people to compete for the "good MEV". - The incentive was supposed to be provided by the fund manager. We are now thinking whether the platform should use part of its fees collected to fund the rules.
We're now exploring more designs:
- Chainlink Automation.. You can programmatically (i.e. from the smart contract) register 1 upkeep task (checkData == ruleHash) per rule. Bot will
checkUpkeep(abiEncodedRuleHash)
and if successful, will callperformUpkeep(abiEncodedRuleHash)
.
Cons 1: Minimum LINK is 5. That's nearly 35$ for each rule.
Cons 2: Aggressive gas limit (5mil) for performUpkeep. For context, a single swap on sushi costs around 1.5mil gas. - Gelato Bots. Can
createTask(roboCopAddr, executeRule.selector, checkTrigger.selector, ruleHash)
during ruleActivation and andcancelTask() && withdrawFunds()
during ruleCancel/Execution easily. Does not look like they have a minimum GEL and does not mention any aggressive gas limits.
Cons 1: Looks like each roboCop has to call depositFunds by itself (no common pot to use). We can potentially work around this if we take the hit of more gas per ruleExec - Keep3r network.. Similar to Gelato, except K3PR tokens need to be bonded and unbonded (14 days wait time)
- OZ Defender Autotasks. Web2 way (i.e. too centralized)
Psyf commented
I'm leaning towards Gelato Ops. What do you think @madneutrino @krenzx ?
Psyf commented