Technical maintenance proposals

Development
21

a.DI update: CCIP bridge adapters and CCC (CrossChainController)


Simple Summary

Technical maintenance proposal to update the CrossChainController and CCIP Bridge Adapters components of a.DI (Aave Delivery Infrastructure).


Motivation

Set of minor improvements on the CrossChainController smart contract to ease and standardise off chain tracking of a.DI contracts and events; and update of the Chainlink CCIP Bridge Adapter to be compatible with the new CCIP version.


Specification


Bridge adapters

On this side, the CCIP Bridge Updated is updated to have full compatibility with CCIP v1.2.0. This affects Ethereum, Polygon PoS, BNBChain and Avalanche.

Network CCIP
Ethereum 0xB7a6618df58626C3a122ABAFD6Ee63Af63f3Ef29
Polygon 0xe79757D55a1600eF28D816a893E78E9FCDE2019E
Avalanche 0x2b88C83727B0E290B76EB3F6133994fF81B7f355
BNBChain 0xAE93BEa44dcbE52B625169588574d31e36fb3A67

Cross-chain controller (CCC)

On the CrossChainController (CCC) implementation, we have updated the logic so that all bridged messages will be treated the same even if required confirmation have already been reached (previously these messages where ignored in practise).

Network CrossChainController Impl
Ethereum 0x28559c2F4B038b1E836fA419DCcDe7454d8Fe215
Polygon 0x87a95917DE670088d81B9a8B30E3B36704Ba3043
Avalanche 0x5Ef80c5eB6CF65Dab8cD1C0ee258a6D2bD38Bd22
BNBChain 0xf41193E25408F652AF878c47E4401A01B5E4B682
Gnosis 0x5e06b10B3b9c3E1c0996D2544A35B9839Be02922
Arbitrum 0x6e633269af45F37c44659D98f382dd0DD524E5Df
Optimism 0xa5cc218513305221201f196760E9e64e9D49d98A
Metis 0xa198Fac58E02A5C5F8F7e877895d50cFa9ad1E04
Base 0x9b6f5ef589A3DD08670Dd146C11C4Fb33E04494F
Scroll 0x5e06b10B3b9c3E1c0996D2544A35B9839Be02922


Security

The updates has been reviewed by Certora, the engaged security provider of the Aave DAO.


References

5 Likes
22

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate :ghost:
https://vote.onaave.com/proposal/?proposalId=53

3 Likes
23

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=56

2 Likes
24

Hello BGD, the GUI for the Harmony markets and dashboards pages is no longer displaying relevant data. Can you confirm its just the GUI not functioning, and should collateral asset repeg happen, we the lenders, can get our funds back?

1 Like
25

Hello @Tobes . We are not in charge of app.aave.com, but the team maintaining it (Aave Labs) has confirmed the issue is related with fetching the data from from the Harmony network, because as Chainlink deprecated support for the network, some helper smart contracts should be adapted.
That doesn’t have any implication on the core Aave pool itself.

2 Likes
26

a.DI. Native bridge adapters update


Simple Summary

This proposal updates the Native bridge adapters used on a.DI, to add extra naming metadata and make the gas limit configurations more granular.


Motivation

For the past month with a.DI in production, we have noticed small improvements due to the specific mechanics of each bridge provider. Additionally, as we improve the off-chain systems (e.g. monitoring) surrounding a.DI, sometimes it is simply better to add features to the smart contracts to facilitate this off-chain infrastructure.


Specification

Updates the Native bridge adapters used to connect between networks to add Adapter Name to the contracts and provider specific gasLimit configuration

Network Polygon Native Gnosis Native Metis Native Arbitrum Native Optimism Native Base Native Scroll Native Same Chain
Ethereum 0x1562F1b2487F892BBA8Ef325aF054Fd157510a71 0x7238d75fD75bb936E83b75854c653F104Ce9c9d8 0x6B3Dc800E7c813Db3fe8D0F30fDCaE636935dC14 0x88d6D01e08d3e64513b15fD46528dBbA7d755883 0x0e24524778fdc67f53eEf144b8cbf50261E930B3 0xa5948b0ac79f72966dFFC5C13E44f6dfDD3D58A0 0xA4dC3F123e1c601A19B3DC8382BB9311F678cafA 0x6cfbd2aA4691fc18B9C209bDd43DC3943C228FCf
Polygon 0x853649f897383f89d8441346Cf26a9ed02720B02 - - - - - - -
Gnosis 0x3C06dce358add17aAf230f2234bCCC4afd50d090 - - - - - -
Metis - 0xf41193E25408F652AF878c47E4401A01B5E4B682 - - - - -
Arbitrum - - 0xc8a2ADC4261c6b669CdFf69E717E77C9cFeB420d - - - -
Optimism - - - 0xa5cc218513305221201f196760E9e64e9D49d98A - - -
Base - - - - 0x7120b1f8e5b73c0C0DC99C6e52Fe4937E7EA11e0 - -
Scroll - - - - - 0x3C06dce358add17aAf230f2234bCCC4afd50d090 -

