Deploy Aave v3 on Neon EVM Chain

Governance New Market
1

TL;DR
To support Aave’s multichain mission and expand cross-chain experiences, the Neon Foundation proposes the deployment of Aave V3 to Neon EVM. We would like to gauge the interest from the Aave community in deploying to Neon EVM devnet, and would greatly appreciate your feedback.

This post is only intended to be an introduction and community temperature check; we will submit a more detailed proposal for deployment at a later date.

  • Neon EVM is the EVM on Solana (currently on devnet), which enables Ethereum-based applications to have access to Solana’s scalability and liquidity without any changes to their codebase.
  • Neon EVM is a smart contract on Solana. Solana is a fast-growing blockchain (https://www.forbes.com/advisor/investing/cryptocurrency/what-is-blockchain/), Neon EVMs performance has been tested through multiple use cases, and the platform now includes the infrastructure and capabilities to support production level development. Notable Ethereum-based projects starting to build on Neon include Curve and Sobal (Balancer friendly fork).
  • Neon EVM has over 200 projects in its pipeline committed to launching shortly after the launch of mainnet, including blue-chip DeFi protocols, wallets, bridges, fiat on/off ramps, infrastructure, DAO tooling, etc. The focus in the early stages will be providing the infrastructure and technical dependencies needed for a breadth of use cases to expand from EVM chains to Solana.
  • Looking beyond mainnet, the plan is to develop interoperability with Solana smart contracts, full ecosystem compatibility, integration with additional major Ethereum tools and services, EVM support for Saga and an early grants program.
  • Deploying on Neon EVM will onboard new users & increase user activity on Aave by decreasing costs compared to Ethereum and enabling users to take advantage of Solana liquidity and access to the overall ecosystem

Resources
Documentation: Neon Docs

Audits:

Audience:

The Neon Foundation welcomes feedback from the community on the proposal, including suggestions on how it can be improved.

About Neon EVM
Neon EVM is an Ethereum Virtual Machine (EVM) built into a Solana smart contract, enabling Ethereum developers to build on Solana and access its native ecosystem without changing their codebases. Neon EVM facilitates the usage of Ethereum tooling by dApp developers to scale and access unaddressed liquidity on Solana. Developers can utilize the vast majority of Ethereum dev tools

Proposal
There’s significant value in Aave V3 being available on Neon EVM (EVM on Solana), which will enable Aave to access unaddressed users, TVL, community and ecosystem of Solana. Solana is a high throughput proof-of-stake blockchain with:

  • 0.4 second block times and 1-2 second confirmation times
  • $0.001 transaction fees
  • 3,000+ independent and globally distributed validators
  • 5,000+ total projects deployed and 900+ daily active programs
  • Close to 1.0 million active wallets per day over the last 30 days
  • More than 100 billion transactions processed since inception

Despite current market conditions and the FTX situation, Solana’s ecosystem demonstrates strong growth and resiliency. Continuous innovation is happening within the ecosystem and new projects / tools are rolling out on a continuous basis.
The Neon EVM ecosystem is already experiencing solid and fast growth: established projects like Curve, Sobal (fork of Balancer), Onomy, Powerpool have committed to launch along with over 100 more projects and infrastructure players like Pyth Network, The Graph, Covalent etc. We are also working on integration with Chainlink. For bridging, initially, we will be using Wormhole; nevertheless, since diversification is part of our core values, we would like to welcome the feedback from the Aave community on this matter.
The team plans to create programs to attract builders and fund their initiatives to accelerate the adoption of the network. Since we are big advocates of transparency and encourage it within our community / ecosystem, we would truly appreciate transparent feedback from the Aave community regarding the interest in deployment on devnet.

Conclusion
Neon EVM is the most awaited and anticipated innovation to the Solana ecosystem, and is positioned as a pioneer & at the forefront of making this a reality. The commitment to bringing together the best of both chains, security and the safety of users is absolutely paramount, and there have been no shortcuts in ensuring the utmost quality controls for this. Neon EVM has been audited by numerous prominent auditors such as: Hallborn, Ackee Blockchain, Neodyme

The Neon Foundation team believes that the Neon EVM solution will prove itself to be the most robust and reliable solution for a market like Aave, and as such is ready to onboard Aave to its ecosystem and looks forward to the opportunity to build a long-term, sustainable, and mutually beneficial relationship.

Truly appreciate your feedback,

Neon Foundation

9 Likes
2

I am firmly against this proposal

Centralization aside, Solana’s downtime is an abomination that regularly makes the chain unusable

Moreover, the TVL is low ($260M according to DefiLlama) compared to other AAVE-supported chains, which limits the market share the protocol can capture

Even if it is a simple proposal to deploy on the devnet, an integration on the mainnet does not make sense today & would be a waste of time/resources; Same applies to a devnet integration

I am however open to feedback, in case there are things I am not aware of

2 Likes
3

Hey @Tor_GAINS many thanks for expressing your concerns! I truly appreciate it and this makes discussion more healthy and transparent. We are really welcoming Aave community’s feedback and would love to get challenged by the community in order to remove every piece of doubt. I do understand your concerns and share them; however I would like to unpack points a bit here:

  1. Centralisation has been a heated topic and I am a decentralisation maxi myself. Nevertheless if we look at the Nakamoto Coefficient, it is around 31 - this means that 31 validators need to collude to censor the network and the coefficient has been improving.
  2. Downtime - agree on this point absolutely and majority of the ecosystem would support your claim. Solana Labs is also aware of the issue and fix is in the works: Solana Co-Founder Says 'Long-Term Fix' to Network Outages Is in the Works - Decrypt. In addition to that the frequent downtimes are the result of excessive duplicate transactions leading to congestion.
  3. Agreed, current TVL is pretty low; however at the height the TVL was around USD 10B. Of course, we should not exclude the case of Macalinao brothers and Serum (post FTX) that potentially contributed to illusional TVL. Nevertheless, TVL is a metric which is highly impacted by the movements within the market. If we are in the bull market, TVL would be proportionally higher on all the chains. Even given the recent circumstances, it doesn’t mean that Solana can’t reach that TVL. One should also take into consideration the vibrant NFT community of Solana, which might lead to potential users for other dApps within the ecosystem. So we can’t really judge from one side.

Also in addition if you look at the current distribution of Aave TVL amongst the other chains, the following picture is depicted: Ethereum- USD 2.92B, Arbitrum - USD 43M (Aave V3), Polygon - USD 252M, Avalanche - USD 308M, Optimism - USD 101M. The majority of Aave TVL is still on Ethereum and Polygon is not even 10%. In addition, the TVL of Aave on Arbitrum is completely statistically insignificant; however Arbitrum is one of the most amazing innovations / solutions within the space. Even though these numbers are low currently; I expect them to go up when the market changes its direction - especially during the heat of bull market with high gas fees on Ethereum (if you remember, the gas fees were around at times 400 - 500 USD per trx). In addition, since it is my 2nd bear market, I would like to state hat true builders endeavour to deploy / build during bear markets in order to be prepared for the bull market and to reap the gains. Deploying during the bull market might mean that there is already some lost potential.

If there is anything specific you would like to see from our side, please let me know and we would be more than happy to share it with you! We would like to be as transparent as possible and get as much feedback as possible to understand where we could improve :slight_smile:

2 Likes
4

If there is appears chance to grow more and more - why not! :D

5

Hi folks - we are trying a new format to evaluate proposals and would love to experiment below.

The goal is to simplify the Governance process, convey how we think about decision-making, and get more users involved.

For Deploying Aave v3 on Neon EVM Chain - our review:

Pros:

  • new users & demographics, expanding into the Solana ecosystem

  • v3 allows for more risk mitigation - and can build on top of existing EVM infrastructure

  • first mover and diversified validator set

  • indirectly introducing more diverse infrastructure providers; Pyth, Covalent, etc.

Cons:

  • very new, lack of understanding of EVM x Solana infrastructure

  • competing teams working on Zk-rollups for Solana (Eclipse)

  • will signal and invite other EVMs (Aurora)

  • greater trust in novel, high-risk bridges such as neonpass

  • technical roadmap will be presented in January

1 Like
6

Hey @fig,

Many thanks for your inputs! Really appreciate it.
In order to remove misunderstanding, would like to include following points:

  • Oracle infrastructure. Neon EVM provides reliable price oracles such as Chainlink and Pyth Network. We are currently in discussion with Chainlink to deploy on mainnet.
  • Block explorers. Neon EVM provides following Block Explorers
    • Neonscan: https://neonscan.org/ - The tool gives users a standard block explorer interface to search the Neon EVM for information such as block data, transactions, and addresses. The tool was created in partnership with the Solscan team, which spearheaded the development of the NeonScan UI and backend functionality. NeonScan gives developers and users in the Neon ecosystem access to easily digestible public data related to transactions, smart contracts, and accounts. This type of information allows users and developers on the Neon EVM to:
      • Understand whether a transaction was successful or functioned as intended
      • Understand how transactions interact with various accounts and programs (which is great for determining whether a dApp is safe/reliable).
      • Debug smart contract code.
      • Review token transfers and account balances.
      • Review transaction data and metadata.

Operations on the Neon EVM all have underlying impacts on the Solana blockchain. As such, all Neon transactions are made up of one or more Solana transactions. Due to this complexity, NeonScan’s data queries source information from two locations: the Neon EVM and the Solana network. Once data has been gathered, NeonScan stores the information on a database maintained by the NeonScan team. All the queried information is available on the NeonScan page and via a user-friendly API.

  • Compatibility with Ethereum RPC endpoints. Neon EVM supports almost all standards. Here is the link to supported JSON-RPC Methods According - Neon Docs

  • Disclosure of any non-EVM/Ethereum extra/different feature of the network. Generally speaking, the features of the network are similar to that of Ethereum. However there are several minor deviations:

    • Gas calculation method: Neon EVM gas fees reflects Solana gas fee model, more details are here Neon Docs
    • Gas costs on the Neon EVM are paid in NEON tokens
    • Currently, Neon supports a variety of precompiled contracts. These include: EVM Codes - Precompiled Contracts. For limitations, please check: Neon Docs

  • RPC endpoints/providers. Currently there will be two whitelisted providers - P2P & Everstake that will be launching on mainnet. Neon DAO will decide on including new operators to the whitelist and in the future the whitelist will be removed.

  • No “weird” chainId behavior. There is no weird chainId behavior. All information can be found on chainlist.org

  • Support by major wallet providers. Neon EVM already supports Metamask and will be supported by following wallet providers once on mainnet: Zerion, Kana, Welldone, Frontier, Coin98, Bitkeep

  • Address formatting. It is the same as standard Ethereum address: Ethereum addresses are composed of the prefix “0x” concatenated with the rightmost 20 bytes of the Keccak-256 hash of the ECDSA public key. In hexadecimal, two digits represent a byte, and so addresses contain 40 hexadecimal digits. Contract addresses are in the same format, however, they are determined by sender and creation transaction nonce.

  • On-chain multi-signature infrastructure. Neon EVM works with Angel DAO on a friendly fork on Gnosis Safe.

  • Liquidity on assets’ to be listed. The following assets will be listed when we launch mainnet (already on devnet)

    • USDC, USDT, SOL, WSOL, NEON, WNEON

In case of successful integration with Wormhole, following Wormhole-wrapped tokens will be added:

  • wDAI, wETH, wWBTC, wAAVE, wCRV, wBAL

  • Bridging infrastructure. Neon EVM has different solutions when it comes to bridging infrastructure

    • Wormhole: The bridge that allows you to bridge tokens across different chains. The guardian proposal has been submitted for integration with Neon EVM and aim is to complete tech integration by 09.12.22
    • NeonPass: NeonPass links Solana and Neon EVM to provide a smoother EVM-compatibility experience for end users (https://neonpass.live/). NeonPass is not a bridge connecting two separate blockchain ecosystems. Rather, it acts as a two-way transfer tool for bringing assets in and out of the Neon EVM platform, which itself is a Solana smart contract directly connected to the network. Under the hood, NeonPass functions by transferring SPL tokens from standard Solana “Associated Token Accounts” to Neon EVM Token Accounts with implemented ERC-20 interface (ERC-20-for-SPL) within Neon EVM. Neon EVM ERC-20-for-SPL Token Accounts are specialized Solana accounts instantiated in the Neon ecosystem. These accounts can interact with Solidity dApps and are similar in structure to Associated Token Accounts in the broader Solana environment. They store tokens associated with a user’s Neon EVM-facing MetaMask wallet. NeonPass is the revolving door of liquidity between Solana and Neon EVM. It will equip users with an easy-to-use tool for:
      • Sending permitted SPL tokens, including NEON, into Neon EVM ERC-20-for-SPL Token Accounts to use dApps and pay for Neon transactions. Permitted SPL tokens, excluding NEON, have a corresponding ERC-20 contract deployed in Neon.
      • Withdrawing SPL tokens from Neon EVM ERC-20-for-SPL Token Accounts back to Solana. Once assets are on Solana, users can use Wormhole to send assets to Ethereum

  • Full disclosure of network security and points of centralization. Neon EVM is trustless and there is no point of centralization in it. Neon EVM is governed by Neon DAO. All transactions are checked and validated on-chain by the Neon core program. The Neon core program operates over the Solana blockchain and is validated by Solana validators. A Neon Proxy operator can’t forge a user’s signature nor change a user’s transaction. It performs only the role of the transport layer for the delivery of transactions inside the Solana. A Proxy operator can’t censor transactions because a user can send a transaction to any operator. Plan is to enable everyone to be able to run a Neon Proxy without limits.

  • Commitment in a catastrophe scenario on the network. In case of a catastrophe scenario our technical / community team will be able to support Aave quickly: suggestion is to have a dedicated Discord and Slack Channels. Telegram would also work - there is an ongoing conversation with the Aave team over Telegram. There will be dedicated business developers and technical leads in the channel to streamline the process. There is also an emergency system to stop transaction processing on Neon EVM in a catastrophe scenario to prevent the theft of user funds.

  • Simulation/fork infrastructure. Integration with Tenderly is being discussed. Developers can use https://book.getfoundry.sh/, but they should connect to Tracer API endpoint ( To be provided )

  • Support of data indexing solutions. Neon EVM is working with the following indexing solutions:

    • The Graph
    • Covalent
    • Aleph
      Neonpass is not a bridge; rather a transfer tool. We will share the technical roadmap in couple of days here as well :) Currently we are finalising it and would be super happy to share it with you guys!
7

Every new thing will have people for and against, not only Neon EVM, including Ethereum two-layer network and other public blockchain, all have more or less different disadvantages; some people judge according to TVL, some people judge according to the number of users and data; but why don’t we look at it with development and innovation eyes, what we need is to build and grow together, you believe in it So it exists, and vice versa.
This is my personal comment, what we are trying to do now is to lay a strong foundation to come in better.

2 Likes
8

I personally totally share your view. What attracts me to this space is the speed of innovation, new products & ideas, novel methods and I simply love testing and checking new offerings / projects. I do believe that in this space this aspect is highly imperative and in the end of the day we should strive to enable users to have choices. All of us, we are contributing to the space and have diverse offerings to certain degree. I prefer to use products that offer me choices, where I don’t need to jeopardise my preferences and commence searching / investigating other products due to lack of choices. Of course, introducing novel integrations bring also an immense degree of accountability into play. However, in my personal belief, if a product has strong fundamentals and has done all of its homework in terms of security and relevant functionalities, why not offer it and simply enable the end users decide what they like the most.

Coming back also to your point @fig regarding signalling and inviting other other EVMs such as Aurora. Question is why not? One would rather have a smaller set of atomic networks that are denser and more engaged than a large number of networks that aren’t there. Eventually those atomic networks tip over to the next atomic networks of users.

1 Like
9

I’m glad to see this proposed in the community (I’m all for deploying on neon evm)
reason:
1: Although solana suffered from Waterloo, the ecological developers are still there. I think the follow-up solana will be brilliant again
2: Neon EVM has received a lot of attention as the first solana EVM, which can obviously bring considerable TVL and traffic to AAVE
3: The downtime of Solana has basically been resolved
So I think that if it can be deployed on Neon EVM, it may make AAVE more powerful

10

Neon follows a respectable goal bring EVM to not evm chain. Yet I cannot consider Solana as a secure chain for Aave deployment. Last downtime occur October 1ft during more than 6 hours what’s is huge. An price movement can be significant during as long downtime. So, to responsibly allocate time of Aave developers and prevent development of a risky Aave Market for user and Aave community my vote will be against this proposal.

1 Like
11

Hey @Nandy.eth many thanks for expressing your concerns and we truly appreciate it. Your concerns are justified; nevertheless there has been significant changes in Solana to address the issue that you depicted.
First and foremost, would like to draw your attention to network uptime page: Solana Status - Uptime History
In addition, would like to share here some articles that demonstrate how Solana is addressing these issues: Making the Case for Solana: Fighting the FUD
Hope it does answer some of your concerns :slight_smile:

2 Likes
12

I’m a bit sad to write this because having briefly met the NEON engineers I can only talk highly of them.

Unfortunately NEON is a Castle built on a sandbank and i’m more than pessimistic about the evolution of Solana L1.

image
image2342×768 138 KB

Deploying on a new network costs 3 valuable ressources in the following ascending order : Money, time & focus.

in this proposal, the future prospects of the underlying L1 make deploying on a L2 a too costly investment.

That is why the Aave-chan Initiative casted a NAY vote to the snapshot.

image
image782×884 178 KB

2 Likes
13

Hey @MarcZeller many thanks for your vote. As Neon Collective we do appreciate every piece of feedback and every vote that users cast. There is nothing wrong with having opposing views and expressing concerns. I love how it is done in a transparent manner and I hope that this transparency persists throughout.
My personal view is following as being avid decentralisation maxi: every individual user should be able to get what he wants and what he needs, especially if we are talking about solidifying adoption further. There are users that inherently use Solana and enjoy utilising it despite its drawbacks, which are related to the downtimes in the past. Nevertheless, I am not taking a side of any chain because I’m a fan of various ecosystems such as Ethereum, Polkadot, Cosmos, Algorand, and Solana. Every chain in no matter which shape and form has the goal of furthering adoption and personally I am in this space, because I consider transparency being a right not a privilege and I do believe that every individual should choose for himself and have the rights and tools to do so. In the end, we all strive to get away from the world that we are tired of and accomplish something which is more superior and provides inclusion for everybody. I would love to see this space succeed and it requires all of us to stick together and bring out as many solutions as possible. I am of avid belief that the community should evolve to the stage where it can dictate everything and has best interests of the underlying solution or project. In fact Neon Collective has shown its support and keen interest with more than 6000 Yes votes. Unfortunately they didn’t have that much Aave to surpass the ‘No’ votes currently.
I do also comprehend that it requires resources on Aave side, as you mentioned: Money, time and focus and I totally respect the concept of prioritisation. We as a collective are totally fine with:

  • granting as much time as needed for the Aave community
  • with assisting Aave with internal and external resources. For example, one of our collective members have deployed Aave V2 on Neon EVM devnet: * https://github.com/mixbytes/protocol-vV
  • The integration implies no code change (something that I would like to emphasise)
    Thank you once more and any feedback is welcome here :slight_smile:
1 Like
14

I appreciate your feedback.

My opinion was established using the uptime downtime tracker you mentioned.

Yes there is no recorded downtime during the last 3 months and it’s go to the good direction. But if we go back a little bit forward just 1 month more. We can see recurrent “major outage” spaced by 2 to 3 months. Maybe Solana devs said they have fix issue. Yet the best test is the mainet user test and currently time without major issue is not significative compare to time between to recorded recurrent issue.

It’s not about does Solana innovate and does it’s a good place to buy and hold tokens.

It’s: “Does Solana is risky for Aave ?” In a sense of does Solana deployment I a good location of time and effort. And does a Solana Aave Market have a good ratio between new revenue for the protocol and likelihood of generating bad debt for the protocol.

And currently downtime increase the likelihood of generating bad debt.

1 Like