BGD. Aave Robot v1

Robot_banner2 (1)


Presenting to the community Aave Robot v1, the first iteration of a framework and architecture of smart contracts to automate permissionless actions of Aave, like those related to the Aave governance; powered by Chainlink Automation.

Context: Aave Governance v2 permissionless triggers

Given their nature, generally, blockchain systems don’t incorporate any type of “automatic” triggering of actions: a smart contract always requires an external interaction (transaction) in order for anything to get executed.

Consequently, in some systems implementing so-called state machines, somebody needs to trigger with an external transaction the state transitions. For example, on Aave for a governance proposal to be queued, somebody needs to submit a transaction to directly or indirectly call the queue() function.

It is important to clarify that these actions are totally permissionless, as any Ethereum address can trigger them, with the smart contract containing the logic to validate the state transition or other effects.

But in practice, certain “soft” problems appear as a consequence of the aforementioned:

  • Anybody can call the permission-less functions, but more frequently than desired, only the entity behind let’s say an Aave governance proposal has a rationale to spend gas doing it.

    E.g. it has happened multiple times in the past that entities submitting governance proposals simply forget or are not familiar with extra steps post-submission, like queueing, execution, or cross-chain execution.

  • Alerting infrastructure based on timing is not as friendly as it should be, and integrating it with all contributors to the protocol is more effort than it initially seems.

  • There is a clear case to be made that if cost is scalable, a decentralized entity like the Aave protocol should cover the cost of its own purely operational workings.

Our conclusion is then: given the existing infrastructure out there and the integration effort, it is clearly worth it for Aave to try to automate all permissionless procedures.

Aave Robot: a layer of automation

The initial iteration of Aave Robot is simple, and based on the following:

  • Focused on Aave Governance V2, which has the big majority of potential scope for automation.
  • Set of smart contracts defining all the actions that can be triggered: queueing of proposals, execution, or cancellation.
  • Funded by the Aave Governance itself with its holdings, and control at any point at which automation is running. This will be done via a RobotOperator smart contract.
  • Powered by Chainlink Automation, technology that we are currently more familiar with in terms of automation.

The following is a diagram of how Robot works in the case of Aave Governance V2:

And for the current Aave cross-chain governance:

This initial iteration supports the following:

  • If the proposition power of a proposal creator drops during the pending/voting/queuing period below the required threshold, Robot will immediately cancel the proposal.
  • Whenever the voting period (in blocks) of a proposal passes, Robot will automatically queue it.
  • Whenever the timelock period (in seconds) of a proposal passes, Robot will automatically execute it. This applies both to the timelock on Ethereum and the timelock on the cross-chain executor of other networks.

Additionally, as commented the Aave Governance will have full control over Robot, by allowing:

  • Registering new Chainlink automation as part of the Aave Ecosystem.
  • Fund those automations both initially and by refilling afterward (this will also be possible to do for any other address, as a kind of “sponsorship”).
  • Switch off automations, retrieving all funds to the Aave Collector.
  • Change technical configurations, like for example the maximum gas limit to be accepted while running Robot. E.g. actions above 8’000’000 gas limit will need to be executed by the proposer, instead of from the DAO funds.

And Aave Governance V3?

The upcoming Aave Governance V3 follows the same approach of Aave Governance V2: using permissionless state transitions, validated by the smart contracts themselves.

So even if the set of actions is bigger than in v2, the underlying automation needs are exactly the same, and naturally, Robot should be applied.

The actions requiring automation can be seen in the following diagram.


Additionally, with the cancel dynamics being similar to Governance v2, Robot will also cover the cancellation use case.

Practical implementation and next steps

Given the permissionless nature of the project, we have been already testing and funding Aave Robot on Aave Governance v2 and cross-chain governance during the last 2 months, and now we think it is a good moment to fully integrate it into the DAO.