Code diffs for the different networks can be checked on a.DI diff repository for revision 2.
Adapter diffs: Native Adapters, BaseAdapter, IBaseAdapter


Security

The updates has been reviewed by Certora, the engaged security provider of the Aave DAO.


References

3 Likes
27

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=70

4 Likes
28

POOL_ADMIN renounceRole() by Guardian on v3 Scroll

Simple Summary

After some maturity time, it is perfectly safe for the Aave Guardian to renounce the POOL_ADMIN role on the newest pool: Aave v3 Scroll.

Motivation

Whenever Aave expands to a new network, this is done in a fully decentralised way via an on-chain governance proposal (e.g. Aave v3 BNB Chain).
Major permissions (upgradeability) of the pool are set to the Aave governance from day 0, but the POOL_ADMIN is given to the Aave Guardian during a period of time for security, even if almost never exercised.
From a technical/security perspective, we don’t see any risk at the moment or need for the Guardian to hold this role anymore, so we will coordinate with its members to renounce on the only applicable pool: Aave v3 Scroll.

Specification

This proposal doesn’t require any governance procedure (Snapshot, on-chain), as the renounce is done directly by the Guardian.

The Aave Guardian (Safe) on Scroll will call the renounceRole() function for the POOL_ADMIN and their own address.

1 Like
29

LayerZero bridge adapter update to V2


Simple Summary

This proposal updates the LayerZero bridge adapters used on a.DI to connect Ethereum with Polygon, Avalanche, Binance and Gnosis to the new LayerZero V2 version.


Motivation

Since the activation of a.DI in production, LayerZero one of its underlying cross-chain communication providers has updated its infrastructure to version 2.
This proposal replaces the a.DI LayerZero adapter with the new version.


Specification

Updates the LayerZero bridge adapters used to connect between networks to LayerZero V2 and, similar to what has been done on proposal 56 for CCIP, adds an adapter name metadata to the smart contract, to facilitate off-chain tracking.

Network LayerZero
Ethereum 0x8410d9BD353b420ebA8C48ff1B0518426C280FCC
Polygon 0x7FAE7765abB4c8f778d57337bB720d0BC53057e3
Avalanche 0x10f02995a399C0dC0FaF29914220E9C1bCdE8640
Binance 0xa5cc218513305221201f196760E9e64e9D49d98A
Gnosis 0x9b6f5ef589A3DD08670Dd146C11C4Fb33E04494F
2 Likes
30

CAPO on v2 and misc oracles maintenance


Simple Summary

This proposal activates the correlated-assets price oracle (CAPO) system for fiat-pegged stable coins on Aave V2 pools, and does extra miscellaneous updates on price feeds of Aave v2.


Motivation

To continue enhancing the security of the protocol using CAPO and to align with the recent approved proposal for Aave v3, we are introducing the activation of CAPO adapters for Aave v2 pools. As no LSTs are listed on the v2 (stETH is not applicable), we are only applying the adapters to the fiat-pegged stablecoins.

This proposal also includes an update of the oracle for DPI from DPI / ETH to DPI / USD.


Specification


Oracles will be updated using ORACLE.setAssetSource() method. Below is the list of assets per network to be updated:


All assets affected

Network Stables
Mainnet USDC, USDT, DAI, USDP, sUSD, FRAX, GUSD, LUSD, BUSD, TUSD, UST, DPI
Avalanche USDC.e, USDT.e, DAI.e
Polygon USDC.e, USDT, DAI

CAPO configurations

Asset Cap
USDC 4%
USDT 4%
DAI 4%
USDP 4%
sUSD 4%
FRAX 4%
LUSD 10%
BUSD 4%
TUSD 4%
UST 4%

Misc specifications

1 Like
31

