The end goal: Unified margin across Ethereum.

CDP Is All You Need

Collateralized Debt Position (CDP) underpins the largest lending and decentralized stablecoin protocols in DeFi. In a CDP, every debt position is overcollateralized by other assets.

Compared with undercollateralized or unbacked lending in the real world (think credit cards), CDPs are clearly less capital-efficient: you must own more to borrow less. That’s why efforts to bring undercollateralized lending onchain never stops, although Wildcat appears to be the only survivor so far.

The untold truth is, undercollateralized lending is never truly undercollateralized. Instead, it’s collateralized by intangible assets such as reputation, legally enforceable contracts, and social standing. Defaulting typically disqualifies you from future borrowing or limits what you can do in society, which is just another form of liquidation where your reputation or creditworthiness is consumed.

Trying to replicate undercollateralized lending onchain isn’t making the best use of blockchain, where technically everything can be tokenized and freely traded in one composable domain. Why not use everything as collateral? After all, this is how undercollateralized lending actually works in real life, and blockchain has the ability to trustlessly tokenize the intangible.

This direction has been explored in DeFi from two angles: enabling more assets as collateral, and looping/leveraged farming. Protocols pioneered by Rari Capital allow permissionless money markets, so that any asset can be used as collateral to borrow as long as there are willing lenders. Unsurprisingly, Rari Capital became the rookie camp for hackers and had been exploited on a monthly basis.

Looping/leveraged farming, on the other hand, has become mainstream with more yield-bearing assets emerging. Borrow against asset A, use the loan to buy more A, repeat the process, and you gain leveraged exposure to A and its yield. Some leveraged-farming protocols market themselves as “undercollateralized” because you can borrow more than your initial deposit, which mainly illustrates that undercollateralized lending is simply a natural use case of CDP.

Protocols like Morpho, Euler and Gearbox are trying to combine both: they enable as many collateral assets as possible by isolating markets thus risks and natively offer looping function, moving closer to permissionless spot leverage/margin trading.

CDP + Based Orderbook = UMBO

Based orderbook introduces another asset type to Ethereum: perp positions. Orderbook-based perp DEXes aren’t new, but almost all run in their own execution environment (L1 or L2) and are siloed from existing ecosystems. By contrast, the composability of the based orderbook lets its perp positions be read and altered from Ethereum L1 in real time, making them feel more like native Ethereum assets.

In the Based Orderbook design there’s already an L1 CDP lending protocol that lets L1 users trade on the based orderbook with L1 collateral. So what if we also enable perp positions as collateral? For example, a user could deposit wstETH into the lending protocol, borrow USDC and deposit it to the based orderbook as margin to open a short ETH perp, then “deposit” that short position back into the lending protocol. After this flow, their lending protocol health factor improves, and they can borrow more USDC if desired.

The outcome of perp-as-collateral is similar to the portfolio margin mode available at CEXs, where a user’s whole portfolio (spot + derivatives) is assessed together and margin is set by portfolio risk. With CDP + based orderbook, users can use their entire L1 portfolio (including DeFi positions) to borrow stablecoin for perp trading, and let perps back the L1 borrowing. If the L1 portfolio falls but the user has unrealized perp gains, those gains can prevent a liquidation that would have occurred without perp-as-collateral. This unifies margin across L1 and L2, which upgrades the based orderbook into UMBO (Unified Margin Based Orderbook).

UMBO unlocks use cases that aren’t possible with existing designs:

• Any asset as collateral: Users can deposit preferred L1 assets into UMBO, borrow USDC and trade. Unified margin allows perp positions to count as collateral, so users don’t lose capital efficiency to overcollateralized borrowing.

• Leveraged basis trading: Delta-neutral basis trading positions (spot + short perp) can be used as collateral to borrow more and increase leverage on UMBO. Normally, to construct a $10,000 delta-neutral position to farm funding, one needs:

      With UMBO, the capital requirement can be reduced by 11x:

