BGD. Aave v3 cross-chain listing template

Development
1

TL;DR;

We released a template repository to list assets on Aave v3 Polygon with the goal to embrace a standard and reduce the complexity of using the Aave cross-chain governance system created by the Aave Companies some time ago.

You can find the template code HERE! :rocket:


Current state

While most non-Ethereum mainnet proposals are currently facilitated by Snapshot voting and the Aave Guardian, on Polygon, on-chain & cross-chain governance has been available for a while.
For example, in January 2022 there has been a proposal to add and alter assets on the Aave v2 Polygon pool.

However, cross-chain proposals are not completely trivial as they usually require double encoding of the transaction payload, as the payload is forwarded from Ethereum’s governance through a bridge to the executor on the other side of the bridge (e.g. Polygon).


Cross-chain listing template

The cross-chain listing template reduces the complexity of this process, by abstracting the bridging logic into a separate contract and enforcing certain assumptions.

Assumptions

  1. When using the bridge template we assume that the payload is deployed on the actual target chain.
  2. The payload on the target chain expects to be called via DELEGATECALL from the PolygonBridgeExecutor.

These assumptions allowed us to deploy the CrosschainForwarderPolygon contract on Ethereum, which handles the bridging, so all that’s left to do for the proposer is to create the L2Payload on the chosen chain and the creation of the proposal on AaveGovernanceV2

bridge-listing
bridge-listing1424Ă—1267 165 KB

Architecture & flow of proposal creation via the cross-chain listing template


By example

Here is how you would create a proposal to list MiMatic(MAI) on Polygon:

Relevant Addresses

Deploy the payload on Polygon

First, you need to deploy your desired payload on Polygon. In this case, the payload is already created so all that is left to do is to deploy it via sh deploy-polygon.sh DeployPolygonMiMatic . The shell-script will broadcast the deployment and try to verify a few times, to avoid frequent verification issues on polygonscan.com.

As a result, we will have our deployed payload MiMaticPayload :rainbow:

Create the governance proposal

With the MiMaticPayload deployed in the target chain, and the CrosschainForwarderPolygon contract common and also deployed on Ethereum, all that is left to do is to create() the governance proposal on AaveGovernanceV2, similar to any other proposal.

Note: To create the proposal on AaveGovernanceV2 you need to be in possession of 80k AAVE proposition power (balance or proposition delegation). The address which creates the proposal does not need to be the same address deploying the Payload on the target chain.

Therefore you need:

  • The L2 payload address.
  • The IPFS hash (make sure it’s the hash for the json generated by the aip repository)

The rest of the parameters are static:

{
  "executor": "0xee56e2b3d491590b5b31738cc34d5232f378a8d5",
  "targets": [
    "0x158a6bc04f0828318821bae797f50b0a1299d45b"
  ],
  "values": [
    "0"
  ],
  "signatures": [
    "execute(address)"
  ],
  "calldatas": [
    "0x00000000000000000000000024bb1df39eb811d4a7d82e9ff4763456750f9750" # abi.encode(l2PayloadAddress)
  ],
  "withDelegatecalls": [
    true
  ],
  "ipfsHash": "<ipfsHash>"
}

It is possible to create the proposal also via Etherscan, where it would look the following way (this is an example, it should include the appropriate parameters for a specific proposal.

etherscan-create-proposal
etherscan-create-proposal1211Ă—787 62.5 KB


Coming next

Tooling around cross-chain communication on Aave will become more and more important. Starting with Optimism & Arbitrum, and following with all other networks, during the next months every Aave instance will be controlled via cross-chain governance from the AaveGovernanceV2 on Ethereum.

Therefore we’ll extend the tooling around emerging bridges to further embrace decentralization of the governance.

As always, for anybody building on top of Aave and in need of support for this tool or any other, reach us out on Twitter, the #bored-ghosts channel on the Aave Discord or even in this forum.

10 Likes
2

Love this. So you are saying instead of passing a big heavy object across a bridge, you

  1. load instructions on the destination side for how to build the object,
  2. create a command on the origin side
  3. pass the (small, light) command across the bridge to trigger the instructions being executed to build the big heavy object

Do i understand that right? Smart!!

1 Like
4

Correct.
Apart from the simplification of how to build the “object” to pass through the bridge, we think it is also a more natural high-level to indicate on the destination side “what you want to do”.

Architecture-wise, you can think of it like this:

  1. You prepare an “action” to do on certain contracts on a certain network.
  2. The “action” seats there until Aave on that network receives approval from governance to execute it.
2 Likes