Metisnetwork links Hyperion parallel execution to transaction dependencies

Metisnetwork's Hyperion Layer 2 architecture uses transaction dependencies to determine which contract operations can execute concurrently without inconsistent state updates. Its execution framework combines dependency analysis with speculative processing and conflict checks. Independent work can overlap, while operations touching shared state need validation before their results become committed blockchain changes.

Last updated - 13 Oct 2026

Concurrent Contract Work

Hyperion targets applications whose independent contract interactions can run concurrently across available processing cores. Its architecture includes the Metis Parallel Execution Framework, or MPEF, alongside MetisVM and MetisDB. The framework coordinates execution opportunities, the virtual machine runs contract instructions and the database manages blockchain state.

Blockchain state includes the stored values contract calls read or change. Independent state access creates opportunities for concurrency because one operation does not require another operation's updated values. Computationally demanding applications can benefit from overlapping independent work. The amount of useful overlap follows the workload's actual dependencies, however, so an application category alone cannot predict its throughput.

Dependency Graphs and Scheduling

Hyperion's execution framework identifies potential dependencies before scheduling concurrent work, using static analysis of transaction behavior. The Metis Parallel Execution Framework represents transaction dependencies with a directed acyclic graph. Each node represents a transaction, while a dependency edge indicates an ordering relationship. Independent paths expose opportunities to process work concurrently.

Static analysis examines relevant storage access and execution paths before execution begins. The scheduler uses those relationships to coordinate work while respecting dependencies. Pre-processing can reduce avoidable conflicts, and runtime conflict detection handles actual state interactions during speculative execution.

Transaction sequencing supplies an order the execution framework must respect when dependencies affect results. Concurrent processing can overlap independent computation within that constraint. The graph organizes processing within an ordered batch. Sequencer selection and network-level ordering protections belong to the network's separate consensus configuration.

MetisVM and Contract Execution

MetisVM runs Ethereum-compatible contract instructions within Hyperion's execution layer, complementing dependency-aware scheduling with virtual-machine optimizations. Its architecture includes dynamic opcode optimization, just-in-time compilation for frequently used opcodes and state-aware caching. These components address instruction processing and redundant state access. They contribute differently from the scheduler, which coordinates work across transactions. A faster instruction path can improve execution efficiency while leaving a contract's shared-state relationships intact; caching also needs to respect the state changes relevant to execution.

Can Hyperion Execute Every Transaction at the Same Time?

Hyperion can overlap independent work, while shared-state dependencies constrain which concurrent results remain valid. A transaction requiring an earlier state update must preserve that relationship even when the engine uses speculation. The framework therefore needs more information than the number of pending transactions to identify useful parallel work.

Shared storage becomes a constraint when operations change values other operations need. Concurrent computation then creates a consistency problem the framework must resolve before accepting its results. Separate application requests can still rely on shared values.

Contract identity alone also gives an incomplete description of contention. Dependency analysis examines the state operations access and the relationships between their reads and writes.

Processing capacity sets another boundary even when the framework identifies independent tasks. The scheduler assigns work to available worker threads, so the execution environment affects how many tasks can progress simultaneously. Hardware resources describe capacity; dependencies describe the work eligible to use it. Extra cores cannot remove a state relationship between operations.

A chain of dependent updates can leave processors waiting for valid preceding state. Such a workload exposes a dependency bottleneck even when other capacity remains available.

Speculation and Conflict Resolution

Optimistic concurrency control lets Hyperion attempt concurrent execution while checking whether each attempt used valid state. Hyperion tracks transaction read and write sets during speculative execution. These records identify the state a transaction consulted and the changes it proposed. Conflict validation connects those observations to the transaction dependencies, so an execution attempt alone does not establish an acceptable update.

A stale read occurs when an attempt uses a value an earlier transaction in the required order subsequently changes. The executor must resolve that dependency before accepting the affected result. Conflict handling can discard speculative results and schedule re-execution with the appropriate state. The scheduler coordinates that additional work, while version tracking supplies the information needed to identify the mismatch.

Successful speculation avoids unnecessary waiting when operations are independent. Conflicting access adds validation and re-execution work, reducing the gain available from concurrency. Conflict handling preserves correctness, but it also consumes resources a throughput comparison needs to include.

MetisDB and State Versions

MetisDB supports Hyperion's execution model by managing concurrent state access alongside storage and recovery functions. MetisDB uses multi-version concurrency control for concurrent state access and modification. Its architecture also includes asynchronous input/output, memory-mapped Merkle trees and write-ahead logging. These components address access latency and data durability.

Execution needs to distinguish the state versions speculative work reads and proposes. MetisDB integration handles storage and retrieval for the framework, while validated updates become part of blockchain state. The database architecture separates active state management from historical storage, allowing those functions to address different access requirements. Efficient storage can reduce a bottleneck outside contract computation, although the dependency checks governing an update still apply.

From Validated Execution to State Commitments

Validated transaction results feed Hyperion's state updates before the network sends commitments to Ethereum. MetisDB supports storage of those accepted changes, while a parallelized state-root framework addresses state computation. A state root compactly represents blockchain state, so its computation concerns the updates the executor has accepted.

Local transaction feedback and Ethereum settlement describe different points in this architecture. Hyperion provides execution feedback within its transaction-processing pipeline, while state commitments reach Ethereum periodically. A prompt local response therefore cannot specify the timing of the later Layer 1 commitment. Performance expectations need to identify which point a timing claim measures.

That boundary also keeps execution speed separate from cross-chain transfer completion. Parallel processing concerns work inside Hyperion; it does not, by itself, confirm an asset's arrival through a bridge. Neither local processing latency nor state-root computation supplies a universal duration for the wider operation.

Fixed Ordering and Deterministic Outputs

Hyperion's parallel executor preserves the final state and outputs serial execution would produce for the same transaction order. Scheduling changes when computation runs, while validation preserves the state relationships affecting the outcome. This fixed-order condition matters whenever transactions interact through shared state. Comparing outputs across different transaction orders would change the basis of the comparison.

Deterministic execution gives performance evaluation a concrete correctness criterion. Faster processing should preserve the final outputs and state under the selected order. A throughput improvement accompanied by different state under identical inputs would fail that criterion.

Execution Features and Release Scope

Hyperion performance claims need an identified network environment and release, alongside the workload under evaluation. The December 2025 roadmap targeted an alpha mainnet in Q1 2026 and a mainnet in Q2 2026. Those targets describe planned deployment milestones, not confirmation of a deployed feature set. Execution optimizations, sequencing changes and fee-abstraction features have distinct release scopes. Conclusions about Hyperion's dependency-aware architecture also remain separate from Andromeda's network configuration.

Workload Fit and Shared-State Limits

Hyperion's parallel execution model favors independent state access over workloads dominated by conflicting state updates. AI-related computation, gaming and demanding financial applications are intended uses, but those labels do not establish independence. Their contract behavior determines the execution opportunity.

• Identify independent state access before expecting substantial concurrency.
• Treat recurring writes to shared storage as a possible constraint on parallel progress.
• Include dependency-related waiting and re-execution when comparing processing performance.
• Distinguish contract execution timing from database work and state-root computation.
• Match observations to the Hyperion environment and release under evaluation.

A throughput comparison applies while its workload and execution conditions remain comparable. Heavy contention can leave conflict resolution as the limiting work even when parallel execution is enabled.

Open full-size image

Your questions, answered