Hello @gf042 . We have been working last weeks improving as much as possible the assurances for the creation of a new activation proposal.
We publish here more precise information very soon, but yes, a re-activation is expected.
2 Likes
We would like to communicate to the community that the proposal for the re-activation of Aave v3 ZKSync is ready to be created.
During the time since the previous activation attempt when an LLVM issue was found (described in detail HERE), we have opted for the side of caution and applied the following extra procedures:
- First, just after the detection of the problem, we discussed internally if the ZKSync network was still suitable for Aave. The answer was YES, due to the nature of the problem: a very specific/edge issue on not even ZKSync “native” infrastructure, affecting exclusively Aave in also very specific logic, and on exactly the compiler version we used.
Even if this is not ideal, we understand that compilers (e.g. solc itself) can have bugs, but it is possible to minimise their impact with both extra types of tests and security procedures, like the ones that allowed Aave to not be impacted in production.
We discussed this with both @Certora, security provider of the DAO and the Matter Labs team, and looks like a reasonable/acceptable conclusion. - We have added extra tests on the Aave codebase, both to further detect similar issues as the one detected prior to activation, and others of similar nature. Even if generalise detection of this type of problems can be very complicated/impossible, we are confident that right now the test suite is solid in that regard.
- We updated the compiler version to
1.5.3, and properly verified the same issue doesn’t manifest with it. - Last but not least, the proposal will introduce an extra layer of protection, procedure-wise:
- The supply and borrow caps configured to start with will be very small (~$10’000 value each asset), to perform extra testing in fully production environment just after proposal execution.
- Once that extra testing is concluded (matter of hours or 1 day), as technical service provider we will communicate here on the forum that everything looks OK.
- Just after, the Aave protocol Guardian will be able to raise the caps to the levels pre-authorised on the governance proposal, and the pool will be fully operational.
As usual, we will notify here on the forum when the governance proposal is created.
5 Likes
We have created the Aave governance proposal for the DAO to re-activate Aave v3 ZKSync.
Voting will start in approximately 24 hours, participate 
4 Likes
Proposal 166 activating Aave v3 ZKSync has been executed, but as previously disclosed, with low supply and borrow caps to be able to further test and monitoring everything working correctly.
Currently, tests post-activation seem to indicate that all systems are working correctly, but the plan is to continue observing the pool during the weekend, and if everything looks functional, authorise the Aave Guardian to raise caps on Monday 23th. This will mark in practise the release of Aave v3 ZKSync.
In the meantime, the pool is already available on for example the Aave Labs user interface, and given that caps protections are in place, there is no problem for users to try it out even if with small amounts.
5 Likes
Am I right in understanding that it is better to be active and contribute and borrow as many assets as possible to help testing?
1 Like
Correct @gf042 , there is no problem to use the pool and it actually helps us by having real activity.
1 Like
Good news. At what time on Monday is it planned to raise the caps?
Are there any problems with the testing? Some assets have already hit or are close to hitting the cap
Following the timeline, and as pre-approved by the Aave governance, the Aave Protocol Guardian has raised the caps to the levels previously recommended by the risk provider (@ChaosLabs) of the community.
We confirm now that Aave v3 ZKSync is fully active and operational.
4 Likes
that’s great! thanks bgdlabs team :)
2 Likes
Hi all, I don’t know if this is the right place for this post, I would like to know why such small limits on zk and wstETH are set. As you can see we have already hit these limits and cannot supply any more liquidity