• Boosted leverage: Traders can effectively exceed a perp DEX’s leverage cap (e.g., 25x) by borrowing against perp positions or idle L1 assets to get extra margin and reach higher effective leverage on their original input (e.g., 30x).

Crucially, UMBO doesn’t require changes by perp DEX — the latter needs not to be aware of the existence of a lending protocol. That means UMBO can work with other non-native perp DEXs seamlessly as long as they are also synchronously composable with Ethereum L1 (and they can use LingLong stack to do so).

Make Ethereum the Prime Broker

Ethereum is often described as the settlement layer and balance sheet, with rollups hosting applications. We haven’t fully realized that vision, and one shortcoming is clear: when assets become isolated inside rollups or apps (effectively “locked” on L1), we give up composability, one of blockchain’s biggest strengths.

UMBO addresses this. It makes rollup assets accessible to L1 logic and provides a margin engine that accepts assets across L1 and rollups, preserving cross-domain composability and maximizing capital efficiency. In effect, Ethereum becomes the prime broker, extending credit to users whose portfolios span L1 and rollups.

Practically, UMBO spins up an smart contract account for each user so they can interact with rollup apps (for example, a perp DEX) while enjoying portfolio margin that includes their L1 deposits. Using Ethereum with UMBO will feel different, and better.

\      

It was further specified by jaehaerys into a concrete blueprint for achieving “just-in-time bridging” or “bridgeless collateralization” between L1 and L2. The idea is expanded by Andrew into the broader ambition of treating Ethereum as the balance sheet and L2s as the execution surface.

On the surface the concept is straightforward, but at its core it’s multi-faceted, with many nuances still unexplored. In this article we will discuss what makes it attractive, what the pitfalls are, and how we might make it even more powerful.

Bridgeless Collateralization

In layman’s terms, Tarun and Jaehaerys’s idea is an L2 perp DEX that lets users use a wide range of L1 assets as collateral without needing a separate bridging transaction to move those assets onto the L2.

Note that there are two key factors in this idea:

1. No-bridge UX. Users post L1 assets directly as collateral to back trades on the L2, as if they’re on the L2. There’s still bridging happening under the hood — it’s just hidden from users.

2. Yield-bearing collateral. Earning on collateral while trading perps is attractive. Ideally the accepted collateral set should be large and include yield-bearing assets to maximize users’ yield opportunities.

Less About Bridge

The mechanism behind bridgeless collateralization described by jaehaerys is shown below.

The mechanism consists of four distinct steps:

1. Lock on L1: A user deposits assets—for example, ETH, stETH, or even DeFi vault positions like those from Morpho—into a purpose-built Escrow smart contract on Ethereum.

2. Credit on L2: After the deposit transaction achieves finality on L1, a ZK-proof of this lock event is generated. The L2 application (e.g., Lighter) verifies this proof and authorizes margin for the user's account.

3. Liquidation on L2: If a user's position violates the maintenance margin threshold, the L2's internal logic executes a liquidation and generates a new, outbound cryptographic proof: a proof-of-liquidation.

4. Settlement on L1: This proof-of-liquidation is submitted to the Escrow contract back on L1. Upon verification, it executes a forced ownership transfer, moving the user's locked collateral to a liquidator or an insurance fund.

It’s easy to see that this process isn’t fundamentally different from classical L1<>L2 native bridging: both lock L1 assets in a smart contract, both create a mapping/credit of those locked assets on L2, and both restrict L1 withdrawals based on L2 state.

The difference is speed. Bridgeless collateralization requires fast bridging, which can be achieved with proof systems (e.g., ZK proofs), custom verification logic, or simply looser trust assumptions. There’s nothing stopping a CEX from building bridgeless collateralization today: it could read users’ L1 locks off-chain, credit accounts with margin in real time, and have the L1 escrow contract accept state updates from the CEX to process withdrawals and liquidations. That model is obviously very risky because it fully depends on oracle robustness and lacks verifiable proofs, but it is technically feasible.

More About Collateral

