$AURADEFI: Aurora EVM DeFi on NEAR

$AURADEFI: Aurora EVM DeFi on NEAR

$AURADEFI Draft Composition & Weights
$AURADEFI Draft Composition & Weights
NEAR Aurora Ecosystem Token TVL Research
NEAR Aurora Ecosystem Token TVL Research
NEAR Ecosystem Research
NEAR Ecosystem Research

Phased Basket Product Development on Aurora/NEAR

Roll-out of PowerPool investment products for the NEAR ecosystem will begin with $AURADEFI, a set of inter-related sub-pools for tokens operating on the Aurora EVM-compatible smart contract on NEAR. In Phase 1, there will be two sub-pools; one for more established ‘value’ tokens with trackable fundamentals like TVL and fees, and another for recently launched ‘growth’ tokens with the most potential for appreciation. Over time, the $AURADEFI itself will become a sub-pool in the broader $NEARDEFI collection of pools/baskets and pools-of-pools.

Background on NEAR

Near is the latest L1 to garner attention in crypto due to its $800M+ ecosystem fund and the momentum of Aurora. A PoS chain with dynamic sharding and 2-second finality, it is viewed in some aspects as the ETH 2.0 roadmap. There are differences, however, as Near’s use of dynamic sharding is how it plans to scale vs Ethereum being rollup-centric. Another big difference vs other ecosystems is that they are not trying to depend on one environment or language. While Rust is the main language native to Near, if a developer wants to use the EVM (Aurora), Substrate (Octopus Network), JavaScript, whatever, they can. From a user perspective, the goal is that they will be able to use apps built using any of these languages seamlessly. Cross-contract calls are what allow Near to compose like this, and there are already some things happening between Near native apps and Aurora.

About Aurora

Since it is a smart contract, Aurora idoes not need a separate validator set or to rely on sequencers and verifiers like a rollup (although it does need relayers). Aurora shares the same security like any other contract on Near. This means that there is a lot of work removed for Aurora: it does not need to get separate validators, worry about consensus, storage, or any other tasks that a blockchain would need to handle.

image

Being implemented as the EVM means developers can use all of the normal tooling available in the Ethereum ecosystem and the look and feel of Aurora will be the same. Users can simply use Metamask and pay gas fees in ETH and developers have access to tools like Truffle and Hardhat for their smart contracts written in Solidity or Vyper. It is the same Ethereum experience but on Near. Now, while ETH is the native asset in Aurora and used for gas, the Near blockchain only accepts NEAR, and so Aurora needs to use relayers to make this experience work. The process is as follows:

User signs an Ethereum transaction (e.g. with Metamask) and sends to the RPCRPC wraps the tx into a Near tx and sends to the Aurora contract on NearTransaction is verified and the original tx is sent to the Aurora engine contractAurora engine contract parses the tx and executes it, calculating gas in ETHETH is paid to RPC for tx

In simple terms, what has happened is that NEAR was used for gas (paid by the relayer) to execute the contract on Near with the relayer collecting ETH from the Aurora user. In a rational, completely free market, we would expect the ETH collected from the Aurora user to be slightly more than the relayer paid in gas fees on Near (to compensate for the service). While anyone can run a relayer, right now this process is heavily incentivized by the Aurora Labs RPC. Transactions were 100% subsidized (i.e. free) in the past, but in February there was an emergency update to implement 1 gwei minimum gas due to excessive load (bots) from a new game called MoonFarmers (games and nft mints tend to be the worst offenders). There is little incentive for someone to run their own relayer and pay the full NEAR gas fee while Aurora is subsidizing. Aurora wants to subsidize gas fees in perpetuity and is one of the main reasons for running the Aurora validator (to be discussed later). Combine this with Near’s sharding technology and mostly empty blockspace at the moment and you have an enticing environment for EVM developers.

As should be clear, while Aurora looks and feels like the EVM, and many users will be onboarded from Ethereum, it is not really an Ethereum scaling solution as all settlement, data availability, and execution is on Near. In other words, all of the economic value on Aurora flows to the NEAR token, not ETH. You could probably call it an EVM scaling solution though.