Skip to content

Latest commit

 

History

History
125 lines (72 loc) · 8.34 KB

98-aave-v3-retroactive-funding.md

File metadata and controls

125 lines (72 loc) · 8.34 KB
Raw

Proposal 98. Aave V3 retroactive funding to the Aave genesis team


Voting link

https://app.aave.com/governance/proposal/?proposalId=98


Governance forum discussion

https://governance.aave.com/t/arc-aave-v3-retroactive-funding/9250


BGD analysis


Proposal types

💸 funds-release

🔗 🌉 cross-chain execution


Context

This proposal releases funds of multiple assets from the collectors of Aave v2 Ethereum and Aave v2 Polygon to an account controlled by the Aave genesis team, as retro-active compensation for the development of Aave v3.

❗ ❗ IMPORTANT During this analysis, we detected the Polygon side of the proposal will fail on execution if some permissions are not received on smart contracts of the Aave system before the execution time.


Proposal creation

Transaction: https://etherscan.io/tx/0x25ca35f005aae409fc35bfc2be4edfc221d12fbb58ab47d0ad16f5aadb5ced85

- id: 98
- creator: 0xdc6d052700a2bb1f45852a65acb61c194ef09b61
- executor: 0xee56e2b3d491590b5b31738cc34d5232f378a8d5
- targets: [0xdb89487a449274478e984665b8692afc67459def,0xfe5e5d361b2ad62c541bab87c45a0b9b018389a2]
- values: [0,0]
- signatures: [execute(),sendMessageToChild(address,bytes)]
- calldatas: [0x,0x000000000000000000000000dc9a35b16db4e126cfedc41322b3a36454b1f7720000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000024000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000120000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000ccf14215e0134d6709c7dd7fa172cec40e97bfb100000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000004614619540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001]
- withDelegatecalls: [true,false]
- startBlock: 15479095
- endBlock: 15498295
- strategy: 0xb7e383ef9b1e9189fc0f71fb30af8aa14377429e
- ipfsHash: 0x38f48494a97a61ec7500a8f8c92e4a233dd4bda22255a72ceb76d7025952bf69

Aave Seatbelt report

https://github.com/bgd-labs/seatbelt-for-ghosts/blob/main/reports/Aave/0xEC568fffba86c094cf06b22134B23074DFE2252c/098.md


Technical analysis

Even if simple in nature, the implementation of this proposal is extensive, and involving interaction with systems on Ethereum (collector of Aave v2 Ethereum), together with cross-chain interaction (Polygon), involving contract upgrades. As commented previously, there is a mistake on the Polygon, but given the isolation of the Ethereum/Polygon actions, this would/will only make the Polygon actions fail on execution.

To simplify the analysis, we will split per network:


Ethereum

The Ethereum side of the proposal simply releases amounts of a set of pre-defined assets from the Aave v2 Collector and the AAVE ecosystem reserve, to a Gnosis Safe defined as the recipient of the Aave genesis team.

We have verified:

  • The proper transfer() functions are called on the correct controller of collector smart contract.
  • Both the v2 collector and the AAVE ecosystem reserves hold enough funds for the transfers.
  • The assets transferred and amounts are as defined in the AIP text, but the sync between forum description, Snapshot and final aip is quite convoluted.

We can't verify assessments on the calculations of amounts involving prices (with discount), because it is not completely clear on the specifications.

In addition, the proposal doesn't establish any lock-up mechanism on AAVE/stkAAVE as defined on the forum, which we believe is really misleading, as it simply transfers AAVE to the Aave genesis team account.


Polygon

The second action of the proposal communicates with main component of the Polygon generic messaging bridge, the FxRoot smart contract.

The messaged transfer to Polygon has as target the PolygonBridgeExecutor on the Polygon network. On that side, a wrapper proposal will be queued to then execute the logic contained on the PolygonProposalPayload, which does the following:

  • Tries to upgrade the implementations under transparent proxy of both the v2 collector of Polygon and the v3 collector. The new implementation used is the one deployed HERE, which properly has REVISION 2. We have verified that this implementation has the functions to transfer and approve funds, but we would like to highlight that this is not the most updated version of the collector, as it lack streaming capabilities included into the one of Aave v2 Ethereum. In addition, the implementation lacks the usage of safeTransfer() and safeApprove(), which should not affect at the current moment, but could create problems and require an extra upgrade down the line.
  • The _fundsAdmin variable is assigned to a CollectorController smart contract, which has permissions over approve() and transfer() of the collector, and which in turn is controlled by the PolygonBridgeExecutor, executing the payload of this proposal.
  • Both the v2 collector and the AAVE ecosystem reserves hold enough funds for the transfers.
  • The assets transferred and amounts are as defined in the AIP text.

As we commented before, currently the PolygonBridgeExecutor executing the proposal doesn't have the admin role of the collector v2 transparent proxy, so the proposal will fail unless those permissions will be transferred before execution time. We have communicated the proposer the problem.

We highly encourage all parties contributing to Aave with proposals to, especially on relatively complex technical contributions like this one, ask a review in advance from BGD and follow standardise security procedures like the usage of this template repository for cross-chain proposal testing and creation https://github.com/bgd-labs/aave-v3-crosschain-listing-template.


BGD validations

❌ Proposal fails partially on execution.

✅ The code on the proposal payload corresponds to the proposal specification.

✅ Payload encoded via multiple targets, with both CALL and DELEGATECALL

✅ ** The proposal includes a proper tests suite, checking all necessary post-conditions.

❌ BGD reviewed the payload before the proposal was submitted.

❌ BGD reviewed the procedure followed to submit the proposal.

** The test suite doesn't detect the proposal failing, so it doesn't provide full proper coverage