The real unlock by bridgeless collateralization is yield-bearing-L1-native collateral assets. Ethereum L1 still has the highest TVL, most matured DeFi ecosystem, and usually the highest DeFi yields (in the form of LP tokens, Pendle PTs, tokenized trading strategies, etc.). Letting those assets serve directly as perp collateral would open new yield streams for traders, dramatically improve capital efficiency, and enable cross-margin DeFi + perp portfolios that weren’t previously possible.

So what’s stopping perp DEXs from doing this? After all, it is already possible with classical bridging. Having multiple collateral assets is also common under CEXs’ portfolio margin mode. Looking at perp DEXs that already accept multiple collaterals (for example, Drift) highlights the practical problems, and why they’re much harder to solve in a cross-chain setup:

• PnL settlement forces onchain collateral handling USD-margined perps settle PnL in stablecoins. If margin is held in exotic assets, the platform must be able to convert those assets into USDC (or equivalent) when paying out PnL. That conversion usually happens during liquidations; without it, winners would receive a messy basket of tokens instead of a stable payout.

• Illiquidity and volatility can create bad debt If a collateral can’t be swapped into enough stablecoins quickly, due to volatile prices and/or shallow liquidity, the exchange risks uncovered losses. To manage risk exposure, exchanges apply collateral ratios/discounts and cap how much margin any single asset can provide.

• Liquidations must be fast, but L1 is slow L2 exchanges progress orders way faster than L1 can move assets due to block time difference. In bridgeless designs, the handling of collateral assets (which live on L1) will always be significantly slower than the L2 orderbook state progression, increasing the likelihood that adverse price moves eat through safety buffers before liquidations complete.

• You need many fast oracles To correctly measure a trader’s margin, you need a fast price feed for every collateral asset. That’s a heavier burden when the exchange (L2) advances in milliseconds while the collateral’s canonical price source (L1) update every 12s — from the exchange’s perspective, a trader’s margin can jump abruptly.

So there’s a third key factor in the idea of bridgeless collateralization: Don’t blow up.

You have to find a way to reconcile fast L2 trading with slow L1 liquidation and price update, when exotic collaterals themselves are already hard enough to handle.

Based Orderbook

Here we propose Based Orderbook: an integrated L1 & L2 design that enables bridgeless collateralization (and more) through maximally accelerated bridging and fully isolated risk for the orderbook. At its core is an onchain orderbook living as an Ethereum based rollup (the based orderbook itself), an L1 money market, and synchronous composability between the two.

The Fastest Bridge

We’re only discussing canonical/native bridging here. Third-party liquidity bridges can bypass limits by taking extra economic risk.

With Based Orderbook, L1<>L2 bridging completes within the same block as the initiating transaction. This is the theoretical speed limit, since nothing can outpace L1 block time.

• Deposit: the user locks assets in the L2 bridge contract on L1 and notifies the sequencer; the sequencer instantly produces an L2 batch crediting the deposit; both the deposit tx and the batch are submitted in the same L1 slot; the batch is valid only if the deposit executes, ensuring same-slot crediting without unbacked L2 balances.

• Withdrawal: the user initiates withdrawal on L2; the sequencer instantly produces a batch containing it; the batch is settled to L1; the L1 bridge contract verifies the proof and releases assets in the same slot; the release is valid only if the withdrawal settles.

For this to work, two requirements must be met:

1. Prove and settle L2 state within one L1 slot. While ZK real-time proving is advancing fast, TEEs still look more practical today.

2. Control ordering of L1 txs and L2 settlement. L1 deposit/withdrawal and L2 settlement must follow each other in the correct order in the same block. This is where basedness matters — unified L1<>L2 transaction ordering.

Unlike the original bridgeless collateral proposal, Based Orderbook doesn’t require extra proof generation or relays — the L1 bridge/inbox remains the source of truth, natively accessible to the based orderbook through settlement.

Risk Isolation

The perp DEX running on the Based Orderbook doesn’t need to natively support any collatrals other than stablecoin(s). Exotic assets are enabled instead by an L1 lending protocol.

