Native vs Based Rollups: Architecture and Verification Differences

Both terms get marketed as if they compete. They do not. They occupy separate axes of the L2 stack. Confusing them creates a measurable procurement error.

Sequencing versus verification

Based rollups delegate transaction ordering to the Ethereum L1 proposer. The next proposer, working with the existing builder pipeline, permissionlessly includes the next L2 block inside an L1 block. Execution stays offchain. Data and commitments still post to Ethereum. What changes is the authority over order and inclusion. The original based-rollup definition inherits Ethereum's liveness and decentralization. That is the direct countermeasure to centralized sequencer censorship risk.

Native rollups target a different invariant. They aim to remove the requirement that every L2 team maintain its own critical EVM verification stack. Ethereum itself would verify that the L2 block follows the same execution program Ethereum recognizes. The rollup retains control over sequencing, fees, gas token, governance, and messaging around that shared rule.

The cleanest mental model is two questions. Who orders transactions. Who verifies execution. Not a winner-takes-all matrix.

Live state versus research state

Based sequencing runs in production. Taiko's official 2025 to 2026 roadmap documents a type-1 based rollup, whitelisted mainnet preconfirmations, and a path toward decentralized sub-second preconfirmations. Evidence the architecture ships in production. Not proof every preconfirmation design has reached equal maturity.

Native rollups remain unscheduled protocol research. Draft EIP-8079 describes an EXECUTE precompile. Major sections sit marked TBD. The newer proof-carrying transactions proposal moves toward program-agnostic verification inside Ethereum's consensus infrastructure. L2BEAT's tracker is explicit on the status: native rollup work is not part of a scheduled hard fork. EIP-8079 is still a draft. Proof-carrying transactions remain a research proposal.

A 2026 architecture plan can preserve a migration path. It cannot honestly place native Ethereum verification on a committed launch checklist. State that explicitly in any vendor conversation.

What to verify before signing

Ask who controls sequencing. Ask who owns the upgrade key for the verifier and the bridge. A vendor claiming "native" has answered neither question. A vendor claiming "based" has answered neither. Labels do not substitute for operating model specifics.

Verification is a broader industry pattern now. The same architectural instinct shows up in Google's parental age verification for Play Store apps — pushing trust decisions up to the platform layer rather than every individual app. Different domain. Same logic.

If the actual decision is public EVM L2 versus another ecosystem, start with gas-cost and chain-selection data from real Web3 mandates. Architecture labels do not generate product demand. Operating model does.