Activate Proof of Reserve
01Summary
Activate the Proof of Reserve mechanism on Aave V2 Avalanche by adding the Proof of Reserve Admin role to the Pool Configurator. This protects against infinite minting attacks on bridged assets (DAI.e, USDC.e, USDT.e, AAVE.e, LINK.e, WBTC.e, BTC.b, WETH.e) by verifying that tokens minted on Avalanche have corresponding backing on their origination networks.
- Type
- protocol addition
Key changes
- Update Pool Configurator implementation to a new version that supports Proof of Reserve Admin role(high)
- Set proof of reserve executor as admin to enable activation of proof of reserve mechanism for V2 Avalanche(high)
- Enable proof of reserve checks for bridged assets on Avalanche (DAI.e, USDC.e, USDT.e, AAVE.e, LINK.e, WBTC.e, BTC.b, WETH.e)(high)
Notable concerns
- This adds a new administrative role that requires proper governance and operational oversight to function correctly
Generated by Kvorum
02Description
Simple Summary
This proposal aims to add Proof of Reserve Admin role to the Avalanche V2 Pool Configurator in order to activate the proof of reserve mechanism.
Motivation
At the moment, in Aave v3 Avalanche there are multiple assets with a “bridged” nature: DAI.e, USDC.e, USDT.e, AAVE.e, LINK.e, WBTC.e, BTC.b and WETH.e.
These assets have 2 sides: one deposit account in the network where the asset originated (Ethereum in the case of the *.e assets) and a token smart contract on the “usage” chain (Avalanche in this case).
Given that architecture, there are 2 main attack vectors to exploit “bridged” assets:
An exploit on the usage network, generally minting tokens that have no backing on the origination network, usually called an “infinite minting attack”. An exploit on the origination network, extracting tokens from the deposit contract.
In order to prevent the 1) type of attack Proof of Reserve mechanism was introduced and activated for the V3 Pool on Avalanche almost a year ago. Now we are ready to activate it for the V2 as well.
Specification
-
AaveV2Avalanche.POOL_ADDRESSES_PROVIDER.setLendingPoolConfiguratorImpl()will be called with the new configurator address passed. -
AaveV2Avalanche.POOL_ADDRESSES_PROVIDER.setAddress()will be called to set proof of reserve executor as the admin.
References
- Implementation: AaveV2Avalanche
- Tests: AaveV2Avalanche
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal is a cross-chain Aave governance action: the on-chain calldata on the origin chain (mainnet) only contains a single 'forwardPayloadForExecution' call that dispatches payload #9 to the Avalanche chain (43114) via the known cross-chain payload controller address. This is the standard mechanism BGD Labs proposals use to execute a pre-deployed payload contract on the target chain — the actual logic (setLendingPoolConfiguratorImpl and setAddress calls described in the Specification section) lives inside that payload contract on Avalanche, which is not directly decodable from this mainnet calldata. The target chain (Avalanche) and the general intent (activating Proof of Reserve for the V2 pool) are consistent with the description. I cannot independently verify from this single decoded action that the payload contract itself calls setLendingPoolConfiguratorImpl and setAddress with the correct proof-of-reserve executor address, since those calls are internal to the forwarded payload and not exposed in this transaction's decoded arguments. This is a routine and expected pattern for this type of proposal, not a sign of concealment, so I do not flag it as a discrepancy, but confidence is medium rather than high because the specific parameter-level claims in the Specification section cannot be cross-checked against this particular decoded action alone.
Generated by Kvorum
04Actions
- Target
- 0x9aee…2bc7
- Value
- 0 wei
- Function
- forwardPayloadForExecution((uint256,uint8,address,uint40))
- Arguments
{ "0": [ "43114", "1", "0x1140CB7CAfAcC745771C2Ea31e7B5C653c5d0B80", "9" ] }- Calldata
05Tally
Summed from votes
06Voters
| Voter | Choice | % of total | Rationale | ||
|---|---|---|---|---|---|
| 570x57ab…2922 | For | 144.3K | 25.62% | — | 3y ago |
| 320x329c…3ed4 | For | 103.1K | 18.31% | — | 3y ago |
| 070x0703…961b | For | 86.8K | 15.40% | — | 3y ago |
| 230x2331…7e73 | For | 60K | 10.65% | — | 3y ago |
| 2C0x2cc1…4df1 | For | 43.7K | 7.75% | — | 3y ago |
| B90xb933…8dd1 | For | 42.6K | 7.56% | — | 3y ago |
| EZezr3al.eth0x8659…7d0e | For | 38.1K | 6.76% | — | 3y ago |
| 870x8787…ea52 | For | 21.2K | 3.76% | — | 3y ago |
| E40xe459…e666 | For | 20K | 3.55% | — | 3y ago |
| 180x1855…98ba | For | 3.6K | 0.63% | — | 3y ago |
| EA0xea17…6676 | For | 38.6 | 0.01% | — | 3y ago |
| 570x5762…a752 | For | 1 | 0.00% | — | 3y ago |
07Forum
No forum thread is confidently linked to this proposal.