Aurora EVM infrastructure overview

Aurora operates as a layer-2 solution built directly on the NEAR Protocol, providing a fully EVM-compatible environment for Ethereum developers. Rather than creating a parallel ecosystem, Aurora allows you to deploy smart contracts and dApps using familiar tools like Hardhat, Remix, or Foundry without rewriting code for a new virtual machine. This approach lowers the barrier to entry for teams already invested in the Ethereum standard.

The technical foundation relies on a high-performance, pure Rust implementation of the EVM. This design choice prioritizes security and efficiency, enabling the network to handle transactions with lower latency and reduced costs compared to the Ethereum mainnet. By leveraging NEAR’s sharding technology, Aurora can scale horizontally while maintaining compatibility with existing Ethereum tooling and standards.

For builders, this means you can deploy your existing contracts and interact with them using standard Web3 libraries. The infrastructure supports seamless integration with popular wallets and explorers, making it easier to onboard users who are already accustomed to Ethereum-based workflows. You can verify the official documentation and source code for the Aurora EVM implementation to understand the specific technical details.

Developer tooling and setup

Aurora Mainnet is fully EVM-compatible, which means you can use the same tools you rely on for Ethereum. You don't need to learn a new language or swap out your entire stack. Whether you are using Hardhat, Foundry, or Remix, the integration is straightforward.

The base fee token is ETH, not a native Aurora token. This simplifies things for developers who already manage ETH for gas on Ethereum. You can deploy smart contracts and interact with dApps using your existing EVM addresses. This compatibility is the main reason Aurora attracts developers looking for high throughput and low costs without the friction of learning a new ecosystem.

1. Add Aurora to your wallet

To interact with Aurora, you need to add the network to your EVM-compatible wallet like MetaMask. Go to your wallet's network settings and select "Add Network." Enter the following details:

Once saved, your wallet will switch to the Aurora network, allowing you to send and receive ETH on the chain.

Aurora EVM in
1
Install Hardhat

Start by installing Hardhat, the most popular Ethereum development environment. Run npm install --save-dev hardhat in your project directory. Hardhat provides a local Ethereum network, a console for testing, and a flexible plugin system that works seamlessly with Aurora.

Aurora EVM in
2
Configure Hardhat for Aurora

Edit your hardhat.config.js file to include the Aurora network. Add a new network entry with the RPC URL https://mainnet.aurora.dev and Chain ID 1313161554. This tells Hardhat where to deploy your contracts when you run the compile and deploy scripts.

Aurora EVM in
3
Compile and Deploy

Use Hardhat's built-in scripts to compile your Solidity code and deploy it to the Aurora Mainnet. Ensure you have enough ETH in your wallet to cover gas fees. The deployment process is identical to Ethereum, but transactions settle much faster and cost fractions of a cent.

2. Use the Aurora RPC endpoint

For direct blockchain interaction, you can use the public RPC endpoint at https://mainnet.aurora.dev. This endpoint allows you to read and write to the blockchain using standard JSON-RPC calls. For higher volume applications, consider using a dedicated RPC provider to ensure reliability and speed.

3. Test on Aurora Testnet

Before deploying to Mainnet, test your contracts on the Aurora Testnet. This allows you to verify functionality without risking real ETH. You can get test ETH from the Aurora Testnet faucet. The testnet uses the same EVM structure, so any bugs you find here will likely appear on Mainnet as well.

Virtual chains and scalability options

Aurora’s virtual chain architecture lets developers spin up dedicated, isolated EVM environments on top of the NEAR blockchain. Instead of deploying to a shared public chain, you get your own private EVM chain that inherits NEAR’s high throughput while maintaining full Ethereum compatibility.

This setup is ideal for applications requiring specific governance models, custom tokenomics, or dedicated resource pools. By separating your chain’s state and execution, you avoid the congestion and fee spikes common on crowded public L2s.

The table below compares a standard Aurora deployment against a dedicated virtual chain.

FeatureStandard AuroraVirtual Chain
Execution EnvironmentShared public EVMDedicated isolated EVM
GovernanceCommunity-wide protocol rulesCustomizable per app
FinalityNEAR block finalityNEAR block finality
Resource ContentionShared with all dAppsReserved for your app

When choosing between these options, consider your application’s scale. Standard Aurora is sufficient for general-purpose DeFi or social apps that benefit from maximum liquidity and network effects. Virtual chains are better for enterprise solutions, gaming, or specialized DAOs that need predictable performance and strict resource isolation.

Both options leverage NEAR’s sharding technology, ensuring that your chain remains fast and cost-effective. The primary difference lies in control: virtual chains give you the autonomy to tune parameters like block time, gas limits, and access controls without waiting for protocol-wide upgrades.

Market positioning and tokenomics

Aurora operates as a Layer 2 solution on the NEAR Protocol, offering an Ethereum Virtual Machine (EVM) environment without the congestion of Ethereum mainnet. This architecture allows developers to deploy standard Solidity smart contracts while leveraging NEAR’s high throughput and low latency. For users, this translates to transaction speeds that are significantly faster than the base Ethereum layer, with fees that remain stable regardless of network spikes.

The economic model is distinct because it uses ETH as the native gas token. This design choice bridges the gap between the Ethereum developer ecosystem and NEAR’s underlying infrastructure. Developers do not need to learn new tokenomics or manage separate gas wallets; they simply use ETH, which they likely already hold, to pay for transactions. This lowers the barrier to entry for Ethereum-native projects looking to scale.

When compared to other L2s like Arbitrum or Optimism, Aurora’s value proposition centers on its shared security model with NEAR. While competitors often rely on their own sequencers or rollup-specific rollup data availability, Aurora inherits NEAR’s proof-of-stake security. This creates a competitive landscape where Aurora targets developers who want EVM compatibility but are deterred by Ethereum’s high gas costs or want to tap into NEAR’s sharded ecosystem.

The AURORA token itself serves as the governance and staking asset for the NEAR network, rather than acting as a gas token for the Aurora chain. This separation of concerns means the token’s value is tied to the growth of the NEAR ecosystem as a whole, including the activity on the Aurora L2. As more EVM applications migrate to Aurora, the demand for NEAR block space increases, indirectly supporting the token’s utility.

Frequently asked: what to check next