This means the following:

  • We will create a Snapshot vote for the community to approve the integration.
  • We will create and deploy RobotOperator contracts that will act as a middleware for the DAO to have full control over which automation should be active and fund them.
  • We will create a governance proposal for the DAO to fund (from Collector) all automation with the required LINK tokens. For context, during the last 2 months, ~270 LINK (close to 2’000 USD at current prices) has been spent on Ethereum Robot, with Polygon, Optimism, and Arbitrum with insignificant cost.
    It is important to highlight that some proposals with high gas limits have been executed, which means they weigh importantly on the cost compared with all queuing and average executions.
  • It is really important for the community to participate in the discussion on defining which kind of proposal executions should be included (and subsidized) by Aave Robot.
    Some of the operational nature seems pretty clear that should be involved (e.g. risk parameters updates, caps, protocol upgrades, treasury management), but for example, new listings are something that could be reasonable to exclude (or not).

As a follow-up on the initial specification, we would like to present to the community the control model of Aave Robot v1, focused on the AaveCLRobotOperator component.


In order for the Aave DAO to have full control of the Aave Robot v1 system, a vital part of the infrastructure is having one single smart contract per network to execute all maintenance actions.
This smart contract will act as a “gateway” for the governance Level 1 Executor and any other entity involved with Robot.

The following diagram shows the all actions available on this AaveCLRobotOperator smart contract:


Control model of AaveCLRobotOperator

We will publish a more comprehensive guide of the procedure to do governance proposals of different types concerning the AaveCLRobotOperator, but as a summary:

  • Registering new Robots (automations). The Level 1 Executor (short executor) of Aave Governance v2 will be the only entity capable of registering new robots; independent automations.
  • Top-up with funds. For the automation to run, the robots should have access to LINK tokens in order to fund gas expenses. The main use case will be for the DAO itself to fund robots (known as “keepers” on the Chainlink system) from the Collector, but anybody else can do it, for example, external entities that want to donate for executions of certain governance proposals.
    This will be done using the refillKeeper() function on the AaveCLRobotOperator.
  • Execution cost control and pausing. setGasLimit() allows setting a maximum gas to spend on specific robot automation. Initially, we will propose having a really high gas limit to execute any governance proposal by default, boiling down to external entities using refillKeeper() if they want to subsidize specific proposals.
    Given that currently the underlying infrastructure of Aave Robot is Chainlink Automation v1, this function will be callable both by the Aave Level 1 Executor and a Robot Guardian (initially BGD). The reason is that this mechanism can be used to pause a robot, by lowering the gas limit configured, and it can be important to have a faster mechanism than the Aave governance flow.
  • Set withdrawal address of funds. setWithdrawAddress() allows the Level 1 Executor to set to which address non-used LINK funds will be sent always, to be configured as the Aave Collector initially.
  • Shutdown a Robot. cancel() can be used by the Level 1 Executor to stop a specific robot.
  • Withdraw funds from canceled Robot. withdrawFunds() will allow anybody to trigger the withdrawal of LINK funds to the configured (and fixed) withdrawal address, the Aave Collector.

Additionally, as sometimes could be important to have more granularity on disabling automation for specific governance proposals, the same role of Robot Guardian (initially BGD) will be kept in the robot governance-related robots.


Additionally, we have created a Snapshot vote for the approval of the community before the final AIP, with voting starting in approximately 9h

Participate :ghost:

1 Like

After extensive testing and with the Robot system executing a good percentage of governance proposals last months, we have created an on-chain AIP to fully migrate the system to the Aave Governance v2 smart contracts.

More details can be found in the proposal description, but as a summary:

  • The proposal will use 675 aLINK from the Aave Collector (~4’100 USD at current price) to top-up the different Robots on Ethereum, Polygon, Optimism, and Arbitrum.
  • 600 aLINK will be sent to BGD Labs (~3’650 USD at current price), compensating a percentage of all the Aave governance proposal actions the system performed during the last months.

All the necessary permissions have been transferred to the Aave Governance smart contracts, which will allow in the future for further proposals to manage everything around Robot.

Voting will start in ~24h, participate :ghost:


I know its more a nice to have but would it be possible to get some data and graphics after a few months to see how much has been executed, how much time it saved us and so on? So just a little onepager with data?


Definitely! This proposal marks an important step for Robot but, especially in the context of Aave Governance v3, we plan to keep improving the system, for example by adding tooling and visibility around it.