Migrate Robots to Chainlink Automation v2
01Summary
Migrate Aave automation robots from Chainlink v1.2 to v2.1 across multiple chains, introduce gas-capped robots on Ethereum mainnet to reduce costs during high gas prices, activate automated liquidity mining reward refreshing for static-a-tokens, and refill cross-chain-controller with 1 ETH.
- Type
- protocol addition
Key changes
- Migrate all Aave governance v3 robots, GSM swap freeze robots, and Proof of Reserve robots from Chainlink automation v1.2 to v2.1 across Ethereum, Polygon, Avalanche, Optimism, Arbitrum, Base, and BNB chains(high)
- Introduce gas-capped robots on Ethereum mainnet (governance, voting, execution, and static-a-token rewards robots) to limit execution based on network gas price and reduce costs during high gas periods(high)
- Activate automated liquidity mining reward refreshing for static-a-tokens on all chains (Ethereum, Polygon, Avalanche, Optimism, Arbitrum, Base, BNB) to automate the previously manual refreshRewardTokens() process(high)
- Refill cross-chain-controller contract with 1 ETH from the collector on Ethereum mainnet(medium)
Notable concerns
- Robot migration requires cancellation of old robots and registration of new ones, with a delay period before unused LINK funds can be withdrawn from the old operator contract
Generated by Kvorum
02Description
Simple Summary
Proposal to migrate existing Aave robots from chainlink automation v1.2 to v2.1. For governance v3 robots on ethereum, we introduce gas-capped robots in order to limit execution based on network gas price. We also activate robots for refreshing liquidity mining rewards for static-a-tokens.
Motivation
With the release of Chainlink automation v2.1, we think its a good idea to update the Aave Robot existing infrastructure to the latest v2.1 version.
In addition, as an effort to reduce the cost spent in gas in times of high gas prices, we also introduce gas-capped robots on mainnet which will be activated via this proposal.
Currently when a liquidity mining reward is added after static-a-token creation, it needs to be registered manually on the token via the permissionless refreshRewardTokens() method. As this process is not currently automated users might be missing out on rewards until the method is called, so now we introduce the robot for static-a-token to automate this process.
Specification
For the migration, the robots registered on the previous robot operator contract will be cancelled and new robots will be registered using an updated robot operator contract, compatible with the newer version of chainlink automation v2.1.
The robots will be cancelled by calling the cancel() method by the payload on the previous robot operator contract, and after the delay has passed anyone could call the permissionless method withdrawLink() on the robot operator contract to withdraw the unused funds on the previous robots to the collector.
On the newer robot operator, the payload will call the register() method to register the keepers with the newer chainlink automation registry supporting v2.1.
The proposal also refills the cross-chain-controller contract (part of aDI) on mainnet with 1 ethereum from the collector.
Note: All aave governance v3 robots along with robots used for gsm swap freeze and Proof of Reserve will be migrated via this proposal and will use the same contract as before except the one's mentioned below
| Deployed AaveCLRobotOperator | |
|---|---|
| Mainnet | 0x1cDF8879eC8bE012bA959EB515b11008E0cb6323 |
| Polygon | 0xB4C212f5cD17E200019b07e6B1fDf124d35DBCf5 |
| Avalanche | 0x06d958772304e7220fc3E463756CE01Ed0D24db2 |
| Optimism | 0x55Cf9583D7D30DC4936bAee1f747591dBECe5df7 |
| Arbitrum | 0xaa944aD95e51CB83C1f35FAEEDfC7d2c31B0BB4d |
| Base | 0x88db99eeBb390a2a4DcAC2E1DDb09c07E911C5C3 |
| BNB | 0x51Bd3d6011Dd0BD88Ee1bEA1a67be799A6A09D79 |
| Deployed Robots | |
|---|---|
| Mainnet Gas Capped Governance Robot | 0x1996c281235D99bB3c6B8d2afbEb8ac6c7A39C11 |
| Mainnet Gas Capped Voting Robot | 0x7Ed0A6A294Cf085c90917c0ee1aa34e795932558 |
| Mainnet Gas Capped Execution Robot | 0xBa37F9eDC52f57caFA3a13ddfD655797Cc4FE257 |
| Mainnet Gas Capped StaticAToken Rewards Robot | 0xda82148a3944BBe442116f41cDb329b0edF11d41 |
| Polygon StaticAToken Rewards Robot | 0x855FbD0D57fF5B1e8263e3cCDf3384545fbaF863 |
| Avalanche StaticAToken Rewards Robot | 0x8aD3f00e91F0a3Ad8b0dF897c19EC345EaB761c4 |
| Optimism StaticAToken Rewards Robot | 0x861Be72d464b6F1C99880B9bE476D40e8F9b5Bce |
| Arbitrum StaticAToken Rewards Robot | 0x0451f67bA61966C346daBAbB50a30Cc6A9A67C69 |
| Base StaticAToken Rewards Robot | 0xad87684D27e6e58F055E6878A9F11F8c52A5b0F5 |
| BNB StaticAToken Rewards Robot | 0x020E452b463568f55BAc6Dc5aFC8F0B62Ea5f0f3 |
References
- Implementation: AaveV2Polygon, AaveV2Avalanche, AaveV3Ethereum, AaveV3Polygon, AaveV3Avalanche, AaveV3Optimism, AaveV3Arbitrum
- Tests: AaveV2Polygon, AaveV2Avalanche, AaveV3Ethereum, AaveV3Polygon, AaveV3Avalanche, AaveV3Optimism, AaveV3Arbitrum
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The decoded on-chain data contains only a single generic action: a call to execute() on a payload contract on Ethereum mainnet, with no further decoded internal calls, parameters, or targets. This is the standard pattern for Aave governance proposals, where the actual multi-step logic (cancelling old robots, registering new ones, deploying gas-capped robots, refreshing reward robots, and refilling the cross-chain-controller) is implemented inside the payload contract's execute() function rather than being visible as separate top-level calldata actions. Because the decoded action gives no visibility into the internal calls, addresses, or amounts (e.g., the claimed 1 ETH refill, or the specific robot operator/registry addresses), it is not possible to verify or contradict the numerous specific claims made in the description (chain-specific robot addresses, gas-cap behavior, reward-refresh automation, etc.). There is nothing in the visible calldata that contradicts the description, but the opacity of the single execute() call means a rigorous line-by-line comparison cannot be performed. This is typical for this proposal type and not itself a red flag, but confidence in the comparison must be marked low rather than asserting full consistency with high confidence.'}, {
Generated by Kvorum
04Actions
- Target
- 0x87c2…e86c
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedRobot Maintenance92%
- aaveexecutedFunding Aave Robot for Governance V2 Automation83%
- aaveexecutedAave Governance V3 Activation80%
- aavecanceledAave Governance V3 Activation Short78%
- aaveexecutedAave Governance V3 Activation Short78%
- aavecanceledGovernance V3 Activation78%
- aaveexecutedGovernance v2.5 Activation75%
- aaveexecutedMigration of remaining Gov v2 permissions & DAO's Paraswap positive slippage73%
- aaveexecutedAdjust Aave Governance Level 2 requirements71%
- aaveexecutedstataToken operational update70%