1. Structural Constraints of Blockchains: Real-Time and Privacy

2. Ephemeral Rollups (ER): Extending Real-Time Execution on Solana

3. Private Ephemeral Rollups (PER): Enabling Confidential Execution

4. Applications: Where ER Delivers Value

5. Key Takeaways: The Next Phase of Blockchain Design

1. Structural Constraints of Blockchains: Real-Time and Privacy

1-1. Real-Time Constraints

Today’s internet users interact with real-time services on a daily basis. Online games and exchanges are representative examples. The key factor that defines a real-time experience is latency—the time between a user submitting an intent to the network and that intent being reflected in the system. If real-time is defined in terms of latency, the next question is what threshold qualifies as real-time. According to Jakob Nielsen’s widely cited usability benchmark, users perceive a system as responding in real time when responses are returned within 100ms (0.1 seconds).

Source : Binance, League of Legends

Latency sensitivity becomes particularly pronounced in environments where timing directly impacts outcomes. Competitive online games and trading platforms fall into this category, as users must react instantly to opponent actions or to changes in price, spread, and slippage. League of Legends, one of the largest online games globally, operates at approximately 3ms (0.003 seconds), while Binance delivers around 41ms (0.041 seconds). Although these figures vary depending on device, network conditions, physical distance, and server congestion, they generally remain below the 100ms threshold associated with real-time interaction.

The natural question is whether such real-time services can be deployed on blockchain infrastructure. From a pure performance standpoint, centralized servers often remain the most efficient option. However, the purpose of using blockchain is not simply to achieve faster execution, but to preserve both the execution process and its outcomes in a verifiable form while maintaining Web2-level responsiveness.

In centralized systems, operators control both data and execution results. Users may lose access due to policy changes or service shutdowns, and internal processes are difficult to verify. In contrast, blockchains record and validate both state and assets at the network level. Even if a specific application ceases operation, users can retain access to their assets, and the rules governing execution can be verified after the fact.

The core issue, therefore, is whether blockchains can provide block production and finality within 100ms. Current architectures struggle to meet this requirement. Unlike centralized systems where a single server determines outcomes instantly, blockchains rely on multiple participants to share and verify state transitions. User inputs must pass through propagation, ordering, execution, and validation before finalization. This multi-step process introduces latency that fundamentally limits real-time performance.

Solana, often regarded as one of the fastest general-purpose Layer 1 networks with both scale and performance, clearly illustrates this limitation. While it is frequently highlighted for high throughput and short block times, its slot time is approximately 400ms. This makes it difficult to reliably meet the 100ms threshold required for users to perceive real-time responsiveness.

Layer 2 solutions present a similar trade-off. They were introduced to reduce costs and improve performance, but they do not automatically inherit the capital and liquidity already concentrated on Layer 1. Applications, liquidity, and users must be rebuilt, which introduces both time and coordination costs. In addition, periods of high demand can lead to sharp increases in fees and reduced stability. Separating execution environments to gain speed weakens the advantages of unified state and liquidity on Layer 1, while still failing to reliably deliver real-time performance.

At a fundamental level, blockchains were not designed for real-time processing. Their primary objective is to maintain a universally verifiable consensus state. Attempting to replicate millisecond-level responsiveness, already standard in gaming and trading environments, creates a structural conflict. Addressing this requires a different architectural approach: isolating latency-sensitive components into a separate execution layer or redesigning the consensus mechanism itself.

1-2. Privacy Constraints

Blockchains are structurally designed such that transactions and state transitions are publicly exposed. Records are not only revealed after being included in a block; even before execution, the propagation of transactions across the network can be externally observed. Although addresses are not directly tied to real-world identities, combining transaction patterns with external signals often allows inference of ownership or behavior. In practice, what blockchains provide is not true privacy, but pseudonymity.

Such a design creates challenges in services where information asymmetry directly translates into unfair outcomes, such as gaming and trading. In games, exposure of information like position, items, or attributes can undermine both strategy and fairness. In trading, visibility into order size, positions, or execution timing can lead to adverse execution conditions. On blockchains, these data points can be observed in near real time at the network level; observability itself introduces the possibility of intervention.

