bgd-labs / aave-address-book Goto Github PK

Should be a secret.

Context

The Aave Address Book is currently missing these 2 addresses which are used in quite a few Proposal Payloads.

• #34
• 2. AAVE Incentives Controller: 0xd784927Ff2f95ba542BfC824c8a8a98F3495f6b5

Would be nice to have them added as well to reduce errors related to Aave addresses.

Why

For reference aave/aave-v3-core#701

Soon, all v3 instances will get the 3.0.1 update, and even more important, for testing could be good to have an AaveV3_1.sol on the address book.

Tips

There should not be many changes, mainly the addition of the flashloanable flag on the asset configuration, together with the interface implications of it.
But necessary to check it better

raised here #20 (comment) and makes sense imo

https://github.com/foundry-rs/foundry/blob/4ae40da76e9a1dbb56c136db509dc3e7eab703c8/testdata/cheats/Fork.t.sol in the new version of foundry it might get more reasonable to use this.

Would be helpful for integrators to have this address available.

afaik this contract is not linked to the Pool or any periphery contract, so this would need to be hardcoded as it is on the interface.

Would be nice if selecting/hovering an item, would show how to actually use it in code via address-book.
This can be useful especially as imports are wildly different on solc vs js:

js: AaveV3Ethereum.ASSETS.FRAX.A_TOKEN
solc: AaveV3EthereumAssets.FRAX_A_TOKEN

Currently we redefine abis where ever we need them, probably it would make sense to ship them as part of the js bundle.

Would be nice if there was an exposed library with eModeLabel = id mapping

It would be nice if the aave governance addresses would be exposed in the address book as well as they are used quite frequently (e.g. in proposals).

What?

Add to the Address Book the addresses of the contracts accruing the fees of the liquidity pool in the different networks (e.g. https://etherscan.io/address/0x464c71f6c2f760dda6093dcb91c24c39e5d6e18c), together with the controller contracts to be used by the governance Short Executor to transfer/approve/manage-streams on those collectors (e.g. https://etherscan.io/address/0x3d569673daa0575c936c7c67c4e6aeda69cc630c#code)

Why?

As we can see from multiple past governance proposals (BGD <> Aave, Aave Grants DAO, consolidation of v1/v2 RF, ...), it is quite common to interact with the collectors of the protocol. So it is pretty natural to have those addresses in the Address Book

Config Engine would be a more appropriate name than Listing Engine as the contract does more than listing assets and also as Config Engine uses a library Listing Engine, it could get quite confusing.

One thing to note is that renaming it might cause some breaking changes in aave-proposals.

with mumbai deprecated, the testnet contract addresses do not included one on amoy, that would be really helpful to have: https://docs.aave.com/developers/deployed-contracts/v3-testnet-addresses

Context

proposal 203

What to do?

The main change should be removing on the applicable networks the reference to controller of collector, as the interaction post-203 will be directly with the Collector (transfer, approve, createStream)

Context

When flattening with Foundry a payload like the one HERE, forge flatten contractPath generates a really big Solitidy flattened file, due to the number of interfaces' dependencies of address book, and it even contains clash of dependencies because of duplications.

This is pretty inconvenient because as we know, it is worth it even to use address book in production payloads in some cases. But with this problem of flattening, and consequently not being able to do Etherscan verification, it is not possible to introduce address book.

 Proposal

Needs some research. This would be solved if on flattening only the used interfaces dependencies (and I would say even better only the functions/structs used on those) would be included.

In #60 we realized the long executor was wrong on ts exports.
This is annoying as we manually maintain this file.

Would be good to extract from the solidity one or sth along these lines. No good idea yet.

Why

Currently, we have the RewardsController, but that is mainly useful for "end-users", for example claiming rewards.
In practice, the one to be most used programmatically for "admin" actions (e.g. changing emission config, or adding a emission admin, is the EmissionManager

Tracking issue for missing icons (assets that might soon be added to aave).
Non of this is super urgent, so just collecting here and once in a while we can have a pr to batch add them.

Missing icons:

• osETH
• stEUR
• sfrxETH
• ETHx
• wbETH
• BNBx

Currently, we define the the reserve treasury and the rewards controller in the generator script from the reserves data first token here which breaks when the reserve has no assets.

@miguelmtzinf noted that for avara it would be nice to have a GHO addresses directly accessible (not via assets library).

Putting them on Misc i was opposed, because:

1. it's a duplication of what we already have in assets
2. misc is used in almost every aave proposal and aave related ecosystem project. As solidity currently does not tree-shake interfaces / libraries at verification every addition bloats verification everywhere and creates noise on diffing.

That said, I think as a compromise - especially considering the growing importance of GHO - it could make sense to just create a seperate GHOMainnet, GHOArbitrum, ... and remove things like GHO, GSM, CCIP from Misc.

publish tokenlist.json and icons for address-book assets.

• IPoolV2 / IPoolV3
• IAggregatorProxy

ProxyFactory

• mainnet
• polygon
• avalanche
• optimism
• arbitrum

ProxyAdmin

• mainnet
• polygon
• avalanche
• optimism
• arbitrum

As we want to reuse them accross different projects would be good to have on address book.
Not sure if besides mainnet anything is deployed yet.

Add ecosystem reserve & controller to address book as suggested in #32

• AaveEcosystemReserve 0x25F2226B597E8F9514B3F68F00f494cF4f286491
• AaveEcosystemReserveController 0x3d569673dAa0575c936c7c67c4E6AedA69CC630C
• PolygonCollectorController 0xDB89487A449274478e984665b8692AfC67459deF

We already have the controller in the address book here https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveV2Ethereum.sol#L34 but we don't ship any interface for COLLECTOR_CONTROLLER - iirc the reason for that is that the interfaces accross pools are not consistent. Ethereum V2 supports streaming - afaik non of the others do.

There's two questions to answer:

1. Where to put AAVE_ECOSYSTEM_RESERVE?
   a) we could add it to the AaveV2Ethereum library. It doesn't really belong there though.
   b) we could add a new library especially for AaveEcosystemReserve containing the reserve and controller address
   c) ...

2. Should we expose the interfaces if yes which ones and where? Is there a chance we could align them throughout pools?

Similar to sol exports for assets which is generated here, its helpful to have assets exports for js as well.

https://github.com/bgd-labs/aave-address-book/blob/main/src/AaveMisc.sol

https://github.com/bgd-labs/aave-address-book/blob/main/scripts/generator_v2.ts

Similar to GHO addresses #482 for aggregators we just dump them in misc.
It might make sense to have a separate library for these sorts of things.

It can be a confusing developer experience when using a library that references different contracts as interfaces vs. addresses. For example, these are both contracts:

This could be a problem when importing a library to use within a contract to reference. For example, this compile would succeed:

import {AaveV3Ethereum} from "aave-address-book/AaveV3Ethereum.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable {
    constructor() Ownable(AaveV3Ethereum.ACL_ADMIN)
    ...
}

But this compile would fail:

import {AaveV3Ethereum} from "aave-address-book/AaveV3Ethereum.sol";
import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";

contract MyContract is Ownable {
    constructor() Ownable(AaveV3Ethereum.CONTROLLER)
    ...
}

My opinion is to have every contract referenced as an address and provide an additional library variable prepended with I to reference the same contract as an interface. It would add some bloat to the libraries but given they are auto-generated and lightweight I don't see it as an issue.

#112 (comment)

For potential contributors it's not clear if their pr has a chance of acceptance or not as we don't have super clear rules.
I think as a minimum requirement we should have verified contracts, but probably it makes sense to also limit to trusted entities as the deployers of these contracts as the upgradability might be a possible attack vector.