it has happened multiple times in the past that ppl accidentally create wrong deploy scripts e.g. bgd-labs/aave-proposals#81 (comment) - we usually catch the errors, but a few times it was close.

Wondering if we could improve the helper to check if the referenced address hasCode on the specific chain.
Not sure if so easy, as this would mean the deploy script would factually need to be multichain.

solidity is not the best tool for formatting strings and manipulating complex structures
The current form of the reports is not easy to digest as numbers are rays etc. also sometimes you might not be interested in some fields for your specific report.

In the one case where we used the snapshot on an aip we manually formatted it a lot and eventually even let an error slip in: https://github.com/aave/aip/pull/267/files

Therefore i'm wondering if it wouldn't be more rational to not generate the markdown in solidity, but just generate a json and have a seperate more sophisticated cli tool for formatting.

The solidity script would just write a:

{
 reserves: [{symbol: 'DAI', aToken: ...}]
 interestRateStrategies: []
 eModes: []
}

json file and the user/tool could decide on how to represent the values.

Hello! I am trying to run the test suite and I think I did everything in the README but I'm still getting 15 tests failing with the same error.
[FAIL. Reason: backend: failed while inspecting: Database error: failed to get account for 0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326: (code: -32603, message: failed to forward request, data: None)] testListingsCustom() (gas: 0)

I did install aave-cli and copy the .env and also forge and yarn is installed correctly. Is there anything I am missing?

Thank you!

createProposal currently assumes to target SHORT_EXECUTOR - which is correct in 99% of cases.
We should add an overload which allows specifying the executor so it covers 100%

Even if no new listings will happen in instances of v2, it is useful to have an equivalent contract to this one https://github.com/bgd-labs/aave-helpers/blob/feat/draft-engine-0.2/src/v3-config-engine/V3RateStrategyFactory.sol, but for Aave v2.

Things to take into account:

• The default interest rate strategy on v2 is slightly different that v3's https://github.com/aave/protocol-v2/blob/master/contracts/protocol/lendingpool/DefaultReserveInterestRateStrategy.sol
• When initializing() the factory with "live" rate strategies, verify well that none has custom logic (it is possible there are some). If there is any with custom logic, don't list it in the factory.
• No need for config engine support to start with, but include an example payload (probably a base payload exposing a simple interface) to use the factory

Using ffi we can run forge inspect contractPath:contractName storageLayout and validate on the defaultTest(), that no storage variable has been added on the payload contract, this is critically dangerous as it would mess with the Executor state otherwise - as the payload is called via delegatecall.

ReserveInterestRateStrategy contracts based on IReserveInterestRateStrategy will not work with the current ListingEngine, because will try to fetch data from functions that are part of IDefaultInterestRateStrategy.

forge verify-contract
0x27efe5db315b71753b2a38ed3d5dd7e9362ba93f
--chain-id 137
DefaultReserveInterestRateStrategy
--constructor-args $(cast abi-encode "constructor(address,uint256,uint256,uint256,uint256,uint256,uint256,uint256,uint256,uint256)"
"0xa97684ead0e402dC232d5A977953DF7ECBaB3CDb"
"00000000000000000000000000000000000000000295be96e640669720000000"
"000000000000000000000000000000000000000000084595161401484a000000"
"0000000000000000000000000000000000000000001f6ed020b26b45e6000000"
"00000000000000000000000000000000000000000295be96e640669720000000"
"0000000000000000000000000000000000000000002116545850052128000000"
"00000000000000000000000000000000000000000295be96e640669720000000"
"00000000000000000000000000000000000000000018d0bf423c03d8de000000"
"000000000000000000000000000000000000000000295be96e64066972000000"
"000000000000000000000000000000000000000000a56fa5b99019a5c8000000")
--watch
--etherscan-api-key

We've been working on some improvements to the e2e testing to ensure more code is covered and things are tested beyond just execution with sanity checks on various values. We will continue to improve this, but wondering if there is any interest in including this upstream.

Here are 3 PRs we've merged and can open a PR here if desired:

https://github.com/marsfoundation/aave-helpers/pull/10/files
https://github.com/marsfoundation/aave-helpers/pull/11/files
https://github.com/marsfoundation/aave-helpers/pull/12/files

Allow passing arc proposals via governance helper

When all parameters are KEEP_CURRENT, there is no need to 1) get the current collateral values and 2) call configureReserveAsCollateral.
Currently and even if it doesn't hurt, it only creates useless updates with exactly the same values, extra read gas, and overhead of events.

• current oracle price
• implementations of important contracts (e.g. pool, pool configurator etc)
• permissions for important contracts (pool etc) - i guess in the end sth close to https://github.com/bgd-labs/aave-permissions-list/blob/master/out/MAINNET-V3.md#contracts @sendra

getProposalsCount and similar are useful sometimes, but missing in the interface

While there is a end-to-end test suite included in the helpers, it's not quite reasonable.
Essentially we ported what we had on various v2 tests to v3, not considering how v3 changed.

The current test suite tries to:

1. supply all assets, 100 each
2. try to deposit 1M whatever and hope it's enough to variable borrow 10 of everything
3. same as 2) but with stable borrows

At this time the tests are barely working on any networks, as supply/borrow caps and and even ceilings can prevent these tasks from being performed.

In addition to that there are currently various issues that might make sense for us to look into on foundry side:

• Optimism sUSD cannot be dealt - this makes e2e on optimism impossible right now
• deal does not work with aTokens - we don't currently need it, but might make sense to look into as we have some expertise & might make some things easier for us

I think it makes sense to think about how a reasonable e2e flow could look like and which properties we actually want to test & how to test them.