Hyperlane bridge adapter update to V3
01Summary
Update Hyperlane bridge adapters on Aave's a.DI to version V3 across multiple networks (Ethereum, Polygon, Avalanche, Binance, Gnosis) and remove old native bridge adapters from Optimism, Base, Arbitrum, Scroll, and Metis after verifying the new versions function properly.
- Type
- contract upgrade
Key changes
- Enable new Hyperlane V3 bridge adapters on Ethereum, Polygon, Avalanche, Binance, and Gnosis networks using enableBridgeAdapters() method(high)
- Remove old native bridge adapters on Arbitrum, Base, Metis, Optimism, and Scroll using disableBridgeAdapters() and disallowReceiverBridgeAdapters() methods(high)
- Add Adapter Name to contracts for improved off-chain tracking(medium)
Notable concerns
- Removal of old native bridges should only occur after verifying new Hyperlane V3 adapters function properly on all affected networks
Generated by Kvorum
02Description
Simple Summary
This proposal updates the bridge Hyperlane bridge adapters used on a.DI to connect Ethereum with Polygon, Avalanche, Binance and Gnosis to the new Hyperlane V3 version. Additionally, removes old native bridges on Optimism, Base, Arbitrum, Scroll and Metis, after verifying that the new active versions work properly.
Motivation
The main motivation of this proposal is to bring the Hyperlane bridge adapters to the up to date version (V3).
Specification
Updates the Hyperlane bridge adapters used to connect between networks to Hyperlane V3 and it also adds Adapter Name to the contracts to make it easy to track off chain
| Network | Hyperlane |
|---|---|
| Ethereum | 0x01dcb90Cf13b82Cde4A0BAcC655585a83Af3cCC1 |
| Polygon | 0x3e72665008dC237bdd91C04C10782Ed1987a4019 |
| Avalanche | 0x617332a777780F546261247F621051d0b98975Eb |
| Binance | 0x3F006299eC88985c18E6e885EeA29A49eC579882 |
| Gnosis | 0xA806DA549FcB2B4912a7dFFE4c1aA7A1ed0Bd5C9 |
To add the new forwarder adapters the method function enableBridgeAdapters(ForwarderBridgeAdapterConfigInput[] memory bridgeAdapters) external will be used,
and to remove the old forwarder adapters, the method function disableBridgeAdapters(BridgeAdapterToDisable[] memory bridgeAdapters) external will be called on each CrossChainController.
To add the new receiver adapters the method function allowReceiverBridgeAdapters(ReceiverBridgeAdapterConfigInput[] memory bridgeAdaptersInput) external will be used,
and to remove the old receiver adapters, the method function disallowReceiverBridgeAdapters(ReceiverBridgeAdapterConfigInput[] memory bridgeAdaptersInput) external will be called on each CrossChainController.
The old native receiver bridge adapters to remove are:
| Network | Native adapters |
|---|---|
| Arbitrum | 0x3829943c53F2d00e20B58475aF19716724bF90Ba |
| Base | 0x7b62461a3570c6AC8a9f8330421576e417B71EE7 |
| Metis | 0x746c675dAB49Bcd5BB9Dc85161f2d7Eb435009bf |
| Optimism | 0x81d32B36380e6266e1BDd490eAC56cdB300afBe0 |
| Scroll | 0x118DFD5418890c0332042ab05173Db4A2C1d283c |
Code diffs for the different networks can be checked on a.DI diff repository for revision 2. Adapter diffs: HLAdapter, BaseAdapter, IBaseAdapter
References
- Implementation: AaveV3Ethereum, AaveV3Polygon, AaveV3Avalanche, AaveV3Gnosis, AaveV3BNB, AaveV3Scroll, AaveV3Arbitrum, AaveV3Optimism, AaveV3Metis, AaveV3Base
- Tests: AaveV3Ethereum, AaveV3Polygon, AaveV3Avalanche, AaveV3Gnosis, AaveV3BNB, AaveV3Scroll, AaveV3Arbitrum, AaveV3Optimism, AaveV3Metis, AaveV3Base
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal description details a fairly specific and technical set of actions: enabling new Hyperlane V3 forwarder/receiver bridge adapters on five networks and disabling old native bridge adapters on five other networks, executed via calls to CrossChainController contracts on each respective chain. However, the only decoded on-chain action available is a single opaque execute() call (decoded as a fallback) to one payload contract on Ethereum mainnet, with no arguments. This is the typical BGD/Aave governance pattern where a payload contract's execute() function performs the real work internally, and none of that internal logic is exposed as decoded calldata here. Because of this, there is no way to directly verify from the provided decoded actions whether the specific adapter addresses, networks, or add/remove operations described in the prose actually match what the payload contract does — the calldata simply doesn't expose enough detail to compare against the prose's claims. I found no evidence of contradiction (no mismatched addresses, no unrelated transfers, nothing that looks suspicious), but I also cannot confirm the specifics claimed in the description solely from this decoded action. Given the lack of decodable detail, confidence in this assessment is low, and no discrepancies are being flagged since there is no concrete conflicting evidence — only an inability to fully verify magnitude/target-level claims from calldata alone.rooted in the payload contract's bytecode/cross-chain execution, which is standard practice and not itself a red flag.
Generated by Kvorum
04Actions
- Target
- 0x6f82…9885
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedNative bridge adapters update92%
- aaveexecutedUpdate a.DI implementation and CCIP adapters89%
- aaveexecutedLayerZero bridge adapter update to V287%
- aaveexecuteda.DI Celo path activation76%
- aaveexecuteda.DI Sonic path activation75%
- aaveexecuteda.DI Linea path activation74%
- aaveexecutedMonad aDI path activation74%
- aaveexecutedPlasma aDI path activation73%
- aaveexecutedMaintenance: Grant AL RETRY_ROLE on a.DI (Part 1)73%
- aaveexecutedX Layer network aDI path activation72%