Ink aDI path activation
01Summary
Register Ink network adapters on Aave Delivery Infrastructure (a.DI) to enable cross-chain message passing from Ethereum to Ink for GHO-related governance operations. This is a technical prerequisite for Aave Governance to control contracts on the Ink network.
- Type
- protocol addition
Key changes
- Enable Ink Native Adapter (0x98E78C2cD3013BF13a658E210e27C3732c8Dc48A) on Ethereum Cross-chain Controller to facilitate Ethereum → Ink communication(high)
- Register pre-deployed a.DI infrastructure contracts on Ink network including CrossChainController and Granular Guardian(high)
- Deploy Aave Governance contracts on Ink network including PayloadsController, Executor Level 1, Governance Guardian, and BGD Labs Guardian(high)
- Configure 1 out of 1 required confirmations for Ethereum → Ink message passing(medium)
Notable concerns
- This is a technical prerequisite and mirrors previous network integrations (Base, Optimism), suggesting established procedures
- The proposal requires coordination with GHO CCIP configuration proposal on Ink
Generated by Kvorum
02Description
Simple Summary
Proposal to register the necessary Ink adapters on a.DI, a technical pre-requirement to have Aave Governance-controlled contracts on Ink, in this case, cross-chain GHO-related to be listed on the Aave <> Ink friendly fork.
Motivation
In order to be able to pass messages from Ethereum to Ink via a.DI (Aave Delivery Infrastructure), it is necessary to at least have three valid adapters Ethereum → Ink smart contracts enabled in the system.
The first case of message passing Ethereum → Ink is the proposal for GHO CCIP configuration on Ink, and consequently, to be able to execute on the Ink side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts.
This procedure mirrors the requirements of previous networks like Base or Optimism.
Specification
The proposal payload simply registers pre-deployed Ink adapters (with the necessary configurations to communicate with the Ink a.DI) on the Ethereum a.DI instance.
This is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.
The following are the configured adapters for the Ethereum → Ink path. The required confirmations on the path are 1 out of 1.
| Network | Ink Native Adapter |
|---|---|
| Ethereum | 0x98E78C2cD3013BF13a658E210e27C3732c8Dc48A |
| Ink | 0xC2cD4F76B7a77AEaE3C04A9B6B105EC1Ad28e984 |
The new a.DI deployments on Ink network are as follows:
| Contract | Address |
|---|---|
| CrossChainController | 0x990B75fD1a2345D905a385dBC6e17BEe0Cb2f505 |
| Granular Guardian | 0xa2bDB2335Faf1940c99654c592B1a80618d79Fc9 |
The new Aave Governance deployments on Ink network are as follows:
| Contract | Address |
|---|---|
| PayloadsController | 0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0Cf |
| Executor Lvl 1 | 0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A |
| Governance Guardian | 0x1bBcC6F0BB563067Ca45450023a13E34fa963Fa9 |
| BGD Labs Guardian | 0x81D251dA015A0C7bD882918Ca1ec6B7B8E094585 |
References
- Adapter Implementations: Ink Native Adapters
- Payload Implementation: Payload
- Payload Tests: tests
- Diffs: a.DI diffs
- Snapshot: Direct-to-AIP
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal follows the standard Aave governance pattern where a single top-level action invokes execute() on a dedicated payload contract, which internally performs the detailed logic (in this case, presumably calling enableBridgeAdapters() on the Cross-chain Controller with the specific Ink adapter addresses described). The decoded calldata only shows this outer execute() call with no further decoded arguments, since the payload contract's internal logic is not unpacked in this dataset. This means I cannot directly verify from the calldata whether the specific adapter addresses, confirmation thresholds, or target chain match the prose. However, this is a well-known and expected structure for Aave AIP payloads (single execute() call to an audited payload contract), and there is nothing in the visible calldata that contradicts the description's claims about registering Ink bridge adapters. Given the lack of decoded internal calls, my confidence in this comparison is low, but I found no overt contradiction, target mismatch, or omitted major action between the one decoded action and the prose's single specification action. Therefore I assess this as consistent, with low confidence due to the opacity of the payload's internal execution.
Generated by Kvorum
04Actions
- Target
- 0x9cda…1b75
- 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
No semantically similar proposals found yet.