Introduction

What is BNB-Ordered Sequencing?

BNB-Ordered Sequencing means that Matrix’s transaction ordering is determined entirely by BNB Chain L1, with no intermediaries or coordination layers. Users send calldata to an uncontrolled Inbox EOA, and BNB includes these transactions into blocks according to its canonical rules. Matrix blocks then mirror the exact ordering that BNB finalizes.

How it Works

1. User Submits Transaction

Users send BNB L1 transactions containing Matrix transaction data to:

Copy

0x00000000000000000000000000000000000bbbb1

2. L1 Ordering

BNB validators include Matrix transactions in L1 blocks just like any other BNB transaction. Once a calldata transaction is accepted by BNB, its position in the canonical block is final—Matrix cannot reorder, delay, or filter it.

Matrix inherits the exact censorship resistance properties of BNB Chain. If a transaction appears in a BNB block, it will appear in the corresponding Matrix block.

3. Matrix Block Construction

Matrix nodes observe every BNB block and derive Matrix blocks deterministically from L1 data.

Matrix-node performs:

• Monitoring every BNB block

• Extracting all transactions whose to equals the Inbox address

• Building Matrix L2 blocks in the same relative order as they appear on BNB

• Producing Matrix blocks on Matrix’s own cadence (e.g., filler blocks if no new Inbox txs exist)

This means Matrix blocks are a faithful reflection of BNB’s ordering, with zero opportunity for reordering, prioritization, or manipulation.

4. Guaranteed Inclusion

If your calldata transaction is included in BNB block N, it is guaranteed to appear in the Matrix block corresponding to that same position in Matrix’s derivation pipeline.

No operator, sequencer, relayer, or admin has the ability to:

• block inclusion

• reorder transactions

• override L1 ordering

• remove a transaction after BNB finalizes it

Matrix’s inclusion guarantee is purely inherited from BNB.

Transaction Ordering Rules

Within each Matrix block:

1. Transactions follow the exact order they appeared in the corresponding BNB block.

2. If BNB block X contains Inbox transactions at positions 11, 52, and 133, Matrix will include them in that same sequence in the derived Matrix block.

3. Matrix-node does not reorder, accelerate, prioritize, or discriminate.

4. No MEV can be extracted by Matrix-layer components, because all ordering is resolved on BNB.

Key Properties:

• Deterministic Anyone reading BNB Chain can derive the same Matrix block—no ambiguity, no trust required.

• Immutable Ordering The Inbox is an EOA, not a contract—its behavior cannot be upgraded, modified, or paused.

• Permissionless Anyone who can send a transaction to BNB can send a transaction into Matrix. No whitelisting or privileged roles.

Why an EOA Instead of a Smart Contract?

Traditional rollups often rely on smart-contract inboxes, allowing upgrades that can alter how transactions enter the system—such as changing gas metering, disabling forced inclusion, or introducing censorship logic.

Matrix uses an uncontrolled EOA Inbox with no known private key:

• Cannot be upgraded

• Cannot change behavior

• Cannot embed logic

• Cannot discriminate between users or transaction types

• Will accept calldata for as long as BNB produces blocks

This ensures the transaction ingress path is permanently open and cannot be administratively modified.

Trade-offs

By inheriting BNB’s ordering directly:

Costs:

• Higher submission cost: users pay full BNB L1 transaction fees

• L1 latency dependency: Matrix inclusion depends on BNB block times

• No soft-confirmation layer: transactions must wait for L1 inclusion for ordering guarantees

In exchange, Matrix gains:

• True unstoppable execution If BNB continues running, Matrix cannot be paused or censored.

• No sequencer MEV All MEV opportunities naturally accrue to BNB validators, not to Matrix operators.

• Perfect L1→L2 alignment Matrix’s execution reflects BNB’s ordering exactly, enabling fully deterministic replay and trustless verification.