KVORUM
aaveSource: Aave governance v3 · #340

Robot Maintenance

executedJul 22, 2025, 03:41 PM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Maintenance proposal to update Aave Robot automations across multiple chains due to VotingMachine address updates and new Stata Token deployments. Old robots will be cancelled and new ones registered to maintain governance voting and liquidity mining rewards automation.

Type
protocol addition

Key changes

  • Cancel old StataRefreshRewardRobot instances on Core, Arbitrum, Avalanche, Polygon, Base, BNB, and Optimism chains and register new StataRefreshRewardRobot instances, including new Prime instance(high)
  • Cancel old VotingChainRobot instances on Mainnet, Avalanche, and Polygon; register new VotingChainRobot instances with redeployed RootsConsumer contracts(high)
  • Migrate LINK balances from old RootsConsumer contracts to new RootsConsumer contracts via emergencyTokenTransfer method(medium)
  • Withdraw unused LINK funds from cancelled robots to the Collector via permissionless withdrawLink method after delay period(medium)

Notable concerns

  • Robots using Gelato automation on networks without Chainlink automation will be updated manually rather than through this proposal
  • Proposal requires a delay period before unused LINK funds can be withdrawn from cancelled robots
Contracts0xda82148a3944BBe442116f41cDb329b0edF11d410x892B74CD3703B427CD90e7f140F358A1DE1EA7030x858f50cB70e6476d37543275aF4c738Ae8a278930x0451f67bA61966C346daBAbB50a30Cc6A9A67C690xF01281a6DfDe5506C5049c9BBf8C7E087b9bD4bF0x8aD3f00e91F0a3Ad8b0dF897c19EC345EaB761c40x43C6b39669355AF93DdEdc70e8eB44c226f09BFB0x855FbD0D57fF5B1e8263e3cCDf3384545fbaF8630x1d8347B427964fad8a742e7f9442a4E89346400a0xad87684D27e6e58F055E6878A9F11F8c52A5b0F50x97CB9e81d480A2AB03299760654C1DDC0C16bE070x020E452b463568f55BAc6Dc5aFC8F0B62Ea5f0f30x9062F78b631f33D24Ed058cBc116A653452ea82A0x861Be72d464b6F1C99880B9bE476D40e8F9b5Bce0x365d47ceD3D7Eb6a9bdB3814aA23cc06B2D33Ef80x7Ed0A6A294Cf085c90917c0ee1aa34e7959325580xbC3210bfff692a5bbDBB068D42Ab4eAF28b01Ee00x10E49034306EaA663646773C04b7B67E81eD0D520x2cf0fA5b36F0f89a5EA18F835d1375974a7720B80xbe7998712402B6A63975515A532Ce503437998b70x1180eE41eC15Dd0accC13a1e646B3152bECFf8F60x80eae07078858fc3f15d04ff5aa21a7951b12057
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

412 words

Simple Summary

Maintenance proposal to update the Aave Robot automations related with governance voting machines and Stata Tokens rewards accounting.

Motivation

Due to the update of the VotingMachine addresses on the voting machine/portal improvements proposal, it is required to update the voting chain Aave Robot performing automations on the voting machine contracts, and also registering storage roots for voting. Additionally, with newer instances of Stata Tokens (used on Umbrella) having been deployed recently, it is also needed to register new robots for refreshing liquidity mining rewards and cancel the old ones that were previously activated via this proposal.

Specification

The old Stata Token refresh liquidity mining robots and the voting chain robots will be cancelled by calling the cancel() method on the Aave Robot operator contract, and after the delay has passed anyone could call the permissionless method withdrawLink() to withdraw the unused funds on the previous robots to the Collector.

For the new Stata Token and voting chain Robots, the payload will call the register() method on the robot operator to register them.

The RootsConsumer contracts, which are triggered by voting chain robots to register storage roots for voting, are also redeployed, and new instances are used on the new voting chain robots. The LINK balances from the old RootsConsumer are also migrated to the new RootsConsumer contract by calling the emergencyTokenTransfer() method.

