Hello, Aave community .
Vote here Snapshot
This is our proposal to begin phase 2 of Aave integration on Starknet. We summarize the details of phase 1, and go over an overview of Starknet today. We are here to answer any questions the community has before beginning the official vote for the temperature check of Aave V3 deployment on Starknet, following the BGD framework for new network deployments.
Aave on Starknet, present and future
The Aave integration with Starknet has originally been planned in two phases. Phase 1 was aimed to be a limited effort to introduce Starknet to the Aave community. The scope of phase 1 was building a bridge for aTokens between Ethereum to Starknet.
Following the successful completion of phase 1, we are now ready to propose a temperature check for the implementation of phase 2: the full deployment of the Aave protocol on Starknet. (You can read more about phase 1 in this post).
The Aave community has previously voted with an overwhelming majority in favour of phase 1, and we hope to get similar support to continue developing Aave on Starknet.
I am submitting this proposal on behalf of the Starkware and the Starknet community, to get a temperature check for the full deployment of the Aave V3 protocol on Starknet, following a positive signal.
New Chain, New Opportunities
Starknet has been live for just over a year and already sees an astounding rate of new developers and projects building on it. This rate is only expected to rise with the upcoming upgrades to Starknet. There are a few major milestones planned for the near future of Starknet that will bring more scale, cheaper transactions, and a much better development experience.
Being a new validity rollup, Starknet supports features that can directly benefit Aave suppliers and borrowers. Starknet natively supports Account Abstraction, allowing wallets to improve the user experience. By deploying on Starknet, the Aave ecosystem immediately benefits from the advanced features afforded by the broader Starknet ecosystem.
Starknet has additional benefits, such as efficient liquidity provision. This is a result of Starknet being a validity rollup, where proofs of the entire state of Starknet are validated on Ethereum several times per day. Once a validity proof is verified, all state changes on Starknet and all messages passed between Starknet and Ethereum are valid and final. Starknet users can thus quickly and securely move funds between Starknet and Ethereum, without the need for a long waiting period, and without losing out on slippage to bridges and liquidity providers.
Bridging through alternative portals is of course, also an option if even faster bridging is required. The easiest way is to bridge through StarkGate, which integrates both the native Ethereum<>Starknet bridge, fiat on/off ramps such as LayerSwap and Ramp as well as cross-chain bridging with providers such as Orbiter.finance.
The Starknet Ecosystem is growing
Starknet is quickly integrating with the broader Ethereum ecosystem. Maker has implemented a DAI bridge from Ethereum to Starknet and are currently working on a full implementation of their protocol on Starknet. Nethermind is working with ENS and starknet.id to support interoperability. Chainlink have recently announced they will be deploying to Starknet. Chainlink contracts are already live on Starknet goerli testnet.
Many reputable and well-known wallets have already integrated with Starknet and are leveraging the advantages of Account Abstraction, such as multiple signers, seamless hardware signing from mobile phones, and more. These include Argent, Braavos, Ledger, and more wallets are on their way.
Other bridging options and Dapps are available on the Starknet portal.
Starknet is scaling
Starknet is on a mission to scale beyond what is currently possible on Ethereum or any other Rollup. There are several efforts currently underway to make Starknet handle more demand and become cheaper to use: LambdaClass is reimplementing the Cario virtual machine in Rust, The Starknet sequencer is being reimplemented in Rust, and proving is made better by utilizing recursive proofs. As a result, transactions on Starknet, which are already 10x cheaper than Ethereum, are expected to get even cheaper and faster. Computation-intensive transactions can be as much as 1000x cheaper on Starknet, and there are plans to improve L1 data costs by integrating support for various Data Availability solutions and support for EIP-4844.
A comparison of transaction fees on Ethereum vs Starknet can be seen on Voyager.
With current and upcoming improvements, all Aave operations can get significantly cheaper on Starknet. This means trades, liquidations, and oracles can be cheaper, resulting in more capital efficiency.
Cairo 1.0 - New developer experience
Cairo 1.0 the new next step in the evolution of the Cairo language. It is a new compiler being built for Starknet. It will introduce a more friendly language, with many similarities to Rust. Cairo 1.0 smart contracts will be supported in the next Starknet upgrade. Development of phase 2 will be done in Cairo 1.0 from the get-go, thereby making the Aave protocol on Starknet fully compatible with Sierra and future Starknet versions. Cairo 1.0 is the next step in the evolution of smart contract languages. More developer friendly, safer, and faster.
Unlike many of the chains where the Aave protocol is already live and thriving, Starknet is not EVM compatible and will thus require a rewrite of the Aave V3 protocol to Cairo 1.0. For this rewrite, we intend to ask for a $200,000 grant from the Aave community for development and audit expenses, if this proposal is accepted, and following the network evaluation by BGD, Gauntlet, and Chaos Labs.
The total costs of the entire project are significantly higher, and the remaining costs will be covered by Starkware.
The proposal for funding phase 1 of the project passed with >340K positive votes. Phase 2 introduces new challenges and opportunities to scale Aave to new chains committed to scaling the Ethereum ecosystem. We are working closely with the BGD team to adhere to the newly proposed framework for assessing new networks and are ready to answer any questions before submitting the temperature check vote to Snapshot.
Outline of next steps:
Discussion and feedback from the community (this post)
Temperature check vote on Snapshot
Review of the network by service providers by BGD, Gauntlet, and Chaos Labs
If positive feedback, an additional vote to approve the start of development and grant