Hello, StarkNet (and Aave) community members!
Even if relatively silent, in parallel with the Starknet’s and Aave’s ecosystems progressing day by day, the Phase I of Aave <> Starknet has done the same, and now it’s time for an update on how things are going.
To summarize, the project has entered its final phase, with the code in a finished state and ongoing audits, targeting a release during this month of June.
You can see the codebase and specification of the system on the official repository HERE
The timeline at the beginning of the project (1st march) was defined as the following.
Currently, we just crossed the 3 months mark, but we are in the final weeks for audits and final review/delivery, still within the margin (< 1.5 months or > 1.5 months) scoped.
Since the last update, there have been numerous changes and progress, in both architecture and implementation. The most important being:
Fossil → Starknet messaging bridge. When designing the system, our idea was to try to have the most optimal way of communicating between Ethereum and Starknet, and reached the point of being convinced that a system using Fossil and storage proofs was the best option. At the same time, we understand that Starknet is a young and rapidly evolving animal, so what looks theoretically the best idea, maybe is not in practice (yet). So finally we have decided to release Phase I not using Fossil and storage proofs, but going with a more “classic” approach based on message bridging. Updates from Ethereum on Starknet will happen automatically every time somebody deposits/withdraws on Ethereum, coexisting with a permissionless mechanism for anybody to trigger an update even if those actions don’t happen.
The decision was relatively complex, motivated by the uncertainty of how the higher cost of storage proof operations could affect our system, consequently affecting the optimality of using it from day 0.
That being said, together with the messaging solution, the repository of Phase I will contain a 90% ready integration of Fossil, and the idea is to swap the system to use it whenever we feel it is worth it. We know that there is incredible work of cost reduction for storage proofs happening on Starknet, so it is highly probable that this will happen in the following 2-3 months.
No Ethereum static aTokens; Hail to the Aave <> Starknet Bridge. Initially, we were thinking about re-using the existing static aTokens of Aave Ethereum (wrapped aTokens not increasing in balance but in value) as an extra layer of composability, to be deposited into a relatively simple bridge.
We realized that this strategy would cause gas cost overhead on Ethereum, and in the end, the bridge smart contract would still need some quite specific logic. So we decided to implement a Bridge contract that already includes wrapping capabilities, making the system a bit simpler, both for us and liquidity providers integrating in the future.
It is important to highlight to static aTokens are still used, but on the Starknet side.
Modular architecture on Starknet. Given our intention (of anybody else in the community) to improve and expand the system in the future, the Starknet side is quite agnostic in what regards updates from Ethereum: they can happen via messaging bridging, storage proofs, or any other mechanism, just by building adapters on top.
The system is also agnostic to the origin network, making doable any kind of Aave on chain X <> Starknet instance (maybe you guess where we are going ).
As previously commented, right now we are in the security review phase and we can disclose that the parties involved in the process are:
- Nethermind. Auditing the Starknet side of the system.
- Certora. Writing Certora rules for property checking of the Ethereum side of the system.
- Peckshield. Auditing the Ethereum side of the system.
- As for the payments schedule of the project, we will be creating the on-chain proposal on the Aave governance to release 92’500 USDC to cover project’s expenses. As this is an already approved project by the community, there will be no Snapshot step.
- We will be doing any fixes/optimizations that could appear during the security review phase.
- Build any appropriate library for integrators to have a good experience with the system (on both the Ethereum and Cairo sides).
Last but not least, we didn’t forget that Phase 1 needs Phase 2. There will be more details pretty soon, but be prepared, the full Aave v3 (or not only 3? ) is coming to Starknet.