MEV (Maximal Extractable Value) illustrates this dynamic. Transactions visible in the mempool can be analyzed and reordered, allowing participants to insert themselves into execution flows or act ahead of price-impacting events to extract economic value. The more critical real-time interaction becomes, the more pronounced these vulnerabilities are. Environments such as private auctions, payments, settlements, and institutional workflows require execution conditions where counterparties, amounts, and transaction details remain hidden by design. Public blockchains, however, are fundamentally misaligned with such requirements.

Privacy-preserving approaches do exist. Technologies such as zero-knowledge proofs and Fully Homomorphic Encryption (FHE) enable verifiable computation without exposing underlying data. However, these approaches introduce additional overhead in both verification and data processing, making it difficult to maintain stable millisecond-level responsiveness required by real-time applications. As a result, blockchains built around transparent data and multi-party consensus face a structural limitation in delivering both real-time performance and application-level privacy simultaneously.

2. Ephemeral Rollups (ER): Extending Real-Time Execution on Solana

MagicBlock was introduced to address the structural limitation of public blockchains in simultaneously supporting real-time performance and privacy. The approach leverages Solana, where liquidity and users are already concentrated, while introducing Ephemeral Rollups (ER) to handle real-time and private execution in a separate layer.

2-1. Architecture: Solana as Settlement, ER as Execution

The core design of MagicBlock builds on Solana’s account model while isolating only the data accounts that require real-time updates into a separate execution environment. Solana separates program accounts, which handle execution, from data accounts, which store state. These data accounts are typically managed as PDAs (Program Derived Addresses). PDAs are generated and controlled by programs according to predefined rules and are primarily used to store application state such as player positions, game progress, and order status.

MagicBlock temporarily delegates control of these PDA-based data accounts to ER. Only the rapidly changing state is processed in real time, and the resulting state is later committed back to Solana. In practice, ER assumes temporary control over an application’s data accounts, processes state transitions in real time, and settles the result on Solana.

An ER session begins when a Solana application requiring real-time execution delegates ownership of its data accounts to an ER provisioner. The delegation includes parameters such as duration, commit interval, and target block time. Based on these conditions, the provisioner initiates an ER session and replicates the delegated accounts, along with any required execution accounts, using Solana’s latest state. From that point, all state updates for delegated accounts are processed exclusively within ER. This enables faster handling of repeated inputs and continuous state transitions within the execution environment.

State changes produced in ER are committed back to Solana at defined intervals, and control of the accounts returns to the original program once the session ends. During delegation, the accounts cannot be modified directly on Solana, and all state updates occur within ER. Read access remains available, allowing other Solana programs to continue referencing the accounts.

The architecture removes the need to migrate applications, liquidity, or users to a separate network, as is typical in Layer 2 designs. Existing users, assets, and programs on Solana remain unchanged, while only latency-sensitive components are selectively accelerated. Developers can retain Solana’s composability and asset base while optimizing specific segments such as gaming or trading, where response time is critical. MagicBlock therefore extends Solana’s capabilities by isolating and enhancing only the components that require real-time execution.

2-2. Execution Optimization for Real-Time Performance

ER operates by delegating Solana data accounts and processing them within a real-time execution environment. Execution speed alone, however, is not sufficient. Achieving a true real-time experience requires optimizing the full request lifecycle, including how user requests reach the ER environment, how ER sessions are initialized, and how requests are routed to the appropriate execution layer.

Dynamic Colocation

In real-time applications, the time required for a user request to reach the execution point is as critical as execution speed itself. Even if execution within ER is fast, latency increases when requests must travel long distances to reach a node. For example, round-trip latency between Tokyo and New York is typically around 150–200ms, which becomes a significant bottleneck in latency-sensitive applications. Physical proximity of the execution environment therefore plays a direct role in overall responsiveness.