Take PT sUSDE November 2025 (“PT” for simplicity) as an example. In the original bridgeless collateral design, the perp DEX must integrate PT liquidation logic on L1, set caps on PT-originated margin, pick a PT collateral ratio that balances safety and capital efficiency, and add/remove PT in the margin calculus.

With Based Orderbook, those responsibilities move to the L1 lending protocol: a user deposits PT, borrows USDC at, say, 85–90% LTV, then deposits the borrowed USDC to the based orderbook to trade. With same-slot bridging and account abstraction, borrow + deposit can be executed atomically in the same block. An automation bot can adjust the loan value and rebalance the perp collateral when price moves with atomic transaction bundles, making the UX very much like using PT directly as collateral to trade.

This isolates the perp DEX from PT price risk. If PT collapses, the lending protocol liquidates the borrower like any L1 loan, with the perp positions unaffected (the perp DEX need not be aware of the PT at all).

The lending protocol thus becomes the portfolio-margin risk engine. That adds borrowing cost for traders, but it can be offset by market-driven risk parameters (higher capital efficiency as long as the lenders are fine with it). This also greatly simplifies perp DEX integration with a wide range of yield-bearing L1 assets.

Synchronous Composability

Being a based rollup, the based orderbook offers more than fast bridging: It enables synchronous composability, or atomic dependency, between the orderbook and the L1. In practice that means you can build atomic cross-domain transaction bundles that behave as if both legs lived on the same chain, unlocking use cases beyond the original bridgeless collateralization idea.

• Atomic swap. The spot market on the based orderbook can be used for swaps on the L1. Say an L1 user wants to swap ETH into USDC. He can:

  1. Deposit ETH into the based orderbook.

  2. Trade ETH for USDC on the orderbook.

  3. Withdraw USDC back to the L1.

  All 3 steps can be bundled into an atomic batch (or even as a single transaction) and complete in one slot. If the trade (step 2) fails, e.g., due to exceeding the user’s slippage tolerance, the whole bundle reverts and the user’s ETH stays on L1 untouched.

  In short: the based orderbook can run at hardware speed while remaining natively accessible to L1 assets.

• Atomic portfolio rebalancing. Users can construct monolithic portfolios spanning the based orderbook and L1 lending. For example: deposit wstETH into the L1 lending protocol, borrow USDC, then open a leveraged short ETH perp on the based orderbook to form a delta-neutral position. When ETH price moves, rebalancing requires both an L1 leg (swap or borrow) and an L2 leg (perp trade) to avoid liquidation & maintain leverage. Synchronous composability lets both legs run atomically: if one fails, the whole operation reverts, thus eliminating the classic cross-domain “leg risk”.

Asset-App Unification

Ethereum will remain the primary asset issuance and settlement layer (in Andrew’s words, the balance sheet) because of its decentralization, neutrality, and security. But L1 will never be able to host the fastest, largest applications (think millisecond orderbooks) without sacrificing those properties. In practice, Ethereum assets are kind of stuck.

Based rollups offer a clean solution: they give Ethereum L1 assets direct access to high-performance applications without burdening L1 blockspace. Based Orderbook is the archetype: it lets L1 assets natively access an “onchain Binance” with minimal extra security assumptions.

Crucially, this also elevates L1 from a rollup settlement layer to a trade settlement layer that links Based Orderbooks and other based rollup apps. The result is a unified ledger that meaningfully improves capital efficiency across the Ethereum ecosystem.

This isn’t the end of the story. We can squeeze more efficiency out of the design. More in the next article. Hint: it’s about leverage, the other way round.

A Recap of Pre-Settlement

Pre-settlement is a commitment framework that enables Ethereum validators to delegate their based rollup sequencing rights to third parties. Its implementation, LingLong, functions as a PBS (Proposer-Builder Separation) platform for based rollups.

LingLong introduces a set of Restaked Services (RS)—networks composed of operators who offer credible commitments backed by restaked collateral.Two RS are central to the pre-settlement architecture:

• Restaked Validator Service (RVS), where validators are opeators. RVS forms the foundation of LingLong, allowing validators to delegate rights to other RS.

