bgd-labs / aave-address-book Goto Github PK
View Code? Open in Web Editor NEWSolidity registry for all smart contracts' addresses of the Aave ecosystem
Home Page: https://search.onaave.com
License: MIT License
Solidity registry for all smart contracts' addresses of the Aave ecosystem
Home Page: https://search.onaave.com
License: MIT License
Should be a secret.
The Aave Address Book is currently missing these 2 addresses which are used in quite a few Proposal Payloads.
0xd784927Ff2f95ba542BfC824c8a8a98F3495f6b5
Would be nice to have them added as well to reduce errors related to Aave addresses.
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.
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).
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)
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
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)
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.
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.
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:
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.
Add ecosystem reserve & controller to address book as suggested in #32
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:
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) ...
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.
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:
aave-address-book/src/AaveV3Ethereum.sol
Lines 37 to 41 in f73f77c
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.