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