# BGD. Aave v3 cross-chain listing template **URL:** \ **Category:** Development\ **Created:** [August 17, 2022, 3:07pm UTC](https://governance.aave.com/t/bgd-aave-v3-cross-chain-listing-template/9354 "2022-08-17T15:07:16Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [August 17, 2022, 3:07pm UTC](https://governance.aave.com/t/bgd-aave-v3-cross-chain-listing-template/9354/1 "2022-08-17T15:07:16Z")
## 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](https://github.com/aave/governance-crosschain-bridges) created by the Aave Companies some time ago. You can find the template code [HERE](https://github.com/bgd-labs/aave-v3-crosschain-listing-template)! 🚀 ## Current state While most non-Ethereum mainnet proposals are currently facilitated by Snapshot voting and the [Aave Guardian](https://governance.aave.com/t/community-guardian-renewal/9177/8), on Polygon, on-chain & cross-chain governance has been available for a while. For example, in January 2022 there has been a [proposal](https://app.aave.com/governance/proposal/56/) 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](https://etherscan.io/address/0x158a6bC04F0828318821baE797f50B0A1299d45b) 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](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/c/c6b43fcdaf7f10b48a0c890b84c6fbabb3e28fb6.png) _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** - [CrosschainForwarderPolygon](https://etherscan.io/address/0x158a6bC04F0828318821baE797f50B0A1299d45b#code): the generic forwarder contract for Ethereum → Polygon proposals. - [AaveGovernanceV2](https://etherscan.io/address/0xEC568fffba86c094cf06b22134B23074DFE2252c): the Aave governance contract, where proposals are created and voted for. ### Deploy the payload on Polygon First, you need to deploy your desired payload on Polygon. In this case, the payload is already [created](https://github.com/bgd-labs/aave-v3-crosschain-listing-template/blob/master/src/contracts/polygon/MiMaticPayload.sol) 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](http://polygonscan.com). As a result, we will have our deployed payload [MiMaticPayload](https://polygonscan.com/address/0x24bb1Df39EB811d4a7D82e9Ff4763456750f9750#code) 🌈 ### 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](https://github.com/aave/aip) repository) The rest of the parameters are static: ```auto { "executor": "0xee56e2b3d491590b5b31738cc34d5232f378a8d5", "targets": [ "0x158a6bc04f0828318821bae797f50b0a1299d45b" ], "values": [ "0" ], "signatures": [ "execute(address)" ], "calldatas": [ "0x00000000000000000000000024bb1df39eb811d4a7d82e9ff4763456750f9750" # abi.encode(l2PayloadAddress) ], "withDelegatecalls": [ true ], "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](https://europe1.discourse-cdn.com/flex013/uploads/aave/original/2X/0/05f0d05eac722e6d9890943aa55fff9265596fc2.png) ## Coming next Tooling around cross-chain communication on Aave will become more and more important. Starting with [Optimism](https://github.com/aave/governance-crosschain-bridges#optimism-governance-bridge) & [Arbitrum](https://github.com/aave/governance-crosschain-bridges#arbitrum-governance-bridge), 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](https://twitter.com/bgdlabs), the #bored-ghosts channel on the Aave Discord or even in this forum. ---
**Author:** ![ml\_sudo](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@ml\_sudo](https://governance.aave.com/u/ml_sudo)\ **Post date:** [September 20, 2022, 10:36pm UTC](https://governance.aave.com/t/bgd-aave-v3-cross-chain-listing-template/9354/2 "2022-09-20T22:36:31Z")
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!! ---
**Author:** ![bgdlabs](https://dub1.discourse-cdn.com/flex013/user_avatar/governance.aave.com/bgdlabs/32/1829_2.png) [@bgdlabs](https://governance.aave.com/u/bgdlabs)\ **Post date:** [September 21, 2022, 7:49am UTC](https://governance.aave.com/t/bgd-aave-v3-cross-chain-listing-template/9354/4 "2022-09-21T07:49:34Z")
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.