Abstract

Matrix introduces a next-generation execution layer that fully inherits the security guarantees, data availability, and finality of BNB Chain. All consensus-level assurances remain anchored to BNB itself, ensuring that Matrix adds no new trust assumptions to the ecosystem.

Without modifying any component of BNB Chain, Matrix increases the network’s effective transaction throughput by 3–5× through two core innovations: relocating execution from the base layer to a dedicated L2 environment, and encoding transactions using a significantly more efficient calldata format. This allows Matrix to expand computational capacity while maintaining complete compatibility with existing BNB tooling and infrastructure.

Built on an unstoppable execution model inspired by modern advancements in rollup architecture (e.g Facet), Matrix guarantees continuous liveness, censorship resistance, and high operational resilience under all conditions. Its immutable transaction ingress and trust-minimized execution pipeline ensure that Matrix cannot be halted, paused, or selectively filtered as long as BNB Chain continues to produce blocks.

Introduction

BNB Chain has evolved into one of the world’s most widely used smart-contract platforms, supporting millions of active users, global liquidity flows, and an increasingly diversified landscape of applications—ranging from DeFi protocols and high-frequency trading systems to SocialFi, gaming, and real-world commercial infrastructure. This rapid growth demonstrates the robustness of BNB Chain’s PoSA consensus and its ability to attract a broad developer base. However, it also exposes a fundamental limitation shared by all monolithic blockchains: execution capacity is finite.

The State of BNB Chain Today

BNB Chain provides strong security guarantees, predictable block intervals, and a thriving ecosystem of wallets, exchanges, and tooling. It is one of the few blockchains with both massive retail adoption and deep liquidity.

Yet, BNB Chain—like all base-layer chains—operates as a single global state machine. Every smart contract, application, and user competes for the same execution resources.

As the ecosystem continues to expand, this shared computational space is becoming increasingly constrained:

• High-throughput applications (bots, games, real-time markets) are pushing against current blockspace limits.

• Congestion events lead to sudden gas spikes and increased latency.

• Execution-heavy workloads cannot scale linearly without impacting unrelated applications.

• Complex multi-contract systems struggle to deliver predictable performance when the underlying state machine becomes saturated.

The consequence is clear: BNB Chain is reaching the upper bound of what a single-chain architecture can sustainably support.

The Growing Demand for Scalable Execution

Within the BNB ecosystem, execution demand is rising faster than base-layer capacity. Several trends contribute to this acceleration:

• On-chain trading automation: MEV bots, arbitrage systems, and perpetuals require stable blockspace.

• GameFi expansion: Real-time interactions and asset-heavy games generate enormous execution load.

• SocialFi platforms: High-activity social graphs create continuous write operations.

• AI-driven applications: Autonomous agents need persistent, low-latency execution.

• Emergence of L3 ecosystems: As new layers build on BNB, their underlying execution needs increase exponentially.

These categories place consistent pressure on the execution layer, often causing spikes that exceed the capacity of the base chain.

At the same time, BNB users increasingly expect:

• Lower latency

• More stable transaction fees

• Faster confirmation

• Higher throughput

• Predictable performance across diverse applications

  
  

These demands cannot be met by simply optimizing parameters or raising gas limits on the base chain.

Changes to BNB Chain’s core protocol affect every application and require global coordination—making them impractical or risky.

The BNB ecosystem requires a scalable execution environment that:

• does not modify BNB Chain,

• does not fragment liquidity,

• does not introduce new trust assumptions,

• and does not depend on centralized sequencers or admin control.

This is the role Matrix was designed to fulfill.

The Goal of Matrix

Matrix introduces a new execution model for BNB Chain—one that expands computational capacity without altering the base layer.

Its objectives are straightforward yet ambitious:

• Keep BNB Chain entirely unchanged. Matrix does not require consensus upgrades, opcode changes, or parameter adjustments.

