Aurora Mainnet is an EVM environment implemented through Aurora Engine on NEAR. ETH is its user-facing base and gas asset, while AURORA is the profiled governance token.
Use this page to separate AURORA governance from ETH gas, understand the relayer and NEAR dependency, and prepare compatible wallet, contract and bridge actions.
Subject:
Aurora
Market mode:
Snapshot Only
Fee asset:
ETH
Timezone:
UTC
This page does not guarantee relayer availability, bridge timing, a fixed gas price or AURORA governance outcomes.
Content ownership: BitcoinToolkit Editorial TeamTechnical references: Official protocol and developer documentation.Review approach: Technical explanations are checked against primary sources and updated when the network or asset changes.Last content review: Data integration last tested:
Aurora at a Glance
SubjectAurora Mainnet and AURORA
Profiled AssetAURORA
User Gas AssetETH
Underlying NetworkNEAR
ExecutionAurora Engine EVM
Market ModeSnapshot Only
ETH pays Aurora Mainnet gas; AURORA is the governance market asset.
Aurora Engine runs on NEAR and relayers submit underlying transactions.
Why Aurora Uses ETH for Gas, Not AURORA
The page subject, market token and fee balance are deliberately different.
Three distinct roles
Aurora is the EVM environment and ecosystem. ETH is the base token shown to Aurora Mainnet EVM users and is required for ordinary gas. AURORA is a governance token with its own market and ecosystem role; holding it does not automatically give a wallet the ETH needed to sign a transaction.
Under the surface, Aurora Engine executes as a NEAR smart contract and underlying computation consumes NEAR gas. Relayers translate the user-facing EVM transaction into the NEAR call. This layered accounting is why a generic statement that the ticker pays gas would be wrong.
User implication
Check which balance a wallet labels as gas and keep enough ETH on Aurora Mainnet. NEAR in a separate NEAR account and AURORA in an EVM wallet do not silently substitute for that ETH balance.
How Aurora Engine Processes EVM Transactions
Aurora presents Ethereum-style interfaces while NEAR performs the underlying contract execution.
From EVM signature to NEAR result
The user signs an Ethereum-format transaction with Aurora Mainnet's chain ID. An Aurora RPC endpoint and relayer validate the envelope, submit the corresponding NEAR transaction to Aurora Engine and return an Ethereum-compatible receipt. Contracts and storage live in the Aurora EVM state managed by the engine.
NEAR gas and EVM gas measure related but different work. A transaction can encounter implementation limits that do not exist on Ethereum Mainnet, so developers should test high-computation calls and use Aurora estimates rather than importing gas assumptions blindly.
Finality dependency
Aurora results depend on NEAR block production and finality plus the relayer path used to submit the transaction. A wallet success message should be checked against a current Aurora receipt before the application advances.
Bridging and Onboarding to Aurora
A user needs the correct representation and a small ETH balance on Aurora for the next action.
Moving assets
Aurora supports routes between Ethereum, NEAR and Aurora through documented bridge and connector systems. Each route defines the source asset, mapped representation, destination address and fees. Verify the current official route and token contract instead of relying on the same ticker across interfaces.
After arrival, confirm the token balance and preserve ETH for gas. Bridged assets can use Aurora-specific ERC-20 representations, and withdrawal steps can differ by destination. Exchange support for an asset does not prove support for Aurora Mainnet deposits.
Operational limits
Relayers, RPC endpoints and bridges are additional dependencies. Incidents can affect submission or transfer completion even when NEAR itself continues producing blocks.
Common Aurora Mistakes
Asset-role confusion is the most avoidable source of failed transactions.
Checklist
Confirm Aurora Mainnet and chain ID, keep ETH for gas, verify the token contract and bridge route, and inspect the Aurora receipt after submission.
Do not use AURORA as the default gas assumption.
Do not describe Aurora as an independent EVM L1.
Do not confuse a NEAR account with an Aurora EVM address.
Do not infer bridge support from a matching symbol.
Next action
Connect with current Aurora network settings, obtain a small ETH gas balance and test the exact contract or bridge workflow before increasing value.