Request for Approval. Aave <> Starkware Phase I

[eboado]

Background

The discussion about Aave on Starknet here.

Introduction

A proposal to start bootstrapping the Aave ecosystem over Starkware has received good support from the Aave community, as it allows to expand to a new and promising environment, following the lead of Aave v3 with rollups.

This bootstrapping was proposed to be executed in 2 phases: an initial one getting in touch with the new technology, while still building something valuable for the Aave and Starknet communities; and a second one, more ambitious, most probably porting Aave v3 to Starknet.

As the facilitator of the project, I outline on this document the details of Phase I, including scope, time estimation, team members and budget allocation request from the Aave DAO.

Phase I. Scope

The project. aTokens bridge

As explained on the initial post, the target of the initial Phase is simplicity, while adding value for the communities.

One of the options was to create some kind of pooling model, for people to deposit and withdraw from Aave Ethereum without ever touching Ethereum and its (current) high gas cost. Since that initial proposal, the idea has been refined together with the built team.

Phase I will pursue the same goals as the original pooling idea, but this will be done by building wrappers and smart contracts around the canonical Starknet bridges, for the aTokens of Aave Ethereum. Following similar idea as pioneered by Aavegotchi with maTokens, together with some extra bridging infrastructure on both the Ethereum and Starknet sides, this model will allow to:

• Build the basic blocks for products to integrate easily with Aave from Starknet. Including smart contracts and interaction libraries.
• Solve some interesting and useful challenges, like cross-chain liquidity mining.
• Boost Starknet’s user base, by providing Aave facilities.
• Keep simplicity.

In terms of user flow, the system will provide smart contracts infrastructure to:

• Users entering on Starknet via CEXes or on-ramp services to deposit on Aave Ethereum, just by buying an aToken equivalent on Starknet.
• Same for withdrawals, by selling the aToken equivalent on Starknet.
• New opportunities to liquidity providers to build on top of that, potentially monetising the movement of liquidity between Ethereum and Starknet.

Timeline

The project is estimated to take a total of 2 to 3 months, with the variability depending on the implementation of the most experimental aspects, like the cross-chain liquidity mining.

As part of the facilitator role, I will post bi-weekly updates on the state of the project, informing the community on the progress on all aspects.

A more detailed timeline is the following:

The project start will be marked by the execution of the on-chain proposal requesting the initial funds of the project.

Team

Since the initial proposal, multiple teams showed interest on participating on the project. Considering the final scope, the team will be formed by:

• 1 facilitator of the project, part-time.
• 1 frontend/backend developer, part-time.
• 3 Cairo/Solidity developers, full-time.
• 1 Solidity developer part-time (depending on availability and need).
• Total: 3 full time and 2-3 part time.

The team is balanced to have expertise on the Aave ecosystem and Starknet.

Budget breakdown

• Salaries. Covering the full scope of the project, estimated for 3 months and to not be modified unless the final timeline is too short (>1.5 month less) or too long (>1.5 month long).
• Gas cost. For deployments of contracts, plus all managerial efforts concerning mainly the payments from the Aave DAO.
• Audit. We plan to engage 2 audit firms, both with EVM/Solidity expertise and at least one with Starknet/Cairo experience.
• Bug bounty. Maximum to be spent, but most probably over-estimated if no important issues are found.
• Buffer. 10% of the total budget.

Payments

For the Starkware part, the payments will be managed as coordinated between the Starknet team, the facilitator and the team members.

For the Aave part, 2 payments are proposed, to be requested via proposals on the Aave governance:

• At the start of the project, 100’000$ to cover mainly fixed expenses.
• Before starting audits (beginning Month 3), $92’500.

Any reconciliation of budget (e.g. return unused funds) will be done at the end of the project, with the bug bounty being kept by the team during 1 year, and then returned to the governance if not used.

Given the nature of the development, the payment will be done on stable assets from the Aave treasury.