• Restaked Gateway Service (RGS), where gateways are operators. RGS receives delegation from RVS, and selects gateways to sequence based rollups.

Commitment-based Fault Attribution

LingLong supports two types of commitments:

1. Validator-to-RS commitments: For example, validators commit their based rollup sequencing rights to RGS through RVS.

2. Operator-to-User commitments: For example, gateways provide commitments to rollup users in the form of instant transaction confirmations.

The separation of commitments, combined with LingLong's agent-based fault attribution model, ensures fair fault attribution and risk isolation between validators and SPs. Penalties are imposed only on the party with direct operational control over a failure.

For example, if a gateway violates its commitment to rollup users by not settling the pre-confirmed transactions on the L1, then only the gateway will be penalized. The validator who delegates sequencing right to RGS (thereby indirectly to this gateway) will remain unaffected.

The validator will only be slashed when it violates its own commitments, e.g., including a rollup batch that's not from the gateway it has delegated to.

Why Do We Need Proofs

To ensure commitments are credible, faulty issuers must be subject to slashing. Fair enforcement requires objective proof of whether a commitment has been properly fulfilled. This allows slashing decisions to be made in a trustless and credibly neutral way—ideally, through smart contracts.

The Case of Using SP1

Key properties we prioritize when designing the proof system for LingLong:

• Cost-efficiency: Proofs should be inexpensive to generate and verify, with minimal onchain overhead.

• Performance: Proof generation and verification should be fast, even in low-bandwidth environments like Ethereum L1.

• Programmability: Since LingLong supports arbitrary commitments, the proof system must be capable of proving and verifying arbitrary logic.

Succinct's SP1 is a compelling choice for LingLong. As a zkVM, it leverages zero-knowledge proofs to shift computation off-chain while keeping on-chain verification costs minimal. Its ability to verify the execution of arbitrary Rust programs makes it especially well-suited for LingLong, particularly as the platform evolves beyond based sequencing to support broader use cases. For these reasons, we’ve chosen to build LingLong’s fraud-proof system using SP1.

Example of Inclusion Proof

Here we show an example of using SP1 to generate transaction inclusion proof and use it in LingLong. While this example doesn’t involve based sequencing, it demonstrates a transaction inclusion commitment on L1—also known as a "preconfirmation." This represents a SP–to–User commitment.

Process:

1. A gateway issues a preconfirmation to a user's transaction

2. A challenger starts the dispute process by calling the fraud proof smart contracts, indicating that the gateway fails to include the user's transaction in the target slot, thus a failed preconfirmation

3. Anyone can respond by generating a zero-knowledge inclusion proof using SP1, which, if valid, overturns the dispute.

4. The fraud-proof smart contracts evaluate the challenge based on three possible outcomes:

   1. A valid proof confirming the transaction's inclusion is submitted: the challenger's bond is slashed, and the gateway remains unaffected.

   2. An invalid proof is submitted: the gateway is slashed after the challenge window expires.

   3. No proof is submitted before the challenge window expires: the gateway is slashed.

Towards a Decentralized Arbitrary Proof System

We envision a growing number of Restaked Services on LingLong as new use cases for validator delegation continue to emerge. Our goal is to keep this process permissionless, enabling validators to benefit from ongoing innovation across the Ethereum ecosystem. As the variety of commitments expands, so does the need for diverse types of proofs—an area where SP1 proves especially valuable. We're also testing integration with Succinct’s prover network to make proof generation more cost-effective and accessible, ultimately enhancing the robustness of the entire proof system.

Want to get more hands-on with pre-settlement?

Join our working group, where node operators, rollups, restakers, and other stakeholders are collaborating to advance the solution!

Ethereum's rollup-centric approach has built a $30B L2 ecosystem, yet concerns over fragmentation and a diminished L1 value proposition grow.

Scaling the L1 is a much needed short term solution. However, in the long term, expecting a single virtual machine on every node to support global-scale finance and applications is unrealistic without compromising decentralization. We still need rollups.

