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

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

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.

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.

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

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?

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.

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

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.

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).

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)

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

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

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.

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

#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.

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

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.

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

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

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.