Hyperlane bridge adapter update to V3


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 function enableBridgeAdapters() will be called on the CrossChainController on the sender side, and allowReceiverBridgeAdapters() on the recipient side.
  • To remove the old forwarder adapters, the function disableBridgeAdapters() will be called on the CrossChainController on the sender side, and disallowReceiverBridgeAdapters() on the recipient side.

The old native receiver bridge adapters to remove are:

Network Native adapters
Arbitrum 0x3829943c53F2d00e20B58475aF19716724bF90Ba
Base 0x7b62461a3570c6AC8a9f8330421576e417B71EE7
Metis 0x746c675dAB49Bcd5BB9Dc85161f2d7Eb435009bf
Optimism 0x81d32B36380e6266e1BDd490eAC56cdB300afBe0
Scroll 0x118DFD5418890c0332042ab05173Db4A2C1d283c
2 Likes
32

Following the recommendation from risk providers to freeze different stablecoins on this post, we proceeded with the creation of the on-chain AIP for CAPO on v2 assets, as it will introduce extra solid protection.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=82

5 Likes
33

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=83

3 Likes
34

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=92

35

We can confirm the Aave Scroll Guardian has renounced the POOL_ADMIN role.

4 Likes
36

Aave Robot migration to Chainlink Automation v2 and gas-price optimization


Simple Summary

Proposal to migrate existing Aave robots from chainlink automation v1.2 to v2.1. For governance v3 robots on Ethereum, we also introduce gas-capped robots in order to limit execution based on network gas price.


Motivation

With the release of Chainlink automation v2.1, we think its a good idea to update the Aave Robot existing infrastructure to the latest v2.1 version.
In addition, as an effort to reduce the cost spent in gas in times of high gas prices, we also introduce gas-capped robots on mainnet which will be activated via this proposal.


Specification

For the migration, the robots registered on the previous robot operator contract will be cancelled and new robots will be registered using an updated robot operator contract, compatible with the newer version of chainlink automation v2.1.

The robots will be cancelled by calling the cancel() method by the payload on the previous robot operator contract, and after the delay has passed anyone could call the permissionless method withdrawLink() on the robot operator contract to withdraw the unused funds on the previous robots to the collector.

On the newer robot operator, the payload will call the register() method to register the keepers with the newer chainlink automation registry supporting v2.1.

Note: All aave governance v3 robots along with robots used for gsm swap freeze will be migrated via this proposal

Deployed AaveCLRobotOperator
Mainnet 0x1cDF8879eC8bE012bA959EB515b11008E0cb6323
Polygon 0xB4C212f5cD17E200019b07e6B1fDf124d35DBCf5
Avalanche 0x06d958772304e7220fc3E463756CE01Ed0D24db2
Optimism 0x55Cf9583D7D30DC4936bAee1f747591dBECe5df7
Arbitrum 0xaa944aD95e51CB83C1f35FAEEDfC7d2c31B0BB4d
Base 0x88db99eeBb390a2a4DcAC2E1DDb09c07E911C5C3
BNB 0x51Bd3d6011Dd0BD88Ee1bEA1a67be799A6A09D79
Deployed Gas Capped Robots
Gas Capped Governance Robot 0x1996c281235D99bB3c6B8d2afbEb8ac6c7A39C11
Gas Capped Voting Robot 0x7Ed0A6A294Cf085c90917c0ee1aa34e795932558
Gas Capped Execution Robot 0xBa37F9eDC52f57caFA3a13ddfD655797Cc4FE257
5 Likes
37

We have created an on-chain AIP for this proposal.

Voting will start in approximately 24 hours, participate :ghost:

https://vote.onaave.com/proposal/?proposalId=109

2 Likes
38

For extra visibility on items that were not really clear on the description, the payloads also include the following minor actions:

  • Activation of a Robot action to enable Aave pool incentives on stataTokens. Whenever incentives are enabled on an asset listed on Aave after the creation of its stataToken, the stataToken needs to be triggered to start tracking those rewards on its own internal accounting.
    This is a permission-less process (anybody can do it), but given that stataTokens are part of the Aave periphery infrastructure and the low cost of the action, we have added a Robot action to automate this.
  • The CrossChainController contract of a.DI on Ethereum is refilled with 1 ETH from the Aave Collector.
39

a.DI v1.1 Shuffle activation


Simple Summary

Proposal to update a.DI with the new Shuffle mechanism, included into the v1.1 release presented HERE.


Motivation

