Rescue Mission Phase 2, 3

Simple Summary

This proposal outlines the final stages of the "Rescue Mission" for tokens erroneously sent to Aave ecosystem smart contracts. Phase 2 and 3 amalgamates the efforts of both phases into a single proposal, covering tokens locked in Aave v1, v2, v2 amm and v3 contracts (across various networks) provided their aggregated value exceeds $1,000. The proposal aims to release these locked tokens which the users can claim by interacting with the Rescue Mission smart contract, or via the utility interface available on https://rescue.bgdlabs.com/

Motivation

As an item part of the Aave <> BGD engagement Phase 1 described here, the rescue mission was created to support users of the Aave ecosystem who sent by mistake the tokens to the wrong smart contract addresses. While Phase 1 of the Rescue Mission has been completed, phases 2 and 3 remained pending. After evaluating the necessary interactions for both phases, it was decided to present them as a unified proposal.

The following table represents the tokens to rescue from various aave ecosystem contracts:

Specification

For wallets to be able to claim the tokens they sent to the contracts specified on Phase 2 and 3, we have created a different Merkle tree for every claimable token. With the roots and amounts, every wallet will be able to claim by calling the AaveMerkleDistributor contract similar to what was being done in Phase 1. For more details of which wallets are eligible for claims you can check here.

The following Aave contracts will be updated by adding a rescue function that can transfer the stuck funds to the Merkle distributor contract by the payloads.

• Aave v1 pool
• Aave v2 amm pool
• Aave v2 ethereum pool
• Aave v2 polygon pool
• Aave v2 avalanche pool
• Aave v2 aRai contract on ethereum
• Aave v2 aUsdt contract on ethereum
• Aave v2 aDai contract on polygon
• Aave v2 aUsdc contract on polygon
• Aave v3 pool on optimism

Once the contracts are updated, the payload will activate the Merkle distributor contract and rescue the stuck funds and send them to the Merkle distributor contract. For ethereum network we will use the same Merkle distributor contract as in Phase 1, while for other networks new ones will be deployed with the owner of the Merkle distributor set as the short executor.

Note: The payload on avalanche will be executed by the guardian

Security Considerations

• Implementation diffs have been generated to see that the new implementations only differ on the rescue logic.
• Storage layouts diffs have also been generated for the contracts where the implementation is updated.

Both the implementation diffs and storage diffs for all the contracts can be found here.

References

• Implementation: Ethereum, Polygon, Avalanche, Optimism
• Tests: Ethereum, Polygon, Avalanche, Optimism
• Discussion

Copyright

Copyright and related rights waived via CC0.