Deliverables

• Smart contracts (Ethereum/Starknet) for wrapping and bridging of aTokens, fully open source and with a permissive license like MIT.
• Full documentation of the codebase, architecture and model in general.
• Public audits.
• Continuous update to the community about the project.

Next steps

• Create a Snapshot proposal to ratify the project.
• If passed, create on-chain proposal to request the initial funds.
• Start the project development.

[Donzo]

Looks really good.
Excited to see this come to life.

[EzR3aL]

Nice to see such a detailed project-planning. Keep it this way. Only concern i do have is regarding the security of the bridge. Just yesterday we saw again what can happen if a bridge gets hacked/bug-abused. And i don’t talkt about the lost ETH but about the consequences that are tied to that. Just imagine how many loans cannot be paid back or collaterals that aren’t there anymore. (Yes i know, Wornhole said they will fill up the ETH so the backing will be again 1:1, but this isn’t always the case. Not everyone has a bunch of VCs able to cover them).

So what i wanted to say is that i would love to see the audit regarding this bridge, just to be as sure as possible that all vulnerability have been found.

[fig]

@eboado really excited about this integration will be a competitive advantage if done correctly.

I will emphasize @EzR3aL’s concern above:

@EzR3aL

Just yesterday we saw again what can happen if a bridge gets hacked/bug-abused. And i don’t talkt about the lost ETH but about the consequences that are tied to that.

While I am excited about the partnership between Aave and Starkware, security and testing must be a priority. Is it possible to include this integration in V3 so it is included in new audits?

How are other ways we can test and protect against the vulnerabilities of this bridge?

[eboado]

Yes, pretty important point.
In the case of Starknet, cross-chain message bridging (the basic mechanism of what we consider a bridge, for tokens or not) is what can be considered part of the base layer of the network. This by itself gives I would say more security assurances, as it is developed in a holistic way with the rest of the infrastructure, by the Starkware team. (Correct me if wrong @Yael-StarkWare )
That being said, obviously doesn’t mean that the bridge couldn’t have a vulnerability, as that can never be predicted. But apart from the first-class security procedures following by Starkware on development, there are some aspects that give good assurances:

• Starknet is newer technology, but pretty similar to StarkEx, which already includes “bridging” components. For what I’m aware, applications like DyDx on StarkEx, never had any problem in what concerns the bridge of assets.
• The Phase I team has members from the Nethermind team with probably one of the highest expertise about Starknet and its connection with Ethereum, having working on a Solidity-to-Cairo transpiler. So even if not part of the scope of this project, it is a fact that the team will analyse in detail the base bridging facilities.
• Phase I is a bootstrap project, as I commented not fully focused on growth of the Aave protocol, but more on providing the right smart contracts infrastructure for that to happen in the near future. Consequently, we will see during the implementation phase, but it is quite probable that liquidity limits will be set at the beginning, increasing/removing them progressively once the maturity of the ecosystem is market proven.

[Yael-StarkWare]

You can read more about StarkNet bridge (built by StarkWare) here and see the code here.
It is currently available on testnet, you can try it here.
And obviously, the code of the bridge will be audited thoroughly by the best experts before going to production.

[liva]

alright lets do it, cant see why not

[EzR3aL]

Could you tell me why? Just curious @liva

[eboado]

To update on the status of the proposal, as you probably saw, there has been pretty good results on the Snapshot vote (217k YES vs almost 0 NO).
Now, the on-chain proposal has been submitted by me, the facilitator, and it is open to vote here.

To summarise, the proposal releases the first scheduled payment on the Aave DAO side, of 90’000 USDC and 3 WETH, amounting close to 100’000 USD. In order to enable this, the proposal also updates the smart contract implementation of the protocol’s treasury, enabling it to release any kind of token when the governance requires it.
Further information about the technicalities can be found on the repository containing the proposal’s payload implementation here.

[eboado]