a.DI v1 has one constraint, that even if not major, limits the scalability of the system: whenever a new underlying bridge provider is added to the set of a communication path, each message on that path will be passed through all the bridges, no matter if the consensus required on the recipient side is lower.
For example, currently all messages Ethereum → Polygon are sent via CCIP, LayerZero, Hyperlane, and the Polygon native bridge, even if the consensus required on the Polygon side is 3-of-4. This means that even if consensus was reached already before the slowest bridge delivers the message (Polygon native in this case), the cost incurred is of the whole set of 4 bridges, not only 3.


a.DI v1.1 (and more specifically its Shuffling feature) introduces a mechanism for, whenever a message needs to be sent, the system choosing pseudo-randomly a sub-set of all the available bridges for that specific path (e.g. Ethereum → Polygon) with optimal bandwidth size,
and only forwards the message via those bridges.

By doing this:

  • Cost is reduced on all those configurations with optimal bandwidth < bandwidth.
  • Any bottleneck to add new underlying bridge providers is removed, as increasing bandwidth doesn’t really have any effect on the optimal bandwidth of the path.
  • Security-wise, the pseudo-random nature of the shuffling mechanism improves the system, in the line of other rotation-based systems like validators-selection in PoS blockchains.

Specification

This proposal upgrades a.DI on every supported network with the new implementation containing the Shuffle mechanism; afterwards, it configures the new parameters required.


The upgrade adds a new _optimalBandwidthByChain mapping on CrossChainForwarder that will store the optimal bandwidth for every supported chain. This will be used to determine how many adapters will be used to pass a message to a destination network

The OptimalBandwidth used to update a.DI will be:

Origin Network Ethereum Polygon Avalanche Arbitrum Optimism Base Gnosis Metis Binance Scroll
Ethereum - 4 2 1 1 1 2 1 2 1
Polygon 3 - - - - - - - - -
Avalanche 2 - - - - - - - - -
Arbitrum - - - - - - - - - -
Optimism - - - - - - - - - -
Base - - - - - - - - - -
Gnosis - - - - - - - - - -
Metis - - - - - - - - - -
Binance - - - - - - - - - -
Scroll - - - - - - - - - -

The method used to initialize a.DI with the new bandwidth configurations is:

function initializeRevision(
  OptimalBandwidthByChain[] memory optimalBandwidthByChain
) external reinitializer(3) {
  _updateOptimalBandwidthByChain(optimalBandwidthByChain);
}

The new CrossChainController implementations for every supported network are the following:

Network CCC v1.1 implementation with Shuffle support
Ethereum 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Polygon 0x191f2bd27f1ce4318f9a0c6b82688c66cd7ad3ba
Avalanche 0x23f5150ace7382c7160a2192c3f9f77444f420d9
Arbitrum 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Optimism 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Base 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Gnosis 0x88e9f8e208ba5ae72b56861d63cbf70fd2320f5c
Metis 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d
Binance 0xda81fb369942e43d4797e79f2c4cbef9fe58b90a
Scroll 0x92f4736b72d131d836b3e4d4c3c23fe53150ce4d

Security

Certora audit report on the Shuffle update can be found HERE.


References

  • Implementation: CrossChainController Shuffle update payloads implementation
  • Tests: CrossChainController Shuffle update tests
  • Diffs: CrossChainController implementation address change diffs
3 Likes
40

a.DI. Enable support to ZKSync


Summary

Proposal to register the necessary ZKSync adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 ZKSync.


Motivation

In order to be able to pass messages from Ethereum to ZKSync via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → ZKSync smart contract enabled in the system.

The first case of message passing Ethereum → ZKSync is the activation proposal for an Aave v3 ZKSync pool and consequently, to be able to execute on the ZKSync side the payload, the Aave governance should approve in advance the a.DI adapter smart contract.

This procedure mirrors the requirements on previous networks like Scroll.


Specification

The proposal payload simply registers a pre-deployed ZKSync adapter (with the necessary configurations to communicate with the ZKSync 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 new a.DI smart contracts for ZKSync support:


Adapters

Network ZkSync Adapter
Ethereum 0x6aD9d4147467f08b165e1b6364584C5d28898b84
ZkSync 0x1BC5C10CAe378fDbd7D52ec4F9f34590a619c68E

a.DI infrastructural contracts

Contract Address
CrossChainController 0x800813f4714BC7A0a95310e3fB9e4f18872CA92C
Granular Guardian 0xe0e23196D42b54F262a3DE952e6B34B197D1A228
5 Likes