The Core Problem

How to scale Ethereum via rollups, while preserving decentralization, sustaining L1 value capture, and maintaining a composable ecosystem.

The Solution

Based rollups solve the challenge by adding shard-like execution extensions to Ethereum while leveraging the L1 for sequencing. This approach aligns with three key scaling trends:

1. Decoupling Execution from Consensus

Emerging solutions decouple execution from consensus:

• Solana proposes Asynchronous Program Execution to build blocks before verification.

• Monad achieves consensus before executing transactions.

• Ethereum is progressing with EIP‑7732 (ePBS) to boost throughput and accelerate finality—capabilities critical for based rollups.

2. Parallel Execution and Local Fee Markets

Parallelization enables higher throughput by processing mutiple transactions concurrently:

• High performance chains like Solana, Sui, and Monad process transactions in parallel, creating isolated "local" fee markets that keep hotspots from throttling the chain.

• Similarly, Ethereum rollups serve as parallel execution zones with independent fee dynamics. For more on local fee markets, see Luban's previous writings.

3. Maintaining Synchronous Composability

Parallel VMs stay composable only if they coordinate state conflicts:

• deterministic read/write lists before execution (Solana, Sui)

• or optimistic "run-then-replay" parallelization (Aptos, Monad).

Absent either, calls between threads can only be asynchronous, consider separate Cosmos zones communicating over IBC, or separate rollups on Ethereum today connected via bridges.

Based rollups restore Ethereum's missing synchronous composability by moving each rollup's sequencing back to the L1. Since the same Ethereum validators order both L1 and L2 transactions within a single block, state transitions on based rollups and L1 share a unified, canonical order, enabling real-time interaction across layers.

What's Missing for Based Rollups Today

Based rollups face a critical trade-off: preserving their based properties (inheriting liveness and censorship-resistance from L1, synchronous composability) versus optimizing user experience. Fully L1-driven sequencing inherits Ethereum's 12-second block time and per-block settlement, resulting in slow, costly transactions. To address this, preconfirmation are used, where Ethereum validators sequence and confirm transactions before they're settled on L1.

However, preconfirmation introduces two key challenges:

1. Cold Start: Each based rollup must independently bootstrap and maintain its own validator network, leading to duplicated effort and resource inefficiency as the ecosystem grows.

2. Scalability: It's impractical to expect every single Ethereum validator to run 1000 sidecars and sequence for 1000 based rollups.

These gaps highlight the need for a unified framework that efficiently connects validators to based rollups, enabling superior UX while preserving the core benefits of based sequencing.

LingLong: The Pre-Settlement Layer for Ethereum

Luban introduces LingLong, a proposer commitment and delegation framework that enables pre-settlement of rollups on Ethereum.

LingLong allows

• Based Rollups to choose where they want to be on the basedness spectrum, offering flexible sequencing models and ways to capture value.

• Validators to earn passive yields from rollup activity, strengthening both Ethereum L1's value proposition and ETH as an asset.

Pre-settlement

Pre-settlement is a proposer commitment primitive that enables Ethereum validators to delegate their based rollup sequencing rights to third parties. LingLong embodies this primitive, thereby effectively facilitating PBS (Proposer-Builder Separation) for based rollups.

Currently, most validators delegate block building rights to the highest-bidding block builder via MEV-Boost relays, maximizing passive returns through auctions. Similarly, validators by definition possess sequencing rights for based rollups and can delegate these rights to earn passive yield. The delegatee—known as a gateway—becomes the actual rollup sequencer.

Unlike MEV-Boost auctions where builders are chosen just-in-time, the gateway must be chosen ahead of time since rollup users require instant transaction confirmation. Linglong makes this possible through restaking-secured credible commitments, allowing rollups to settle state update before actual L1 settlement.

Pre-settlement vs. Preconfirmation

In preconfirmation, the 'preconfirmer' must be the proposer of the next Ethereum block to guarantee absolute settlement certainty for the preconfirmed transactions—since the proposer controls the block. A preconfirmer who is not the proposer cannot offer the same level of assurance.