Aave <> Starknet Phase I. Project update 1 (25/03/2022)

Hello, Aave (and Starknet) community members! As you know, an Aave governance proposal was passed on the last 26th of February, serving as final approval for the first phase for the integration between Aave’s and Starknet’s ecosystems.

The initial details regarding the proposal at the beginning of this thread.

Since then, the team participating has been working on the project continuously and I will try to summarise in the following section what exactly was happening.

What was being done?

Prior to starting the project, a rough timeline was presented as the following:

@eboado

Currently, we finished the 3rd week of the project, as it factually started on the 1st of March, and the timeline still holds.

During these first 3 weeks, we have been mainly allocating time to the Definition phase, mainly brainstorming and architecture around the idea of what we need to allow users on Starknet to deposit on Aave on Ethereum in a seamless and cost-efficient way.

To achieve that, we needed to dig a bit deeper into the concept of staticATokens, the equivalent of Ethereum aTokens, but increasing in value and not in balance. These are a starting point for almost any cross-chain liquidity development that requires the minimization of “active” communication between chains, as by its nature, a holder of those tokens (both on Ethereum or after bridging somewhere else) will be passively accumulating yield from Aave on Ethereum.

From that base, we confirmed certain aspects and took some decisions:

• The Starknet ecosystem is growing at an exaggerated rhythm (that is good), with tons of projects continuously developing cool solutions for any type of need. We will be naturally using some of them, and specifically, we have decided to leverage:

  • Fossil by Oiler Network. Infrastructure layer for cross-chain communication based on storage proofs. We will be using it for the majority of our cross-chain accounting needs regarding the staticATokens, more precisely the accruing of stkAAVE liquidity mining rewards on Aave v2 Ethereum. We appreciate that the team behind Fossil has been really helpful in giving us access to their beta product.

    Given the particularities of the Starknet computation system, some challenges are appearing due to our needs in terms of storage proofs, but at the moment, they seem fully solvable. And improvements/optimizations unveil almost every day on Starknet, which helps with experimental ideas like this.

  • Starkgate by the Starkware team. Also cross-chain infrastructure layer, this time for cross-chain generic messaging from Ethereum contracts to Starknet’s. The main use case is the bridging of assets, but we have extended it to be generic.

• As more or less we expected from our pre-project analysis, the most complex part is the bridging of liquidity mining reward from Aave v2 Ethereum. During these past weeks, we evaluated different options, with mainly 2 final candidates: to include somehow the value of the stkAAVE rewards on the value of the staticATokens bridged to Starknet, or to keep the rewards accruing on L2 for staticAToken holders, but separated, as a different “token”.

  We finally decided to go with option 2, keeping the rewards separated, which can be summarised as:

  • A user bridges 100 staticADAI to Starknet.
  • By holding that 100 staticADAI on Starknet, he passively accrues the yield of Aave v2 Ethereum.
  • In parallel, while he/she holds the staticADAI on L2, is accruing another token on Starknet, temporarily named rewAAVE, which is 1:1 equivalent to AAVE of Ethereum L1.
  • The infrastructure needed on this model will be pretty minimal because no AAVE needs to actually be bridged to Starknet, as the conversion rewAAVE to AAVE will happen whenever somebody wants to bridge back the rewards to Ethereum. If we assume that in the future the utilities of AAVE will be present in multiple networks too (being able to vote on Starknet, stake on the Safety Module, etc), it is highly possible that people will not really bridge too much back and forth AAVE.

Apart from brainstorming and defining the details of the project, both Solidity, and Cairo of almost all the part has been progressing, theoretically being a bit anticipated on the planning, especially on the Cairo side.

Given the parallel progress happening on the Cairo language and standard libraries development, we expect to have a pretty seamless implementation process in regards to tooling on the Starknet side.

Audits

We did also some work contacting auditors of the ecosystem and we already reserved with 3 external security firms, considering the Ethereum and Cairo sides.

What’s next?