• Extend BNB Chain throughput by 3–5× using more efficient calldata and L2 execution. BNB continues to serve as the universal source of ordering and data availability, while Matrix handles computation.

• Provide an execution layer that cannot be halted or censored. Matrix adopts an immutable-inbox architecture that guarantees transaction inclusion as long as BNB Chain continues to produce blocks.

• Eliminate trust in sequencers, committees, or upgradeable infrastructure. Matrix maintains a strictly deterministic relationship with the base chain, ensuring that no operator can pause, reorder, or suppress user activity.

• Offer developers a BNB-native scaling solution. DApps can deploy to Matrix with full EVM compatibility, benefiting from higher throughput without sacrificing security or interoperability.

  
  

In short: Matrix is designed to be the execution engine that scales BNB Chain for the next decade—without changing BNB itself.

By relocating computation to a higher-performance environment anchored to BNB Chain’s data availability layer, Matrix frees the base chain from execution bottlenecks while preserving its security guarantees.

The result is a fast, censorship-resistant, and fully trust-minimized execution network that supports everything from high-frequency DeFi to real-time gaming and autonomous AI systems.

Design Principles

Matrix’s core objective is to provide BNB with execution-layer scalability for the next decade without modifying BNB, without interrupting BNB, and without introducing new trust assumptions.

To achieve this, Matrix strictly follows three foundational principles:

Security Inheritance

Security = BNB Security

Matrix’s core objective is to provide execution scalability for the next decade—without modifying BNB, without interrupting BNB, and without adding any new trust assumptions. To achieve this, Matrix strictly follows the principle that all of its security must come directly from BNB Chain.

Matrix’s security model is built on three foundations:

• All user transaction calldata is stored in BNB blocks. No matter what happens externally, all data is permanently preserved in BNB’s data-availability layer.

• All state roots and cross-chain messages are finalized on BNB. Finality is guaranteed by BNB itself, not by Matrix or any L2 mechanism.

• BNB consensus and BNB full nodes can fully verify Matrix state. No new validator sets, governance committees, or privileged upgrade keys are introduced.

Therefore:

Matrix Security = BNB Security

In other words, as long as BNB remains secure, Matrix remains secure.

Zero Modification

Matrix does not—and cannot—require BNB Chain to change anything.

Matrix does not:

• ❌ fork the BNB mainnet

• ❌ modify BNB consensus (Tendermint, fast finality)

• ❌ modify BNB’s EVM, gas model, block format, or slot time

• ❌ require BNB to expand its DA capacity or upgrade any protocol parameters

• ❌ rely on new permissions, multisigs, committees, or operator authorities

BNB continues operating exactly as it does today.

Matrix’s role is simple and pure: To unlock BNB’s true execution potential without changing BNB in any way.

BNB acts as the finality layer and data-availability layer.

Matrix acts as the high-performance execution layer.

The two systems interact deterministically solely through the Inbox.

Unstoppable

Matrix is designed to be truly unstoppable—incapable of being paused, censored, or administratively altered.

Its unstoppable nature comes from four key design choices:

1. The Inbox is an uncontrolled EOA address—not a contract—so it has no upgrade path, no pause switch, and no administrative privileges.

2. Any user can freely submit transactions to the Inbox on BNB. No sequencer, no relayer, no whitelist, no privileged access.

3. Matrix has no center of control:

   no pause button

   no emergency committee

   no admin multisig

   no sequencer

   no coordination layer

   no mechanism to restrict withdrawals

4. No one can halt, censor, delay, or rewrite Matrix’s execution.

5. As long as BNB continues producing blocks, Matrix will continue running. Matrix depends only on three things from BNB:

   block production

   transaction inclusion

   data availability

Therefore: Matrix can only be stopped if BNB itself stops.

This makes Matrix a truly censorship-resistant, verifiable, and permanently available execution network.

Architecture Overview

Matrix is built on a simple architectural principle: BNB provides ordering, data availability, and finality; Matrix focuses solely on execution. BNB serves as the input layer, while Matrix serves as the execution layer—connected through a minimal, transparent, trustless interface.

