jezer0x/barren-wuffet

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:

  1. 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 call performUpkeep(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.
  2. Gelato Bots. Can createTask(roboCopAddr, executeRule.selector, checkTrigger.selector, ruleHash) during ruleActivation and and cancelTask() && 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
  3. Keep3r network.. Similar to Gelato, except K3PR tokens need to be bonded and unbonded (14 days wait time)
  4. 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

Here is what I've considered re: Gelato Ops

image

image

Psyf commented

We took the BotFrontend approach. See #63