Note: This proposal only updates Robots on Chainlink automation. Robots using Gelato automation on networks where Chainlink automation is not available will be updated manually

Below you can find the changelog of deployed contracts for each instance:

StataRefreshRewardRobot:

Old ContractNew Contract
Core0xda82148a3944BBe442116f41cDb329b0edF11d410x892B74CD3703B427CD90e7f140F358A1DE1EA703
Prime-0x858f50cB70e6476d37543275aF4c738Ae8a27893
Arbitrum0x0451f67bA61966C346daBAbB50a30Cc6A9A67C690xF01281a6DfDe5506C5049c9BBf8C7E087b9bD4bF
Avalanche0x8aD3f00e91F0a3Ad8b0dF897c19EC345EaB761c40x43C6b39669355AF93DdEdc70e8eB44c226f09BFB
Polygon0x855FbD0D57fF5B1e8263e3cCDf3384545fbaF8630x1d8347B427964fad8a742e7f9442a4E89346400a
Base0xad87684D27e6e58F055E6878A9F11F8c52A5b0F50x97CB9e81d480A2AB03299760654C1DDC0C16bE07
BNB0x020E452b463568f55BAc6Dc5aFC8F0B62Ea5f0f30x9062F78b631f33D24Ed058cBc116A653452ea82A
Optimism0x861Be72d464b6F1C99880B9bE476D40e8F9b5Bce0x365d47ceD3D7Eb6a9bdB3814aA23cc06B2D33Ef8

VotingChainRobot:

Old ContractNew Contract
Mainnet0x7Ed0A6A294Cf085c90917c0ee1aa34e7959325580xbC3210bfff692a5bbDBB068D42Ab4eAF28b01Ee0
Avalanche0x10E49034306EaA663646773C04b7B67E81eD0D520x2cf0fA5b36F0f89a5EA18F835d1375974a7720B8
Polygon0xbe7998712402B6A63975515A532Ce503437998b70x1180eE41eC15Dd0accC13a1e646B3152bECFf8F6

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

The decoded on-chain data exposes only a single top-level action: an execute() fallback call to a payload contract address on mainnet, with no decoded internal arguments. This is the standard pattern for Aave governance proposals, where the actual granular logic (cancel(), register(), withdrawLink(), emergencyTokenTransfer()) is encoded in the payload contract's bytecode rather than being visible in the proposal's calldata arguments. The proposal description is detailed and specific, listing exact old/new contract addresses for StataRefreshRewardRobot and VotingChainRobot across 8+ networks, consistent with a maintenance-style proposal referencing multiple per-chain payload contracts (as confirmed by the linked implementation source files for Ethereum, Polygon, Avalanche, Optimism, Arbitrum, Base, and BNB). However, because the decoded calldata for this proposal only shows the single mainnet execute() call without decoded sub-calls, I cannot directly verify that the specific addresses, cancel/register sequence, or LINK migration described in the prose exactly match the internal logic executed by the payload. There is no evidence of contradiction — the single visible action is generic and does not conflict with the description — but the depth of internal verification is limited. Given this opacity, I mark confidence as low: the proposal appears consistent with what's typically expected for this type of maintenance action, but a full trace of the internal payload logic (which lives in referenced Solidity source, not in the decoded calldata provided) would be needed for a high-confidence line-by-line match. No contradictions, mismatched targets, or extra/omitted high-level claims were found within the scope of what could be verified.

Generated by Kvorum
model: claude-sonnet-5
provider: anthropic
profile: anthropic-strong-v1
prompt: v1.0
generated: 2mo ago
Review the decoded actions ↗

04Actions

1 total
#0fallback()chain 0x1
Target
0x80ea…2057
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters37
VP participating792.9K
Outcome (current)For
Current support100%

06Voters

37 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.