Matrix does not rely on a centralized sequencer, administrative privileges, or upgradeable control points. All user inputs are committed directly to BNB, ordered by BNB consensus, and deterministically transformed into L2 state by Matrix nodes. The result is a verifiable, censorship-resistant, and unstoppable execution environment.

L1 Ordering & Forced Inclusion

Matrix runs without a sequencer. All user inputs are ordered entirely by BNB L1.

Mechanism:

• Users submit calldata directly to the Inbox (an uncontrolled EOA address)

• BNB consensus determines the ordering of these transactions

• Matrix derives its L2 input sequence according to BNB’s canonical ordering

Because the Inbox is a non-upgradeable, ownerless EOA:

• It cannot be paused or replaced

• It cannot be restricted or censored

• No administrator can alter or override it

As long as BNB accepts transactions, users always retain the ability to submit data to Matrix.

Thus: BNB acts as the Ordering Layer; Matrix acts as the Execution Layer. Matrix inherits liveness and censorship resistance directly from BNB.

Data Availability

Matrix uses BNB calldata as its sole data availability layer.

This approach provides:

• Permanent storage in BNB blocks

• Immutable, verifiable data

• No reliance on external DA networks (Celestia / EigenDA / Avail)

• No cross-layer synchronization

• No additional DA trust assumptions or infrastructure costs

BNB already supplies strong consistency, high availability, and a well-established ecosystem, enabling Matrix to concentrate complexity entirely in the execution layer.

State Derivation

Including Matrix-node and Matrix-geth architecture

Matrix’s execution layer deterministically derives L2 state from BNB’s ordered inputs.

This process is performed by two cooperating components:

Matrix-node (Data & Derivation Layer)

Matrix-node transforms BNB data into L2 execution batches:

• Synchronizes BNB blocks

• Extracts Inbox calldata

• Parses and validates inputs based on BNB’s ordering

• Aggregates data into L2 batches

• Submits batches to Matrix-geth via the Engine API

Matrix-node acts as the BNB → Matrix bridge, ensuring that inputs remain:

• Replayable

• Verifiable

• Auditable

• Fully ordered by BNB

Matrix-geth (Execution Layer)

Matrix-geth, fully compatible with the BNB EVM, is responsible for:

• Receiving execution batches from Matrix-node

• Running the EVM and computing state transitions

• Producing L2 blocks

• Storing state roots and historical state

• Responding to user RPC queries

It is the core execution engine of Matrix and maintains full consistency with the broader BNB tooling ecosystem.

Determinism & Verifiability

Because all inputs originate from BNB:

• Inputs cannot be forged

• Ordering cannot be manipulated

• State can be reconstructed from genesis

• Execution can be independently verified by any node

Therefore:

Matrix is a deterministic, trustless, fully replayable execution layer.

Any node can rebuild the entire chain solely from BNB blocks, without relying on any privileged participant.

Execution Model & Throughput

Matrix increases throughput not by accelerating the EVM, but by adopting a lightweight transaction model that significantly reduces L1 gas consumption.

In Matrix:

• A user action is encoded as a 0-BNB L1 transaction with compact calldata

• Complex logic executes inside Matrix

• L1 serves only as a minimal data recorder

Thus, for common use cases such as swaps: A Matrix block can process roughly four times as many effective transactions as a BNB L1 block.

Throughput improvements are driven by:

• Reduced per-transaction gas footprint

• Higher transaction density per block

• Minimal L1 resource usage

All while maintaining 100% EVM compatibility with BNB.

Finality & Exit

Matrix inherits finality completely from BNB:

• All inputs are permanently recorded on BNB

• State derivation is fully verifiable

• Exit requests are simply BNB transactions

As a result:

• No party can block or delay user exits

• No sequencer relay or admin authority is required

• No multisig or committee can freeze withdrawals

