Testnet maintainance

[sakulstra]

Currently testnets are a mess.

All the testnets deployed by avara are outdated.
The ones not outdated and listed on https://aave.com/docs/resources/addresses were deployed by bgd, but funny enough don't have a permissionless faucet, so for most ppl they are useless as well.

Not 100% sure how to resolve this situation right now.
People are asking for an amoy testnet, but again it's unclear who will maintain this long term.

Deploying with permissionless&limitless faucet doesn't make to much sense, as of lately it only takes a few days till people break the pool. For BGD there is little incentive to maintain these things, as all our testing is done on mainnet forks instead.

---

The options I see are:

1. maintain some infra for a permissioned faucet. Takes some effort and not sure if worth it.
2. create testnets only with tokens that already have a permissioned faucet (e.g. LINK and USDC as on almost every testnet). Is probably pain for users and maintainers of interfaces because they need to go/link to different pages for different faucets.
3. create a new permissionless, but somehow limited faucet (limited minting over time, limited via amount or limiting by charging some amount in testnet base currency)

[brotherlymite]

Currently the assets listed on the testnet faucet are from the base faucet: https://faucet.circle.com/
The limitation is that we have no control over it if we wish to mint some more tokens in order to test some flows, and also number of assets on the faucets are limited.

In my opinion, we should put some effort on the aave-v3-origin repo to have a flag in the config while deploying on testnets, which will list all the assets linked to a permission-less faucet with some sort of access control which can be used to mint more tokens.

The permission-less faucet for the tokens could be capped via block.timestamp and maybe some other mechanism too so users cannot abuse it, while also having some permissioned access control mechanism which can allow multiple other contributors of the DAO to mint some extra tokens so they can tests things smoothly.

Before each pool upgrade, we can schedule an update on testnets also using the same upgrade proposal which can be useful in validating the upgrade. Maintaining testnets for all networks could be a bit of pain, so we can have some selected 2-3 networks which we can maintain in the long run. The deprecated testnet addresses should then be removed from the address book to avoid confusions.

[yoheinishikubo]

First of all, thank you for developing and maintaining this library.

For the past three days, I’ve been developing a smart contract that supplies USDC to the AAVE V3 Protocol pool. I started development using Arbitrum Sepolia as the testnet, and within a few hours, I confirmed that supplying USDC worked without any issues.

However, earlier today, I encountered Error 51, which caused the transaction to fail. After some research, I learned that this error indicates the Supply Cap has been reached, and that it cannot be controlled by external developers.

I then switched to Base Sepolia for testing, but found that the USDC-related contract addresses referenced by this library differ from those used by Circle, and I couldn’t find any documentation on how to obtain those tokens. I also tried Ethereum Sepolia and encountered the same issue. It seems Arbitrum Sepolia just “happened” to use the same addresses as Circle.

It was at that point that I discovered this thread.

I understand that fundamentally resolving this issue may be difficult, but if there is currently a testnet where development and testing (without worrying about the Supply Cap) is possible, I would really appreciate it if you could share that information.

[defispartan]

@yoheinishikubo The majority of assets on Aave testnet markets are custom tokens that can be minted through protocol faucets

You can faucet these tokens by going to https://app.aave.com/ -> click gear icon in top right -> enable testnet mode -> go to faucet tab

[yoheinishikubo]

@defispartan Thank you. Could I ask if this is mentioned in documents? If so, sorry for consuming your time.