KVORUM
aaveSource: Aave governance v3 · #353

Upgrade Aave instances to v3.5

executedAug 6, 2025, 09:12 AM UTCbyF70xf71f…1e02

01Summary

AISummary by Kvorumclaude-haiku-4-5

Upgrade Aave protocol instances from v3.4 to v3.5 to improve mathematical precision and rounding directionally in the accounting layer, affecting Pool, AToken, and VariableDebtToken implementations across all networks. Includes 96,050 USD reimbursement to BGD Labs for audit costs.

Type
contract upgrade
Funding
$96050

Key changes

  • Update Pool, AToken, and VariableDebtToken implementations to improve mathematical precision and directional rounding consistency(high)
  • Enhanced accounting mechanisms to address inherent mathematical imprecision from rebasing tokens on the lowest order of magnitudes(high)
  • Special handling for aAave implementation due to governance delegation integration(medium)
  • Special handling for vGHO implementation due to deprecated discount mechanism on stkAAVE(medium)
  • Transfer 96,050 USD as aUSDT to BGD Labs for audit reimbursement(low)

Notable concerns

  • Upgrade affects core protocol components (Pool, AToken, VariableDebtToken) across all networks and requires coordinated deployment
  • Mathematical precision changes, while extensively audited and tested, affect fundamental accounting mechanics of the protocol
ContractsPoolATokenVariableDebtTokenaAavevGHO
Generated by Kvorum
model: claude-haiku-4-5
provider: anthropic
profile: anthropic-fast-v1
prompt: v1.0
generated: 2mo ago
Read the description ↗

02Description

297 words

Simple Summary

Upgrade the Aave protocol instances from v3.4 to v3.5.

Motivation

Due to aspects like using rebasing tokens (a/v Tokens) on the accounting layer, Aave v3 has had well-known inherent mathematical imprecision on the lowest order of magnitudes. But even if this imprecision is highly frequently unavoidable, in the case of Aave v3, it has a kind of “chaotic” direction. This is different from standards like 4626, where the rounding is directionally explicit, consequently simpler to understand and reason about.

Even though this has not created major problems historically, we believe it is essential to enhance these mathematical mechanisms in a protocol as significant and widely adopted as Aave v3.

While originally these changes were part of the Aave v3.4 upgrade, they have been isolated in a v3.5 upgrade to have a reduced scope on 3.4 while having additional audits for v3.5.

Specification

The upgrade payload updates the implementations of the Pool, AToken & VariableDebtToken on all networks.

On mainnet the payloads varies slightly to account for:

  • aAave which has a different implementation due to the governance delegation integration
  • vGHO which has a different implementation due to the deprecated discount mechanism on stkAAVE

An additional action is included on mainnet which transfers 96,050 $ as aUSDT to a BGD Labs address, to reimburse the cost of the audits.

Security procedures

  • The upgrade was extensively unit tested and fuzzed.
  • Certora adapted its formal properties to ensure the upgrade's correctness.

In addition 4 audits by Independent Auditors were conducted.

References

Copyright

Copyright and related rights waived via CC0.

03Mismatch analysis

AIMismatch analysis by Kvorumlow confidenceclaude-sonnet-5
Consistent

All four decoded actions are opaque execute() fallback calls to distinct payload contracts on Ethereum mainnet. Because these are proxy/delegatecall-style governance executor calls, the actual internal logic (implementation upgrades for Pool/AToken/VariableDebtToken, the aAave and vGHO variant handling, and the aUSDT transfer to BGD Labs) is not visible in the decoded calldata — it lives inside the payload contracts' bytecode, which is not exposed here. This means I cannot directly confirm or contradict any of the specific numeric or targeting claims in the description (e.g., the exact $96,050 aUSDT amount, the specific aAave/vGHO implementation swaps, or coverage of 'all networks' — only mainnet chain_id 0x1 appears in this action set, which is expected since other networks are typically handled by separate per-network proposals). Nothing in the visible calldata contradicts the description, but the opacity of execute()-only calls means verification is fundamentally limited. Given the lack of decodable detail, I mark confidence as low and, absent any visible contradiction, assess the proposal as consistent with no flagged discrepancies. Delegates relying on this analysis should be aware that the low-level correctness of the upgrade payload content itself must be verified through the linked audits, diffs, and source code rather than through calldata decoding alone.

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

04Actions

4 total
#0fallback()chain 0x1
Target
0xd51b…d45b
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#1fallback()chain 0x1
Target
0x6ab8…b012
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#2fallback()chain 0x1
Target
0xb705…26d3
Value
0 wei
Function
fallback()
Arguments
{}
Calldata
#3fallback()chain 0x1
Target
0xfea1…f176
Value
0 wei
Function
fallback()
Arguments
{}
Calldata

05Tally

Summed from votes

Voters0
VP participating0
Outcome (current)—
Current support—

06Voters

0 total

No votes recorded yet.

07Forum

No forum thread is confidently linked to this proposal.