• Finalized BNB blocks imply finalized Matrix state

Users enjoy a censorship-resistant, trust-minimized exit path backed by BNB’s settlement guarantees.

Security

Matrix’s security is rooted in an extremely minimal trust model: no additional trust, no additional authority, and no additional centralized components. All ordering, data availability, and finality are provided by BNB Chain L1; all execution, derivation, and verification can be performed by any node. This chapter explains how Matrix remains secure under adversarial conditions.

Security Assumptions & Threat Model

Matrix’s only systemic assumption is:

• The BNB Chain consensus remains secure and final.

Beyond this, Matrix assumes:

• Nodes may be offline or malicious

• Network connectivity may be unreliable

• Users must be able to submit transactions without assistance

Matrix does not rely on:

• A sequencer

• Multisig committees or governance authorities

• Centralized bridges or administrators

• Upgradeable entry points or contract owners

→ No additional governance attack surface.

Ordering & Censorship Resistance

Matrix cannot be censored, reordered, or manipulated by any participant, because:

• Users submit calldata directly to the Inbox (a non-upgradeable, ownerless EOA)

• BNB Chain consensus determines transaction ordering

• Matrix has no ability to delay, reorder, or front-run any input

Thus, sequencer-based attacks common in other L2 systems—such as:

• Front-running

• Reordering

• Selective censorship

• Delayed inclusion

are all impossible in Matrix. As long as BNB Chain accepts transactions, Matrix cannot be censored or obstructed.

Liveness & Unstoppability

Conventional L2s face systemic liveness risks:

• Sequencer downtime

• Admin-key failures

• Upgrade-induced freezes

• Permissioned bridges blocking exits

Matrix eliminates these risks entirely:

• The Inbox is a fixed, non-upgradeable EOA with no owner or pause switch

• Users can always submit data directly to BNB Chain L1

• State derivation requires only continued BNB Chain L1 block production

Thus: If BNB Chain L1 continues producing blocks, Matrix cannot stop.

No sequencer, no administrators, no privileged logic → no single point of failure.

State Verifiability

Matrix’s state is fully replayable and verifiable, requiring no trust in any executor:

• Inputs are recorded on BNB Chain L1 and cannot be forged

• Ordering is determined by BNB Chain L1 and cannot be altered

• Execution is deterministic EVM computation and fully reproducible

• Any node can rebuild the entire Matrix chain from genesis

This ensures:

• No “alternative” or malicious state can be created

• No centralized snapshots can override the chain state

• No reliance on trusted executors—only on BNB Chain L1

User exits, state integrity, and developer trust are all secured by BNB Chain L1’s finality.

Ecosystem Compatibility

Matrix is fully compatible with the BNB Chain ecosystem.

Because Matrix extends BNB Chain at the execution layer—without modifying its EVM, RPC interface, or developer tooling—it supports all existing smart contracts, wallets, libraries, and development frameworks out of the box.

Wallet Compatibility

Matrix uses the same account model, signature standards, and transaction formats as BNB Chain L1.

All major wallets work natively without plug-ins or configuration:

• MetaMask

• Trust Wallet

• Binance Wallet

• Coin98

Users can interact with Matrix using the same wallets and the same keypairs they already use on BNB Chain.

Tooling & SDK Compatibility

Matrix maintains full compatibility with the BNB Chain EVM and RPC interface.

All major developer tools support Matrix without modification:

• web3.js / ethers.js / viem

• Foundry / Hardhat / Truffle / Remix

• OpenZeppelin tooling

• The Graph / Subgraph indexing frameworks

No custom tooling or proprietary SDKs are required.

Smart Contract Compatibility

All BNB Chain smart contracts are fully compatible with Matrix.

• Solidity / Vyper source code can be deployed without modification

• ABI interfaces, event formats, and contract behaviors remain identical

• Frontends require no additional adaptation

• Existing DApps can migrate with zero friction

