An interesting narrative on perp DEXs and Ethereum DeFi is quietly unfolding. It began with Tarun, who sketched a compelling vision in which DeFi positions on Ethereum L1 (e.g., vault shares in Morpho) can be used directly as collateral to back perp trades on L2 perp DEXs like Lighter, enabled by ZK proofs of position value on L1 and liquidation data on L2.

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.

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.

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.

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.

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.

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.

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.

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”.

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.

An interesting narrative on perp DEXs and Ethereum DeFi is quietly unfolding. It began with Tarun, who sketched a compelling vision in which DeFi positions on Ethereum L1 (e.g., vault shares in Morpho) can be used directly as collateral to back perp trades on L2 perp DEXs like Lighter, enabled by ZK proofs of position value on L1 and liquidation data on L2.

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.

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.

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.

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.

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.

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.

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.

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”.

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.