Pre-settlement decouples the roles of preconfirmer and proposer, allowing anyone to act as a preconfirmer (gateway) while still achieving absolute settlement certainty through delegation from proposers.

Rather than relying on centralized solutions with individual gateways, validators delegate to a gateway network that supports customizable selection mechanisms to optimize for both validator and rollup.

Restaked Services

Pre-settlement operates through LingLong's restaked services, which use restaking protocols to extend validator commitments across a permissionless range of activities—such as rollup sequencing—while shielding validators from operational, legal, and financial risks.

Restaked Validator Service (RVS) is foundational to all other restaked services. Validators join RVS and provide the required stake through restaking—using either their own staked ETH or external capital from restakers—to delegate rights and duties to other restaked services.

Restaked Gateway Service (RGS) is a network of sequencing gateways that receives delegation from validators to sequence based rollups. RGS creates a marketplace where gateways can join by meeting rollup sequencing requirements and compete for sequencing opportunities.

When RVS delegates rollup sequencing rights to RGS

• rollups dictate their own sequencing models,

• validator receives passive yield from rollup activities,

• rollup users receive instant transaction confirmation from gateways,

• restakers receive yield from restaked services they are securing.

Note: More restaked services can be built on top of RVS permissionlessly. For example, validators can delegate future blockspace and blobs to an underwriter network, enabling users to secure faster confirmations and deterministic L1 costs with blockspace futures. As a validator, the downside of opting into RVS is limited yet the upside is unlimited.

Sequencing Models

LingLong, or specifically RGS supports three configurable sequencing models compatible with all rollups—not just based ones. This flexibility allows rollups to balance decentralization, performance, and control throughout their platform's development stages.

1. Fully-Based Model

• Based Sequencing: Validators freely choose rollup gateways through RGS auction mechanisms.

• No Rollup Restrictions: Rollups place no constraints on gateway selection.

• Use Cases: Ideal for rollups prioritizing maximum decentralization and censorship resistance.

2. Half-Based Model

• Hybrid Approach: Rollups establish gateway requirements (like native token staking or hardware specifications), while validators select from qualified candidates.

• Two-Stage Process: Gateways must first satisfy rollup criteria, then compete for validator selection.

• Use Cases: Suitable for rollups requiring specific infrastructure or focusing on native token value capture.

3. Fully-Centralized Model

• Direct Appointment: Rollups directly assign their gateways without validator involvement.

• Maximum Control: Mirrors the structure of traditional centralized sequencer rollups.

• Use Cases: Best for early-stage rollups or those prioritizing MEV control.

What the Future Looks Like

Existing rollups can use LingLong to gradually transition to being based. A centralized sequencer rollup can initially adopt the fully-centralized sequencing model—which preserves complete control for the rollup operator—while benefiting from guaranteed settlement certainty through proposer commitments. Their sequencer, as part of RGS, can then compete to sequence other rollups (including L1) to enhance cross-chain composability for their users.

Most rollups are expected to adopt the half-based model. Rollup operators can accrue value by setting gateway selection criteria while opening sequencing to a unified market of professional gateways. These gateways aim to sequence multiple rollups and L1 to maximize returns, naturally creating a synchronously composable ecosystem.

The fully-based model creates pure extensions to Ethereum L1's execution environment. It's analogous to sharding, but in a bottom-up way. Based rollups can be built permissionlessly without requiring changes to Ethereum consensus.

At Luban, we envision a horizontally scalable Ethereum as a unified ecosystem that eliminates the boundary between dapps and rollups. Any application or group of applications can seamlessly become part of Ethereum, accessing the strongest cryptoeconomic security and largest onchain financial ecosystem while maintaining sovereignty and user experience. Assets and operations flow freely across all applications, whether they're L1 smart contracts or rollups.

Since November 2024, Ethereum’s blob market has stabilized at an average of 3 blobs per block, aligning with EIP-4844 goals. However, blob prices remain highly volatile—hovering at lows during periods of inactivity and spiking even up to 10 billion times higher during peak demand.