For developers: Matrix behaves exactly like BNB Chain—just with significantly higher throughput and predictable performance.

Applications

Matrix opens the door to an entirely new class of applications that require high throughput, predictable execution, and strong resistance to censorship or downtime. Because Matrix inherits the security and data availability of BNB Chain while delivering significantly higher computational capacity, it serves as an ideal foundation for any system that demands continuous liveness.

Below is an expanded overview of use cases uniquely enabled and dramatically improved by Matrix:

High-Frequency Trading & On-Chain Market Infrastructure

Market-making bots, arbitrage systems, perpetual futures engines, prediction markets, and decentralized exchanges often require:

• millisecond-level responsiveness

• deterministic transaction ordering

• protection against sequencer manipulation

• stable execution fees during periods of volatility

Matrix’s immutable inbox and BNB-based ordering make it impossible for operators to reorder, censor, or delay trades.

This creates a fair, neutral environment for on-chain financial systems.

Examples:

• High-frequency AMM arbitrage

• On-chain limit orderbooks

• Collateralized derivatives engines

• Cross-venue arbitrage strategies

• Latency-sensitive clearing systems

Real-Time & High-Load Gaming

Modern on-chain games demand:

• fast finality

• predictable gas

• reliable tick updates

• uninterrupted server-like execution

Matrix provides a stable execution environment suitable for:

• large multiplayer worlds

• strategy games with thousands of simultaneous actors

• on-chain tournaments

• real-time interactive game loops

• asset-heavy NFT inventory systems

• fully on-chain physics or AI logic

The certainty that Matrix cannot be halted or censored is critical for game developers who need uninterrupted player experiences.

AI Agents & Autonomous Systems

AI agents require:

• continuous uptime

• task scheduling

• deterministic execution slots

• low-latency state transitions

• reliable data feeds

Matrix can host agent networks such as:

• autonomous trading agents

• AI-driven NFT games

• workflow automation bots

• decentralized AI training loops

• long-lived on-chain intelligence processes

Because Matrix is unstoppable, agents can execute 24/7 without operator interference—ideal for “always-on” computation.

Social Networks & Creator Platforms

On-chain social systems must ensure:

• user messages cannot be censored

• profiles and posts cannot be frozen

• creators retain full control over digital identity

• execution fees remain affordable at scale

Matrix enables:

• censorship-resistant social feeds

• tokenized communities

• creator monetization rails

• decentralized identity (DID) systems

• traceable supply-chain of social content

Applications can safely store user interactions without worrying about L2 administrators intervening.

DeFi Protocols Requiring Stable Blockspace

For DeFi infrastructure, liveness is a critical requirement. Matrix offers:

• predictable blockspace

• consistent gas pricing

• no sequencer pause risks

• no admin-controlled censorship

Ideal for:

• money markets

• collateralized lending

• yield aggregators

• stablecoin systems

• bonding curve markets

• synthetic asset protocols

DeFi platforms benefit from Matrix’s trust-minimized guarantees, making systemic risks significantly lower.

Payment Networks & Merchant Systems

Payment systems need:

• low latency

• predictable fees

• uninterrupted settlement

• trust-minimized execution

Matrix enables:

• retail payment networks

• microtransaction systems

• subscription-based services

• blockchain-powered invoicing

• decentralized merchant tools

Because Matrix cannot be halted, businesses can build applications without worrying about downtime.

Large-Scale Data Computation

Some applications need large volumes of computation rather than pure financial settlement:

• zk-proof aggregation

• batch data processing

• sensor data pipelines

• IoT networks

• privacy-preserving computation

Matrix offers the stable computational environment required to host these workloads while inheriting BNB Chain security.

RWA & Institutional Infrastructure

Institutions require predictability and legal certainty, which most app-chains fail to deliver because:

• bridges can be paused

• sequencers can be turned off

• upgrades can modify asset semantics

Matrix’s immutability model makes it uniquely suited for:

• real-world asset issuance