MagicBlock addresses this through dynamic colocation. ER sessions are not tied to a fixed physical location; instead, execution is handled by ER nodes located close to the user. The system provides region-specific RPC endpoints across Asia, Europe, and the United States. Users can connect to a specific regional endpoint or be automatically routed to the nearest node via the Magic Router described below. This approach reduces the physical distance between the user and the execution environment, allowing ER performance to translate directly into user-perceived responsiveness.

Magic Router

Applications must determine whether a given request should be executed on Solana or routed to ER. Some requests modify delegated data accounts, while others interact with accounts that remain on Solana. Handling this logic at the application level would require managing both execution layers and routing decisions for each request.

The Magic Router resolves this by analyzing the accounts accessed by each transaction. When a transaction is submitted, the router identifies the accounts being read and written and determines the appropriate execution layer. Applications no longer need to manually separate execution paths or manage routing logic. As a result, ER-based real-time execution and Solana-based processing can be integrated into a single flow. From the user’s perspective, interaction remains unchanged, with no need to distinguish between ER and Solana environments.

JIT Cloning

ER sessions can be initialized in advance, but the state required for execution depends on incoming user requests. Preloading all potential accounts at session start would increase preparation overhead and introduce bottlenecks as the scope of required state expands. Real-time applications require not only fast execution after session initialization, but also the ability to attach relevant state and begin processing immediately when a request arrives.

JIT (Just-In-Time) Cloning addresses this by replicating the state of a delegated account only when it is first accessed. When a transaction interacts with a specific account, the latest state is fetched from Solana and copied into the ER environment. Only the accounts required for actual execution are cloned, rather than preloading all possible state at session initialization. For example, even if a session is already active, a data account is only replicated when a user first interacts with it. Subsequent inputs and state transitions are then processed continuously within ER based on that replicated state.

The key principle is the separation of session preparation and state preparation. Sessions are initialized in advance, while state is attached only when required. This eliminates the need for full upfront preparation, allowing users to enter an active session immediately and enabling ER to begin execution with minimal delay.

2-3. Consensus and Finality: Dynamic Fraud Proofs

State executed within ER is ultimately returned to Solana for commitment. The critical question is how these execution results are submitted, verified, and finalized on Solana. MagicBlock addresses this through optimistic execution combined with Dynamic Fraud Proofs. The structure is similar to an optimistic rollup: state changes are first submitted, followed by a challenge window during which disputes can be raised, and finalized if no issues are identified.

State processed in ER is committed back to Solana at predefined intervals, when required, or upon session termination. Each commit includes the state diff to be applied, metadata referencing the transaction execution records from the ER session, and delegation records specifying the conditions under which the state can be approved and finalized. The execution record reference enables reconstruction and verification of how the state transition was produced. As a result, not only the outcome but also the underlying execution trace and approval conditions are committed to Solana.

A challenge period follows each submission. During this phase, submitted state transitions are treated as valid by default, while active challengers re-verify them using the associated execution records and evidence. Valid state transitions are signed, while discrepancies trigger challenges and initiate a dispute resolution process. Once the challenge period ends, state transitions are finalized if a sufficient number of signatures has been collected. Unlike conventional optimistic rollups with fixed and extended challenge windows, MagicBlock uses a dynamic model where the challenge period starts short and extends only when necessary. Under normal conditions, finality can be achieved within approximately 500ms, enabling responsiveness suitable for real-time applications.

Fast finality is not based on optimistic assumptions alone. Economic incentives and penalties are embedded into the system to enforce correct behavior. Nodes operating ER sessions stake bonded assets and are subject to slashing if incorrect state transitions are submitted. Challengers are incentivized to detect invalid commits and initiate disputes. This structure assigns economic responsibility to both submitters and validators, ensuring that fast finality is supported by enforceable guarantees rather than assumption.

3. Private Ephemeral Rollups (PER): Enabling Confidential Execution