Furthermore, blobs contain significantly more data than regular L1 transactions, leading to larger block sizes and slower block submission. In the current PBS (Proposer-Builder Separation) setup, this increased latency puts builders at a disadvantage when competing in block auctions. As a result, block builders tend to avoid including blobs—incorporating significantly fewer of them compared to vanilla local builders.

Uncertain inclusion and price volatility make it difficult for rollups to maintain consistent blob submission schedules and manage L1 costs. This especially affects smaller rollups, who risk being priced out by major players like Base and Taiko.

Introducing Blob futures

Luban introduces blob futures, the first solution that enables Ethereum rollups to pre-purchase guaranteed blobs at fixed prices. Blob futures are built on Luban’s Taiyi protocol, a Restaked Service that allows users to obtain fine-grained commitments from proposers on future blockspace. Taiyi will soon launch on both Holesky and Hoodi testnet.

Restaked Services leverage existing restaking infrastructure like Eigenlayer and Symbiotic to create a layered security model with isolated risk and rewards, for Ethereum validators to extend commitments beyond Ethereum core consensus.

Workflow for Securing Future Blobs

• Underwriter Delegation: Restaked underwriters within Taiyi receive delegation from proposers—those who have opted into Taiyi—to issue blobpace commitments.

• Slot Identification: Rollups scan a 2-epoch (~12-minute) lookahead window to identify opt-in proposers and target slots.

• Price Agreement: Rollups and the underwriter for the chosen slot agree on a price under an RFQ model, with rollups paying the underwriter for the future blobs.

• Batch Submission: Rollups submit transaction batches to the underwriter before the designated slot.

• Inclusion Enforcement: Underwriters enforce blob inclusion via constraints on block building in the target slot, absorbing real-time gas costs.

Benefits for Stakeholders

• Rollups: Secure predictable settlement costs and schedule reliability, even during demand spikes.

• Validators: Earn premium yields by selling future blob capacity, minimizing exposure to gas volatility.

• Underwriters: Assume gas volatility risk while competing to profit through market-making for future blobs.

Based OP Stack Rollup PoC w/ Blob Futures

RISE Chain, a high-throughput Ethereum based rollup, has built an OP stack rollup incorporating based sequencing and blob futures. By locking in blobs upfront, the rollup ensures uninterrupted throughput with rotating sequencers, smooth cost and in the future, better composability with the L1. The implementation has been open-sourced.

Beyond Blobs: Luban’s Vision for Pre-Settlement

Blob futures are the first step toward Pre-Settlement—a framework decoupling based rollups’ execution from L1 consensus. By enabling based rollups to settle state updates on L1 ahead of the actual settlement transactions via delegation, Luban unlocks:

• Supercharged based rollups: As horizontal extensions of Ethereum’s execution layer, based rollups leverage pre-settlement to achieve near-instant transaction finality. This eliminates user experience bottlenecks while preserving seamless interoperability with L1 and other rollups.

• Validator-centric scaling: Pre-settlement transforms Ethereum validators into economic hubs that earn passive yield from rollup activity. Through flexible proposer commitments, validators can delegate sequencing tasks—and eventually any other duties—to specialized third parties using customizable selection mechanisms. This optimizes efficiency while maintaining Ethereum's decentralization and liveness guarantees.

Get Involved

While we are coordinating testnet deployment on Holesky and Hoodi, rollups and validators interested in integration are encouraged to reach out. The Taiyi underwriter repo is now open-sourced and can be found here. You can also check out the smart contracts, documentations, and the Go client for blob futures.

If you are a rollup, please just DM. A dedicated devnet will be available for early adopters.

If you are a node operator, please fill out this form https://docs.google.com/forms/d/e/1FAIpQLSdFYuxkG6Jp16KORAWk1fF79MxOe0aIY4KYTJ_iC2-kDvqyaQ/viewform?usp=dialog and we will get you hands-on support for setup.

Join Luban in reshaping Ethereum’s blockspace economy and hyperscaling the world computer!