Ethereum's Layer 2 (L2) scaling solutions are undergoing a fundamental architectural shift that could reshape how developers build blockchain applications. Two competing design philosophies, known as "based" and "native" rollups, are emerging as the primary paths forward, each solving different problems in the L2 stack. Based rollups, which delegate transaction ordering to Ethereum's main chain, are already live in production. Native rollups, which would shift execution verification to Ethereum itself, remain in research and prototype phases as of August 2026.

The distinction matters because these architectures change everything about how a Layer 2 network operates: who controls transaction ordering, how resistant the network is to censorship, how fast confirmations happen, and who maintains the critical infrastructure. For teams planning an Ethereum L2 or deciding whether to build their own blockchain, understanding these trade-offs is no longer optional.

What's the Difference Between Based and Native Rollups?

The simplest way to understand the distinction is to ask two separate questions: who decides the order of transactions, and who verifies that the transactions executed correctly ? Based rollups answer the first question; native rollups answer the second.

A based rollup lets the next Ethereum proposer, working with Ethereum's existing builder pipeline, permissionlessly include the next L2 block inside an L1 block. The rollup still executes transactions offchain and posts data or commitments to Ethereum. What changes is the authority that decides order and inclusion. In contrast, a native rollup aims to stop every L2 team from maintaining its own critical EVM (Ethereum Virtual Machine) verification stack. Ethereum would verify that the L2 block follows the same execution program Ethereum recognizes.

Importantly, these are not competing categories. One rollup can be both based and native simultaneously. The choice depends on what problems a team prioritizes and what trade-offs it can accept.

How Do Based Rollups Work in Practice?

Based sequencing is live as of August 2026, with evolving preconfirmation stacks already in production. The clearest reference point is Taiko, which describes a type-1 based rollup with whitelisted mainnet preconfirmations and a path toward decentralized, sub-second preconfirmations.

When a based rollup delegates transaction ordering to Ethereum, several consequences ripple through the system. Users gain liveness tied directly to Ethereum itself; a separate sequencer cannot halt the chain by disappearing. Censorship resistance improves because ordering is not controlled by one rollup operator. The sequencer trust surface shrinks because teams can remove a dedicated consensus network, token, and escape-hatch path from the critical flow. Some MEV (maximal extractable value) flows to Ethereum rather than to a private L2 sequencer, creating economic alignment with the main chain.

However, based sequencing introduces new challenges. Instant confirmations are no longer trivial; users do not want to wait for an L1 slot, so production designs add preconfirmers that promise inclusion before final L1 settlement. Sequencing policy becomes less flexible. First-come-first-served ordering, private order flow, and custom auctions are harder to guarantee. MEV revenue changes, meaning a business model built on exclusive sequencing cannot be copied unchanged. Operations do not disappear; teams still need block building, preconfirmation monitoring, proving, data publication, RPCs, indexers, and incident response.

What About Native Rollups and Ethereum Verification?

Native rollups remain in research and prototype phases, not part of any scheduled Ethereum hard fork as of August 2026. The proposal has changed materially over time. Draft EIP-8079 describes an EXECUTE precompile and leaves major areas marked TBD (to be determined). The newer native proof verification proposal moves toward proof-carrying transactions and program-agnostic verification in Ethereum's consensus infrastructure.

The appeal of native verification is clear: it would reduce the burden on individual L2 teams. A rollup could still customize sequencing, fees, gas token, governance, and messaging around that shared execution rule. However, L2BEAT's current native-rollup research tracker is explicit: the work is not part of a scheduled Ethereum hard fork, EIP-8079 is still a draft, and proof-carrying transactions remain a research proposal. A 2026 architecture plan can preserve a migration path to native verification, but it cannot honestly put native Ethereum verification on a committed launch checklist.

How Should Teams Choose Between These Architectures?

The cleanest mental model is a two-axis matrix rather than a winner-takes-all comparison. One axis represents sequencing (dedicated versus based); the other represents verification (custom versus native). Most production rollups today occupy the dedicated-sequencing, custom-verification quadrant: fast and controllable, with bespoke verifier governance. Future designs will populate other quadrants as native verification matures.

This framework prevents a common procurement mistake. A vendor saying "native" has not answered who controls transaction order. A vendor saying "based" has not answered who can upgrade the verifier or bridge. Teams must ask both questions before committing to an architecture.

• Choose based sequencing when: Censorship resistance, permissionless inclusion, and credible neutrality are central to the product, and when the team can test the preconfirmation path under failure conditions.
• Choose a dedicated sequencer when: Sub-second user experience, deterministic ordering, private transactions, or control of sequencing revenue are launch-critical. Document the censorship and liveness escape path clearly.
• Design for native compatibility when: EVM equivalence, a long-lived chain, and the option to shed bespoke verifier governance later are priorities. Keep custom execution extensions behind explicit boundaries.
• Do not launch your own L2 when: A public L2 already gives you the cost, throughput, distribution, and compliance properties you need. A chain creates a permanent operations product beside your actual product.

The decision should match the product's actual needs, not the most Ethereum-aligned label. A team building a DeFi protocol might prioritize based sequencing for censorship resistance. A gaming studio might choose a dedicated sequencer for deterministic ordering and sub-second latency. An enterprise application might design for native compatibility to reduce long-term governance risk.

What Questions Should Teams Ask Rollup Providers?

Before selecting a Layer 2 infrastructure provider or committing to an architecture, teams should ask critical questions about both sequencing and verification. Understanding these details prevents costly mistakes later in development.

• Sequencing control: Who can include, reorder, or censor a transaction, and what happens when that component is offline? Is there a fallback mechanism?
• Verification ownership: Who owns the verifier contract, and who can upgrade it? What governance process controls changes to execution rules?
• Escape paths: If the sequencer fails or acts maliciously, what is the documented path for users to exit or recover assets?
• Upgrade authority: Who controls protocol upgrades, and how decentralized is that process? Can a small group unilaterally change critical parameters?
• Data availability: Where is transaction data posted, and who can access it? Is there a fallback if the primary data availability layer fails?

These questions apply whether a team is evaluating a rollup-as-a-service provider, planning an appchain, or deciding whether its product needs its own Layer 2. The architecture changes censorship risk, confirmation latency, MEV revenue, upgrade ownership, and the systems the team must operate. It does not automatically create product demand, so the choice must be grounded in real product requirements, not architectural fashion.

As Ethereum's scaling roadmap continues to identify centralized sequencers as a censorship risk, based rollups and native verification represent the ecosystem's attempt to solve that problem at different layers of the stack. Teams that understand both architectures and their trade-offs will be better positioned to build resilient, long-lived applications on Ethereum's Layer 2 networks.