Other system · settles to NEAR Protocol
Aurora ticker AURORA
Summary
Aurora borrows NEAR's consensus. Users sign ordinary Ethereum-format transactions. A relayer wraps each one in a NEAR transaction that calls the engine contract, pays the NEAR gas, and charges the user ETH at a fixed gas price. NEAR's proof-of-stake validators include and execute those calls in NEAR blocks. A separate indexer, the refiner, rebuilds Aurora blocks in Ethereum's block format from NEAR blocks, so Aurora block numbers track NEAR block heights. The engine is upgradable. A public NEAR query on 2026-09-27 showed engine version 3.10.1, owned by a controller contract whose top role is held by a five-member council account. The same query showed a full-access key on the engine account. 12378112728
Design
- System
- Other systemNot a standalone chain: Aurora is an EVM implemented as a smart contract at the NEAR account "aurora" (EVM chain ID 1313161554). NEAR validators include and execute its transactions; Aurora has no validators, fork choice or finality of its own. It calls itself a layer 2 on NEAR, but it posts no batches or proofs like a rollup and has no separate consensus like a sidechain. Gas is bridged ETH; AURORA is the governance token. Live on 2026-09-27; not migrated or rebranded.
- Settles to
- NEAR ProtocolEvery Aurora transaction is a NEAR transaction to the engine contract, so Aurora's ordering, execution, finality and availability are NEAR's. Assets reach Aurora from NEAR through the engine's built-in token mapping, and from Ethereum through the Rainbow Bridge.
- Settlement family
- Ethereum / EVM
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Economic finality
- Who makes blocks
- NEAR's stake-selected validators; the top 100 produce blocks and chunks. Aurora Labs runs the default public relayer (mainnet.aurora.dev), but anyone with a funded NEAR account can run their own relayer and submit transactions to the engine.
- Fork choice
- Aurora follows the NEAR chain. NEAR validators produce and finalize blocks by stake-weighted approval, and Aurora has no fork choice or reorganization rule of its own. The refiner only reflects the NEAR blocks it has processed.
Qualifications
- Scarce resource · Partial. The stake that secures Aurora is NEAR validators' NEAR stake. AURORA tokens are not staked to produce or finalize blocks.
- Settlement family · Partial. Ethereum family describes Aurora's execution environment and tooling. Blocks are produced and finalized by NEAR, which has no settlement family of its own in this comparison.
- Finality · Partial. Aurora inherits NEAR finality. Aurora's site states about 1.2 seconds; NEAR's docs describe most transactions as final within 1-3 blocks. Withdrawals to Ethereum take hours longer.
- Block metrics · Partial. Aurora blocks are rebuilt from NEAR blocks by the refiner. Block numbers follow NEAR heights, and the reported block gas limit is a placeholder maximum, so block-level metrics describe NEAR rather than an Aurora-specific block producer.
- Fee market · Not applicable. There is no gas auction: relayers charge a fixed EVM gas price (0.07 gwei on 2026-09-27) and pay the underlying NEAR gas themselves.
- Layer label · Contested. Aurora calls itself a layer 2 on NEAR. It is a contract executed directly by NEAR validators, with no batch posting, fraud proofs or validity proofs, so this comparison does not treat it as a rollup.
- Upgrade authority · Unknown. A public NEAR query showed that the engine owner is a controller contract; its top role is held by a five-member council account, with separate updater and pauser roles. It also showed a full-access key on the engine account. Who holds that key, and how the council relates to the 13-seat Aurora DAO, was not established.
Tradeoffs
- Emphasizes
- Scalability and Security Contested
- Gives up
- Independence and decentralized control. Aurora cannot run without NEAR. An owner contract run by a small council can upgrade or pause its engine, and most users reach it through the relayer that Aurora Labs operates. EVM compatibility also has limits: a fixed gas price, altered block-level opcodes, and NEAR's per-transaction gas cap.Here, security means reusing NEAR's full validator set instead of recruiting a new, smaller one. That benefit is limited by whoever can change the engine contract. This review observed the controller roles and a full-access key on the engine account, but did not establish who holds that key, so the security reading is marked contested. Aurora Cloud's site calls Virtual Chains an effective solution to the trilemma; this comparison treats that as a contested vendor claim.
- Full node at home
- Demanding 48929Aurora's FAQ says an Aurora node needs the same hardware as a NEAR RPC node plus 20-30% more storage. NEAR lists 8 cores/16 threads, 16-32 GB RAM and 2.5-4 TB of fast SSD (15k IOPS on the minimal spec). Aurora's 2023 node guide says reindexing from genesis takes weeks to months and up to 6 TB, so its installer starts from NEAR and Aurora snapshots instead.
- Throughput claims
- Theoretical peak: 500 tx/s 4Theoretical peak; not comparable across chains or with observed load.Upper end of a stated 300-500 range per Aurora chain instance.None stated. The FAQ frames throughput as depending on computation (about 1 Tgas per millisecond); its own worked example of 10 Tgas per transaction gives about 100 per second, and the 300-500 range is given without a method.An FAQ estimate with no stated method, window, transaction mix or measurement; a theoretical peak that is not comparable and is not observed load. Ignores propagation, state growth and the load of everything else sharing NEAR's shard capacity; not comparable with another chain's figure.
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | Not yet assessed under the current definitions; no protocol-level swap mechanism on Aurora was found, and no swap contract was reviewed; EVM contracts are only building blocks for one. Aurora's ecosystem page lists NEAR Intents, which settles on NEAR rather than on Aurora. 20 |
| Authenticated data publication | Unknown | Not yet assessed under this row's current definition. |
| Light clients | Built into the protocolLimited scope | NEAR light client: every Aurora transaction is a NEAR transaction, and consensus produces what a light client checks, since NEAR specifies a light client that checks block-producer approvals; the Rainbow Bridge relies on NEAR proofs. Limited: no Aurora-specific light client for EVM state was found, and most users trust an RPC relayer's rebuilt view of Aurora blocks. 71530 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Aurora was found in Aurora's documentation. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Spend conditions are EVM smart contracts. The engine also supports relayer-paid meta-transactions and calls into NEAR contracts. The deployed 3.10.1 release updates gas rules for EIP-7702 delegation transactions, and 3.11.0, released but not yet deployed when checked, improves how their authorizations are validated. 121213 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; Safe's deployment registry lists its version 1.4.1 smart-account contracts on Aurora (chain ID 1313161554). A Safe account needs a set number of owners to approve each spend, lets owners be replaced and can add modules, including one that restores access under set conditions, but no cited source shows a delay or recovery module deployed there, and an owner threshold alone meets neither part of this row. The engine owner's power to pause or upgrade is not a user reversal or recovery feature. 3637 |
| Rollups | None found Earlier definition | No rollup that settles to Aurora was found. Aurora's Virtual Chains are separate copies of the engine contract deployed on NEAR, which Aurora itself contrasts with rollups and sidechains. They are not anchored to Aurora. 6 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | ThinTrisolaris | Aurora's ecosystem directory lists Trisolaris as the first AMM on Aurora, and its contract repository targets Aurora. A third-party aggregator's public data feed still tracked Trisolaris on Aurora with nonzero liquidity when checked; no figures are used here. Aurora's own homepage shows its value-locked figure as not available. Trisolaris's web interface renders with scripts, so live trading was not tested, and liquidity depth was not measured. 5202132 |
| Issuer-native stablecoins | None found | No issuer lists Aurora as a native network: Circle's USDC address page and Tether's protocol page list NEAR but not Aurora. Aurora carries four bridged or mapped stablecoin versions. USDC and USDT are engine-mapped copies of the issuers' NEAR tokens, and USDC.e and USDT.e come from Ethereum through the Rainbow Bridge. 18192223 |
| Algorithmic stablecoins | Unknown | Aurora's token list includes a bridged FRAX, and its directory lists Polaris Finance with a seigniorage multi-peg design. Their current design, usage and liveness were not verified. 1920 |
| Bridges | Native to the protocolEngine token mapping between NEAR and Aurora, Rainbow Bridge (Ethereum, NEAR, Aurora), Third-party routes listed by Aurora (LayerZero, Stargate, Meson) | The engine maps NEAR fungible tokens to ERC-20 contracts and has exit precompiles back to NEAR and Ethereum. Aurora's bridge documentation is built around the Rainbow Bridge for moves between Ethereum, NEAR and Aurora. NEAR's Omni Bridge can bring other chains' tokens to NEAR, and from there to Aurora. Risk: Transfers to Ethereum take two transactions and cannot be cancelled. Aurora's docs give conflicting waits: 4-8 hours on one page and up to 16 hours on another; the same introduction mentions a faster route, the Fast Bridge, whose current operation was not checked. Aurora calls the bridge trustless, but upgrade and admin authority over the bridge contracts was not reviewed. The engine that holds the mapped tokens is itself upgradable and pausable by its owner, and third-party routes carry their own trust models. 12151617182031 |
| Block explorers | First-partyAurora Explorer (Blockscout, explorer.aurora.dev), NearBlocks (underlying NEAR transactions) | Aurora's docs name its Blockscout instance for mainnet, and aurorascan.dev now redirects there. The engine repository links NearBlocks for the underlying NEAR account. Explorer data is indexer output, not consensus. 102425 |
| Hardware wallets | ThinTrezor (Aurora network through MetaMask or Rabby) | See the custody rows. Trezor's AURORA page lists the Ethereum and Aurora networks, but Trezor Suite has no Aurora network, so a Trezor reaches Aurora through MetaMask or Rabby. Ledger support could not be verified. 2635 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | UnknownSame as native: Unknown | Ledger coin pages tried for Aurora returned 404, and the static content of Ledger's supported-assets page did not name Aurora. That page is only partly readable without scripts, so absence is not proof. Using a Ledger through a third-party EVM wallet on the Aurora network was not checked. 33 |
| Trezor | Through an intermediaryMetaMask or RabbySame as native: Unknown | Can: Use a Trezor Safe 3, Safe 5 or Safe 7 on the Aurora network through MetaMask or Rabby, the third-party apps Trezor's AURORA page lists Can: Hold the AURORA token on Ethereum in Trezor Suite Cannot: Manage the Aurora network, or ETH gas on it, in Trezor Suite: current Suite code has no Aurora networkTrezor's AURORA page lists the Ethereum and Aurora networks and names Trezor Suite, MetaMask and Rabby without mapping apps to networks. Suite has no Aurora network, so under the custody evidence rule the device reaches Aurora through the third-party apps, and Suite holds only the token on Ethereum. 2635 |
Public data
iKnow Blockchain has no public-data lookups for Aurora yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
Aurora Engine 3.11.0 released with Osaka execution rules
Engine 3.11.0 switches execution and gas validation to Ethereum's Osaka rules, improves EIP-7702 authorization handling and fixes several gas-accounting and precompile bugs. On 2026-09-27 the mainnet engine still reported 3.10.1, so this release was published but not yet active there.
- Implementation:Released
- Release:published 2026-09-17
- Activation:not active on mainnet as of 2026-09-27
Source: Aurora Labs — Aurora Engine Release 3.11.0 (external site)
-
Aurora DAO approved 2026 funding for Aurora Labs and its NEAR validator
Two forum proposals were posted on 2026-05-04 and marked approved on 2026-05-22. One grants Aurora Labs 25,000,000 AURORA for 2026 and reports 2025 work on engine upgrades, Virtual Chains and NEAR Intents tooling. The other continues the NEAR validator the DAO runs, with a new delegator reward farm.
- Proposal:Approved
- Implementation:approval stated by staff reply
- Release:not applicable
- Activation:not independently verified
Sources: Aurora Forum — [APPROVED] Aurora Labs Grant Allocation for 2026 (external site) · Aurora Forum — [APPROVED] Aurora Validator on NEAR 2026 (external site)
-
Aurora Engine 3.10.1 released; mainnet engine reports 3.10.1
Aurora Labs published engine 3.10.0 on 2026-01-14 and 3.10.1 on 2026-01-23. The releases include Osaka-era precompile changes (including secp256r1), updated gas rules for newer Ethereum transaction types and the removal of legacy ETH-connector code from the engine. On 2026-09-27 the deployed mainnet contract reported version 3.10.1.
- Implementation:Released
- Release:3.10.0 on 2026-01-14; 3.10.1 on 2026-01-23
- Activation:mainnet engine reported 3.10.1 on 2026-09-27
Sources: Aurora Labs — Aurora Engine Release 3.10.0 (external site) · Aurora Labs — Aurora Engine Release 3.10.1 (external site)
-
Aurora DAO approved rotating its 13 council seats
A forum proposal to refresh the Aurora DAO council while keeping 13 seats is marked approved. Proposed members include the NEAR Foundation, Aurora Labs, NEAR One, HOT Wallet, HAPI, two Virtual Chain projects and early investors, matching the members now listed on Aurora's DAO page.
- Proposal:Approved
- Implementation:council list on Aurora's DAO page matches the proposal
- Release:not applicable
- Activation:reflected on the DAO page as of 2026-09-27
Sources: Aurora Forum — [Approved] Rotating the Composition of Aurora DAO Councils (external site) · Aurora — Aurora DAO (external site)
Topics your AI can explain
Your AI can explain these topics for Aurora through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Who holds the full-access key on the engine account, and how the five-member council behind the controller relates to the 13-seat Aurora DAO, was not established. Both were observed through a public NEAR query, not a published Aurora page.
- Engine 3.11.0 (released 2026-09-17) was not yet running on mainnet when checked; the engine reported 3.10.1. No deployment schedule was found.
- Aurora docs disagree on withdrawal times to Ethereum (4-8 hours versus up to 16 hours), and the current operator and upgrade authority of the Rainbow Bridge contracts were not reviewed.
- The Rainbow Bridge app and the Aurora status page could not be read in this review (script-rendered page; certificate mismatch), so live bridge status is unknown.
- Current Aurora node storage needs were not captured; the node guide dates from 2023 and the node requirements page in the docs is empty.
- Ledger support for AURORA or the Aurora network could not be verified from a Ledger page.
- Whether Trisolaris and other listed AMMs still operate with meaningful liquidity was not verified; no liquidity figures are used.
- Current design and usage of algorithmic or hybrid stablecoins on Aurora (bridged FRAX, Polaris Finance) were not reviewed.
- Atomic-swap and payment or state channel surfaces on Aurora were not reviewed beyond the documentation search.
- Aurora's own figures for block time (0.6 seconds on the homepage, 1 second on the Virtual Chains page) and finality (1.2 seconds) are unaudited statements.
- Aurora Labs' DAO-approved 2026 plan moves effort toward cross-chain products built on NEAR Intents, restricts new Virtual Chain sign-ups and proposes merging Aurora's websites. How this affects maintenance of Aurora mainnet was not established.
- DefiLlama's Aurora chain page blocked automated reads in this review, so only its public data feed for Trisolaris was used, and only to confirm the listing.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- What is Aurora? (external site)
- Aurora Engine (external site)
- Networks Endpoints (external site)
- Frequently Asked Questions (external site)
- Aurora - The Network of Virtual Chains (external site)
- About Virtual Chains (external site)
- How the Aurora Relayer 2.0 works? (external site)
- Spinning up your own Aurora node (external site)
- aurora-is-near/standalone-rpc (external site)
- aurora-is-near/aurora-engine (external site)
- aurora-is-near/aurora-controller-factory (external site)
- Aurora Engine Release 3.10.1 (external site)
- Aurora Engine Release 3.11.0 (external site)
- Aurora DAO (external site)
- What is the Rainbow Bridge? (external site)
- Bridge to Ethereum (external site)
- Transfers Between Aurora and Near (external site)
- How to bridge liquidity to Aurora? (external site)
- Token List (external site)
- Ecosystem: Exchanges (external site)
- trisolaris-labs/trisolaris_core (external site)
- USDC contract addresses (external site)
- Supported Protocols and Integration Guidelines (external site)
- Aurora blockchain explorer (external site)
- Block Explorer (external site)
- Aurora wallet (external site)
- Validators (external site)
- Lifecycle of a Transaction (external site)
- Hardware Requirements for RPC Node (external site)
- Light Client (external site)
- Omni Bridge Overview (external site)
- Trisolaris protocol data (third-party aggregator API) (external site)
- Supported crypto assets (external site)
- [APPROVED] Aurora Labs Grant Allocation for 2026 (external site)
- Trezor Suite network configuration (trezor-suite, develop branch) (external site)
- SafeL2 v1.4.1 deployments by chain ID (safe-deployments registry) (external site)
- How Safe Smart Accounts work (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding