Ephemeral Rollup - MagicBlock Documentation

Magicblock’s core idea leverages the Solana Virtual Machine (SVM)’s account-based structure and parallel execution to optimize state management. By structuring the state into clusters, users can lock one or multiple accounts and temporarily shift state execution to a dedicated auxiliary layer—which we define as the “ephemeral rollup” (ER).

How It Works

State Delegation – Users lock state accounts to an ephemeral rollup, enabling a configurable runtime that operates independently.
Sequencer Control – The sequencer temporarily modifies the state in this rollup. If constraints are violated, the state is forcefully reverted and unlocked on the L1.
Parallel Read Access – Even as accounts are delegated, transactions on the base layer can still read their state, ensuring compatibility. Non-delegated accounts remain fully modifiable and unaffected.

Capabilities of Ephemeral Rollups

The ephemeral rollup functions as a specialized SVM runtime, significantly enhancing transaction throughput. This runtime can be customized to include:

✅ Gasless Transactions – Enable scalability and mass adoption.
✅ Faster Block Times – Enables real-time interactions for seamless UX.
✅ Integrated Scheduling (Ticking Mechanism) – Built-in automation, like Clockwork, to execute transactions on schedule.

Programs and assets reside directly on the base layer and are fully compatible. Any improvements or advancements at the base layer are immediately available, without the need to modify or re-deploy programs.

✅ Program and States Synchronization – No fragementation. States and programs can interact with any existing protocol and assets.
✅ Horizontal Scaling – Launch multiple rollups on-demand and perform millions of transactions.
✅ Familiar Tooling – Reuse any existing and familiar programming language, libraries and testing tools.

Seamless User Experience

All of this happens transparently to the end user. A specialized RPC provider dynamically routes transactions to both the base layer and the ephemeral rollup(s) in parallel—optimizing execution.

The white paper describes the architecture and the scalability solution in detail.

How are Transaction executed?

Once transactions are submitted via specialized RPCs, the provisioner detects delegation events and manages runtime provisioning based on configuration.Below is a high-level overview of the process of executing transactions in the ephemeral rollup:

Delegation

State accounts are delegated to the Ephemeral Rollup via the Delegation Program, specifying parameters like lifetime and update frequency.

Transaction Execution

Transactions are routed to the appropriate execution layer (base or Ephemeral) via an RPC router.

State Commitment

The operator periodically commits the ephemeral state to the base layer, including new state and relevant pointers. The state is finalized using a fraud-proof mechanism as detailed in the paper.

Continued Transaction Execution

Transactions are continuously routed to the appropriate execution layer (base or Ephemeral) via an RPC router.

Final Commitment and Undelegation

Ephemeral states are committed to the base layer and accounts are undelegated via the Delegation Program to the original owner.