During the next weeks, the effort will be focused on the implementation side of things, both Ethereum and Cairo, targeting having an initial mature end-to-end implementation in around 3 weeks’ time.

By the way, everybody can follow the progress on Github account dedicated to this joint project here

[Zer0dot]

Awesome stuff! This is really exciting because it allows access to the same liquidity from L2, which is something we haven’t really seen (bar as mentioned, simple bridge implementations like amTokens from Aavegotchi).

I’ve got one question with regards to liquidity mining rewards though- as stated, rewards will accrue as “rewAAVE” and will be 1:1 redeemable against L1 AAVE tokens. I like this model, but what happens if an L1 user deposits afterwards, diluting the yield?

Take for instance this example:

• Assume 100 AAVE/period of LM rewards for DAI and an empty pool
• User A deposits 900 DAI on L1 at time 1
• User B deposits 100 DAI on L2 at time 1
• User A accrues 90 AAVE and user B accrues 10 rewAAVE
• User C deposits 1000 DAI on L1 at time 2
• User A accrues 45 AAVE, user C accrues 50 AAVE, user B should accrue 5 rewAAVE, but the L2 state has not been updated, so user B still accrues 10 rewAAVE

How is this case accounted for? Or are the rewards separated on a per-network basis?

Other than that, really happy to see this is going so smoothly. This close to dig into Cairo!

[Jorik]

Thanks @Zer0dot! That’s a good question but luckily we don’t run into this problem.

Side note: the dilution problem is avoided for users of L1 by keeping an index or a per-token amount of accrued asset which is updated before mints, transfers, and burns as implemented by both (DistributionManager + aTokens) and staticATokens. This index is also memoed per user when they interact with the implementation so that their pending rewards can be computed with respect to the current index.

We don’t actually configure the emission rate on L2. The memoed index of the bridge as a user of the staticATokens is forward periodically to L2 instead. These reward updates are distributed amongst users on L2 using the exact same logic as the implementations mentioned prior. In this way we never create rewards on L2 which were not already accounted for on L1.

That said there is a strange form of time dilation between L1 and L2. No rewards will be created or lost compared to L1 however users who swap staticATokens on L2 between updates of the index will lose (the sender) and gain (the receiver) the rewards accrued within that update. This also occurs in the staticATokens implementation on L1 right now because transfer doesn’t update the index. Therefore the L2 bridge will ‘dilate’ as much as the L1 statiticAToken with the perception of time on L2 offset by the messaging delay from L1 → L2.

[Jorik]

Does anyone have any good alternative name suggestions for rewAAVE?

[pakim249]

I think the name should be as short as possible. Therefore we should call it rAAVE… ;)

[eboado]

I remember that at some point the r + Asset was used for the assets with built-in interest redirection. Maybe the “r” only is even too generic.

[Zer0dot]

Oookay I get it now. So it’s not really a continuous accrual of rewAAVE (better name pending), but a periodic accrual in accordance with the index updates that are pushed to L2 yeah? So due to the async nature of it, you’d push an index of some time in the past from L1 to L2, which would determine the earned rewards between that time and the last update right?

[eboado]

Hello, Aave (and Starknet) 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

What was being done since the last update?

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 ).

Security procedures

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.

Next steps

• As for the payments schedule of the project, we will be creating the on-chain proposal 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.

[eboado]

Following the payment schedule defined at the beginning of the project, when it was approved

@eboado

Before starting audits (beginning Month 3), $92’500.

A proposal has been created on the Aave governance to release the 92’500 USDC on
https://app.aave.com/governance/proposal/?proposalId=85

P.S. The audits of the project are almost finished, so Phase 1 delivery to the community will happen on the following weeks.

[soanky]

Great work! Can’t wait to see this in action! Starknet is my favourite

[eboado]

Given that update this time is lengthy, the post about the release of the project has been created in a new thread on Aave <> StarkNet Phase I. Release