• institutional settlement rails

• regulated token marketplaces

• enterprise-grade workflow engines

Matrix offers the reliability enterprises require to build long-term systems.

Cross-Chain Routing & Messaging Hubs

Because Matrix is fully aligned with BNB Chain and cannot be halted, it is ideal as:

• a cross-chain settlement layer

• a messaging hub

• a bridge aggregator backend

• a multi-chain coordination network

Applications can rely on Matrix for routing messages between chains with stronger liveness guarantees than typical app-chains.

Infrastructure-Level Applications

Matrix’s unstoppable nature makes it well suited to serve as the backbone for:

• decentralized RPC networks

• data availability committees

• oracles

• indexers

• verifiable compute platforms

• MEV protection systems

Infrastructure providers benefit massively from the predictable execution model and guaranteed uptime.

Gas Model

Matrix uses an independent execution-layer gas that powers computation and state transitions on L2. This gas has no economic value, no supply limits, and no role in any economic model—it exists purely as technical fuel.

Gas is generated and consumed entirely within the L2 execution environment. Users do not need to bridge gas tokens from L1, greatly reducing reliance on cross-chain bridges and eliminating the operational and security risks they introduce.

This lightweight gas design ensures:

• Stable and predictable execution costs

• No exposure to market volatility

• No speculation or accumulation dynamics

• A simpler, safer user experience

Matrix provides a reliable, always-available execution layer without requiring users to pre-fund separate gas assets.

Conclusion

Matrix is designed with a long-term perspective: a vision of transforming BNB Chain into a resilient and high-performance settlement layer capable of supporting the next wave of global-scale on-chain applications. Rather than altering the underlying blockchain, Matrix amplifies its strengths—leveraging BNB Chain’s proven consensus, reliability, and data availability as the immutable backbone of a new execution economy.

By anchoring itself entirely to BNB Chain, Matrix achieves properties that typical L2s and app-chains cannot guarantee. It cannot be halted by a committee, modified through governance intervention, or manipulated by privileged operators. Its execution model is directly ordered by BNB Chain, removing the need for trust in sequencers, administrators, or upgradeable smart contracts. If a transaction is recorded on BNB Chain, it becomes part of Matrix—unconditionally.

This architecture enables Matrix to provide continuous operation under all circumstances. Whether the network is facing market volatility, coordinated attacks, sudden usage spikes, or infrastructure failures, Matrix continues to process transactions as long as BNB Chain produces blocks. This level of liveness and predictability is critical for the next generation of DeFi systems, AI agents, payment rails, real-time games, and institution-grade applications that cannot tolerate downtime or censorship.

At the same time, Matrix significantly increases the computational bandwidth available to the ecosystem. Through batching, compression, and execution offloading, Matrix expands effective throughput by multiple times, without fragmenting liquidity or requiring protocol-level changes. The result is a scalable execution network that operates in harmony with the base chain—extending its capabilities rather than competing with them.

In this model:

BNB Chain remains the settlement and security anchor. Matrix becomes the high-speed execution environment.

Together, they create a dual-layer architecture that blends trust minimization with performance and ensures that the ecosystem can evolve without structural compromise. This is not simply a performance upgrade; it is a new foundation for sustainable growth across the entire BNB Chain landscape.

Matrix represents a shift in how scaling is approached:

not through trusted operators, not through privileged committees, and not through mechanisms that can be turned off—but through engineering principles that prioritize permanence, neutrality, and openness.

As more applications demand higher throughput, stable fees, and unstoppable infrastructure, Matrix positions the BNB Chain ecosystem to meet these requirements head-on. It lays the groundwork for a future where large-scale computation, AI-driven systems, global payments, and institutional-grade networks can operate with full confidence in their execution layer.

Matrix is a step toward a broader future: a future where BNB Chain supports millions of daily active users, thousands of industrial-grade applications, and a thriving decentralized economy—all secured by the same base layer and powered by an unstoppable execution network.