In a blockchain environment where everything is public, real-time execution alone does not resolve all challenges. There remain domains—such as payments, trading, and enterprise workflows—where the exposure of interaction details itself can be critical. To address this need for privacy, PER was introduced as a structure that extends ER by incorporating TEE (Trusted Execution Environment)-based confidentiality. A TEE is an isolated execution environment within the CPU that protects code and data from being directly accessed by the external operating system or third parties. PER processes sensitive state and interactions within this environment, and only reflects the necessary results externally, thereby preserving privacy. As a result, it enables a structure that maintains Solana’s real-time execution performance while preventing sensitive information from being exposed externally.

3-1. Execution Model: Why TEE

Among the available approaches to blockchain privacy, MagicBlock adopts TEE as the execution model. The objective is not simply confidentiality, but maintaining real-time performance while protecting sensitive state. Approaches such as zero-knowledge proofs, Fully Homomorphic Encryption (FHE), and MPC offer strong privacy guarantees, but introduce significant latency and computational overhead when applied to general-purpose execution. These constraints make it difficult to sustain the low-latency requirements of real-time applications. TEE operates within a protected execution region at the CPU level, allowing computation to proceed in a manner close to a standard execution environment while shielding state and memory from external access. This enables private execution with minimal performance degradation, which is critical in latency-sensitive environments.

This design aligns naturally with the ER architecture. ER isolates a subset of Solana state and executes it in real time. Integrating TEE into this model preserves the fast execution path while preventing both intermediate processes and resulting state from being externally visible. Developers can build real-time privacy applications using patterns similar to standard Solana programs, and users can interact through existing Solana accounts. No separate chain or alternative user environment is required, as private execution is introduced directly within the existing execution model.

3-2. Access Control: Permissioned State Visibility

PER introduces group-based access control through a program deployed on Solana, allowing visibility over account state to be defined at the group level. Access is structured around accounts, specifying which user groups are permitted to view which portions of state. In a payment service, for example, access groups can be segmented by roles such as operators, compliance officers, and auditors, with each group assigned a different level of visibility over the same account. Private state defined under this model is protected within the PER session, and remains inaccessible to unauthorized parties.

When a user connects to an application, the app submits a signed request to MagicBlock’s TEE endpoint to verify access eligibility and issue an access token. Once issued, the token allows the user to retrieve restricted private state without additional authentication steps. From the user’s perspective, the interaction remains similar to a standard application, while access control and private state retrieval are handled transparently in the background.

Private applications such as payments, trading, and institutional workflows, which are difficult to implement using only public state, can be built directly on Solana using this model. The architecture does not require developers to build a separate privacy network or operate dedicated infrastructure. Private real-time applications can be integrated directly into the existing Solana environment. By providing both real-time execution and private computation, MagicBlock reduces implementation overhead and allows developers to focus on product design, functionality, and business logic.

4. Applications: Where ER Delivers Value

4-1. Use Cases: Oracles, Private Payments, and Gaming

ER can appear abstract when viewed purely at the architectural level. Delegating state and executing it in a separate environment does not immediately convey its impact at the application layer. The following examples—focused on oracle, privacy, and gaming use cases—illustrate how ER translates into concrete functionality.

1) Oracle: MagicBlock x Pyth

The real-time oracle implemented by MagicBlock and Pyth reflects price data directly into ER-delegated data accounts, which applications read to update pricing. Instead of relying on delayed feeds from external servers, users access prices already reflected on-chain. Prices are updated approximately every 50ms, well below the commonly referenced 100ms threshold for real-time responsiveness. This enables applications such as exchanges, where price latency directly affects execution quality, to operate more naturally on-chain.

Price data is not maintained off-chain and then pushed into the application layer. It is written directly into ER-managed data accounts, which simplifies application design by removing the need for external infrastructure. The same model can be extended to assets such as real estate, tokenized equities, and commodities, where price discovery primarily occurs off-chain. This creates a pathway for DeFi applications—such as lending protocols, private credit, and structured products—to incorporate real-time pricing of off-chain assets.

2) Privacy: Private Payments

In the private payments model, users deposit assets on Solana and delegate the associated accounts to PER. Transfers are then processed privately within PER. For example, if Bob deposits 100 USDC, the balance can be transferred to Alice within a TEE-based execution environment without exposing transaction details. Alice can later undelegate the account and withdraw funds. Deposits, withdrawals, and final settlement remain on Solana, while intermediate balance changes and transaction details remain private and accessible only to authorized participants.

Privacy is not absolute, but selectively controlled. Access can be granted to relevant parties such as payment providers or operators responsible for KYC/KYB, based on account-level permissions. This enables on-chain asset management and settlement to coexist with restricted visibility over sensitive payment data. The model can extend to use cases such as payroll, corporate settlements, and partner payments, where both confidentiality and regulatory compliance are required. It also supports institutional workflows where selective disclosure is necessary for compliance or audit purposes.

3) Gaming: Solana-Generals

Solana-Generals is a real-time strategy game in which players move across a map and expand territory through competitive interaction. Built entirely on Solana and the MagicBlock development environment, the game operates fully on-chain without a centralized server. Both game state and execution logic are implemented as on-chain programs. Player actions are processed and reflected in state immediately, enabling real-time gameplay. Strategy games require continuous inputs and state transitions at short intervals, including movement, territory capture, and combat. Solana-Generals demonstrates that such interactions can be handled in real time within an on-chain execution model.

In traditional games, assets and progression data are tied to centralized servers. Ownership of in-game items and records is limited, and service termination results in loss of access. The persistence of user assets depends on the operator. By contrast, placing game logic and state transitions on-chain allows players to retain ownership of assets and history independently of the operator. Outcomes such as win conditions, probability, and state transitions become verifiable. This demonstrates that real-time games can be implemented without centralized infrastructure, using only Solana and ER.

4-2. Tokenomics: $BLOCK and Network Incentives

MagicBlock’s network token, $BLOCK, is scheduled for a TGE in Q2 2026. The token model integrates staking and slashing, protocol fees, and performance-based incentives into a unified system. ER node operators execute requested ER sessions and commit resulting state back to Solana. Participation requires staking $BLOCK as collateral, with rewards distributed based on successful operation. Failure to meet uptime or performance requirements, or submission of incorrect state updates, results in slashing of the staked collateral.

Protocol usage scales with delegation. As applications delegate more accounts to ER, both execution activity and associated fees from state commits and undelegation increase. Token emissions are partially allocated to applications that generate the highest levels of delegation. Fee generation is designed to feed into value capture. The protocol plans to introduce a $BLOCK buyback mechanism funded by these fees, linking increased network usage to token holder value.

5. Key Takeaways: The Next Phase of Blockchain Design

Public blockchains struggle to fully support real-time applications, while separating execution into Layer 2 environments leads to fragmentation of state and liquidity. MagicBlock addresses this by introducing ER as a dedicated real-time execution layer while keeping settlement on Solana. With the addition of PER, the architecture extends to support both real-time execution and privacy within a unified model. Since the launch of MagicNet in June 2025, MagicBlock has processed over 1 billion transactions across 18 live applications, alongside 250,000 delegations and 27,000 unique addresses. These metrics indicate that demand for real-time applications is already materializing at the application layer.

MagicBlock is currently in the ecosystem expansion phase. Growth depends on a feedback loop in which developers build applications, applications attract users, and user activity translates into network usage and fee generation. With TGE yet to occur, the pace at which this flywheel accelerates will depend on the alignment between token incentives and ecosystem expansion strategies.

MagicBlock demonstrates clear technical differentiation by presenting its solution as a working architecture rather than a conceptual framework. For blockchains to evolve beyond asset issuance and settlement into infrastructure for real-time applications—such as gaming, payments, finance, and social platforms—the most effective approach is to address both latency and privacy within a Layer 1 environment where liquidity and users are already concentrated. If adoption continues to expand across applications, ER-based real-time execution and fully on-chain, serverless architectures could establish a new baseline for blockchain design. In this context, MagicBlock remains a project to watch as its ecosystem continues to develop.