Why This Matters

Nothing changes for users, except potentially better prices. Users simply swap through KyberSwap as usual, and the router will automatically include BaiBai liquidity in its pathfinding when doing so improves execution.

Behind the scenes, market makers on BaiBai continuously compete on price. Since BaiBai's PropAMM provides active, programmable liquidity with real-time price updates, it can often deliver better pricing than traditional onchain venues.

For market makers on BaiBai, this integration represents an important new source of order flow, allowing them to reach a broader set of users while competing on execution quality.

This collaboration marks an important step toward bringing professional-grade liquidity onchain and delivering the best possible trading experience for everyone in DeFi.

Next Up: BaiBai Public Launch

While KyberSwap users can already access BaiBai liquidity through Kyber's routing engine today, the standalone BaiBai app remains in closed alpha.

The public launch of BaiBai, a PropAMM DEX, is planned for the coming months and will introduce additional features including gasless trading, rewards, and a dedicated trading experience built around professional market maker liquidity.

Early users are encouraged to join the closed alpha today to get first access and experience the next generation of onchain trading before the public launch.

Link: baibai.cx

A biased history of Ethereum trading primitives

In Ethereum’s early years, trading onchain felt more like a digital bazaar than a modern exchange. Liquidity was thin, fragmented, and difficult to discover. If you wanted to trade one asset for another, you needed someone willing to take the opposite side at roughly the same time and price. Early systems relied on variants of peer-to-peer matching and onchain order books, but liquidity was sparse, and the user experience was often slow and inefficient.

The problem wasn’t that trading infrastructure didn’t exist; it was that Ethereum’s architecture imposed constraints. Maintaining a traditional onchain central limit order book (CLOB) meant continuously creating, updating, and cancelling orders. Execution was expensive and unpredictable. Markets could exist, but they struggled to attract enough liquidity and activity to feel efficient. At a time when online trading systems elsewhere could fill orders in milliseconds, Ethereum transactions could take minutes to settle. The future of finance it was not.

Automated Market Makers (AMMs) changed this model entirely.

Instead of requiring a direct counterparty for every trade, AMMs introduced pooled liquidity that anyone could trade against at any time. Liquidity providers could deposit otherwise idle assets and earn fees in return, while traders gained immediate access to liquidity without needing another participant on the other side.

The tradeoff was straightforward: users exchanged price precision for accessibility and composability. Prices were mathematically derived from liquidity curves rather than determined through competing bids and offers. Larger trades incurred slippage, and liquidity was not necessarily deep, but it was always available, 24/7. More importantly, liquidity itself became a permissionless building block that any application could integrate with. Early pioneers such as Bancor led the charge, with Uniswap later refining the model and pushing it into the centre of DeFi.

This was transformative. Rather than being a destination, liquidity became infrastructure. Money was becoming programmable. For the first time, financial functionality felt less like an application and more like a set of Lego bricks that anyone could assemble into something new. It was genuinely innovative and, at the time, incredibly exciting.

As the ecosystem matured and more sophisticated participants entered the market, new trading primitives emerged. Protocols such as AirSwap, 0x, and later CoW Protocol explored alternative designs built around RFQs, off-chain order relays, intents, and solver networks.

These systems sought to address some of AMMs’ weaknesses by enabling users to express trades through signed intents or limit orders, while market makers and competing solvers provided execution. This frequently resulted in tighter pricing and improved capital efficiency, particularly for larger trades.

But the tradeoffs simply shifted elsewhere. Quotes could become stale, orders might not fill immediately, if ever, and more of the coordination would move off-chain. While settlement remained on Ethereum, some of the magic of fully onchain composability was lost. From a programmable money perspective, this felt like a step backwards. Not because the execution quality was worse, often it was much better, but because some of the intelligence moved away from open and shared infrastructure into specialised and often more opaque intermediaries.

Meanwhile, AMMs themselves continued evolving. Concentrated liquidity allowed liquidity providers to allocate capital only where trading activity was expected, dramatically improving capital efficiency. More recently, hooks introduced the ability to attach custom logic directly to liquidity pools, enabling dynamic fees, custom execution behaviour and entirely new forms of market design. Trading primitives have gradually shifted from static, passive systems to increasingly adaptive and expressive ones.

Yet despite all these improvements, AMMs and DeFi more generally still react to market conditions rather than anticipate them. Liquidity positions update periodically while markets move continuously. For many major assets, price discovery still largely happens on centralised exchanges such as Binance, while DeFi often plays catch-up.

That gap between where prices are discovered and where liquidity actually lives may be one of the most interesting problems in DeFi today. PropAMMs are an attempt to close it.

What is a PropAMM

PropAMM has become something of a catch-all term for a new class of active market-making systems. Rather than relying purely on a static pricing curve, these systems continuously adjust prices using external signals, inventory models and proprietary strategies. At its simplest, a PropAMM is an AMM with a feedback loop attached. A pricing engine observes market conditions, estimates fair value and updates executable liquidity accordingly. In some implementations, this may be little more than publishing updated quotes every block and refusing to trade against stale prices. More sophisticated systems incorporate volatility, inventory exposure, order flow and broader market conditions into their pricing decisions.

Most designs share a common pattern: pricing happens off-chain while execution remains onchain. This creates an interesting shift in where competitive advantage lives. Traditional AMMs largely competed on liquidity depth and fee structures; active market makers increasingly compete on latency, pricing accuracy and execution quality. The ability to observe markets, react quickly, and land transactions efficiently is becoming a strategic edge.

Some firms are already forming closer relationships with block builders and sequencers to secure favourable execution and top-of-block placement. In many ways, this feels familiar. High-frequency trading firms spent years placing servers physically closer to exchanges because microseconds mattered. Crypto is beginning to develop similar behaviour. Instead of competing for physical proximity to exchanges, firms are competing for proximity to block production.

The problem with this model, at least in our view, is that it is still too slow. The programmability remains separated from the moment that actually matters: the swap itself. Ideally, you want pricing logic to execute at the point of trade execution, allowing liquidity to adapt in real time as transactions flow through the system. The challenge is cost. Complex logic executed during a swap increases gas consumption, and those costs ultimately fall on the user. More expensive execution leads to wider spreads, poorer execution quality, and a less competitive market. The ideal system would allow market makers to continuously adapt prices at the point of execution while making that additional complexity feel almost free to the trader.

Based L3 Appchains, Synchronous Composability and Programmable Market Makers

Baibai approaches this problem differently to other PropAMMs. We use a based L3 appchain architecture. In practice, this means the market-making logic and price updates run in a dedicated execution environment, while users continue to interact from the L2.

Users remain on Base.

Market makers operate on the L3 appchain.

This separation matters because execution on the appchain is cheap enough that market makers can continuously update pricing logic without pushing meaningful additional costs onto traders.

The important detail is that the swap itself still happens on the L2, but the pricing logic is composed with state from the appchain at execution time. The AMM curve becomes less important than the ability to retrieve a fresh executable price.

In practice, the L2 queries the L3 for pricing data. Before the swap executes, the market maker submits an updated pricing state to the appchain. The sequencer then observes both the state update and the swap within the same sequencing window, allowing the transaction to execute against pricing that was refreshed immediately before inclusion. Rather than relying on stale liquidity positions or periodically refreshed curves, execution composes directly with continuously updated market state.

Conceptually, it starts to resemble synchronous composability across execution domains. Instead of treating the appchain as an isolated environment, the L2 swap effectively composes with market-making logic executing elsewhere, but still within the same sequencing window. This design fits naturally alongside emerging preconfirmation systems such as ETHGas or more direct integrations with sequencers and block builders. The later a market maker can observe the state before committing a quote, the more accurately it can price risk and the tighter spreads it can theoretically offer. Today, this is a best-efforts predictive model in which price updates are inserted alongside the swap and calculated at the point of submission to the sequencer. But we think tighter sequencer integration could push this much closer to real-time state updates.

In many ways, this shifts the AMM's role entirely. Liquidity increasingly stops being the mechanism for price discovery and instead becomes infrastructure for executing against externally generated prices.

Ethereum trading primitives have steadily evolved from simple peer-to-peer swaps to passive liquidity curves, to increasingly programmable and adaptive systems. PropAMMs push that trajectory even further. They blur the boundary between market maker, execution engine and settlement layer, while forcing DeFi to confront deeper questions about composability, latency, openness, centralisation and where intelligence should live (and who ultimately controls it) within the stack. Some of these designs may ultimately fail or drift too far toward opaque off-chain systems, but that tension is precisely what makes them important.

DeFi has always progressed by pulling more financial logic onchain, then discovering the limits of what onchain systems can support. PropAMMs feel like the latest attempt to push that boundary again.

Our view is that the next step is not simply building faster market makers. DeFi will never compete with high-frequency trading firms operating at sub-microsecond latencies inside highly optimised private infrastructure. Instead, the opportunity lies in extending Ethereum to make it even more composable. Fully customisable execution environments where complex programmable liquidity can evolve without sacrificing the composability that made DeFi powerful in the first place.

We think synchronously composable based appchains are one of the best ways to keep pushing Ethereum forward without giving up the things that made this whole experiment exciting to begin with.

You are no longer just a trading platform or custodian.

You are an execution engine.

Most CEXs run that engine inefficiently.

Once you control signing, execution becomes a cost center, and most teams under-optimize it.

Backend-Signed Execution Systems

Centralized exchanges fall into a category that doesn’t get enough attention:

backend-signed execution systems.

These systems:

• Construct transactions server-side

• Control calldata and execution structure

• Pass gas costs to users (often with a buffer)

In a CEX, this includes:

• Withdrawals

• Deposit sweeping

• Hot ↔ cold wallet rebalancing

• Internal settlement

• Cross-chain liquidity movement

There is no external signer. Everything is coordinated internally, signed by your infrastructure (or MPC provider), and executed at your expense.

Which means:

Execution inefficiency directly impacts both margins and user experience.

The Hidden Cost Center

Most exchanges optimize for:

• Volume

• Liquidity

• Fees

• Latency

But under the hood, they run a high-throughput execution pipeline.

Where inefficiency shows up

• One withdrawal = one transaction

• Repeated logic with fixed overhead per user

• The same contract calls encoded over and over

• No aggregation or batching across users

• Identical transfers executed independently

• Systems built for correctness, not efficiency

Why it’s missed

At small scale, costs are negligible.

At large scale, they compound across millions of transactions.

Execution quietly becomes one of the largest unoptimized cost centers in a CEX.

Where CEXs Leak Efficiency

Withdrawals

Pattern:

• One request → one transaction

Opportunity:

• Batch across users

• Share execution overhead

Deposit Sweeping

Pattern:

• Individual sweeps from deposit addresses

Opportunity:

• Aggregate transfers

• Reduce repeated contract calls

Rebalancing

Pattern:

• Independent transfers across wallets and assets

Opportunity:

• Combine flows

• Optimize timing and batching

Internal Onchain Flows

Even mostly offchain systems still:

• Move funds

• Reconcile balances

Opportunity:

• Treat internal operations as batchable units

• Reduce routine execution cost

Spire: Execution Optimization as Infrastructure

Spire Labs builds DA Builder, a transaction aggregation layer for Ethereum.

It sits between your backend and the chain, combining multiple transactions into a single optimized execution.

DA Builder:

• Combines multiple transactions into a single onchain transaction

• Reduces redundant overhead and execution costs

• Shares calldata across transactions

• Lowers gas and calldata costs

• Improves inclusion via higher-value bundled transactions

• Adds built-in MEV and revert protection

Framed simply:

Execution infrastructure for teams that already own transaction flow

No changes to:

• UX

• Product logic

• Core systems

Just more efficient execution.

Why It Matters

Margin Expansion

Lower gas per action directly improves unit economics.

Better User Economics

Cheaper execution enables lower fees and better pricing.

Non-Linear Scaling

Batching reduces cost per transaction as volume grows.

The Shift

If your backend signs transactions, execution is your responsibility.

Most CEXs today:

• Treat execution as plumbing

• Accept default patterns

• Ignore aggregation

That won’t hold.

Execution optimization will become standard infrastructure, like CDNs in Web2.

And exchanges that adopt it early will have a structural advantage:

• Lower costs

• Better pricing

• More scalable systems

Because ultimately:

If you control signing, you control execution.

And execution is worth optimizing.

It's surprising, you're building on Base, blockspace is faster, feedback loops are tighter, and execution should finally feel like a modern trading app. Sub-second preconfirmations and ~200ms feedback loops are supposed to remove the old excuses.

And yet the user still taps trade, waits, refreshes, retries, or gets a worse fill than expected.

That gap matters because it changes the diagnosis. On high-performance EVM rails, this is no longer mainly a chain-speed problem. It is an execution problem inside the application stack.

Embedded wallets solved one of crypto's hardest early problems: getting users on-chain without forcing them through seed phrases, extensions, and custody anxiety. They made the front door feel normal. A user can sign up, fund, and start trading in a flow that looks much closer to fintech than old-school crypto.

But for trading terminals, removing onboarding friction only raises the bar. Once the wallet experience becomes invisible, users stop grading you on wallet UX and start grading you on whether the trade actually lands, how fast it lands, and whether the result matches the quote.

That is why teams building on Base keep running into the same uncomfortable question:

If we're already on fast chains, why is execution still breaking in our app?

The bottleneck has moved

For a long time, crypto teams could blame the chain.

Blocks were slow. Confirmation times were long. Feedback loops were noisy. Users had to tolerate latency because latency was structurally unavoidable.

That excuse is getting weaker, especially on Base and other fast EVM environments. With Flashblocks and similar improvements, users can get signal far earlier than final settlement. Infrastructure has moved forward. Expectations moved with it.

The bottleneck did not disappear. It moved.

Today, the fragile part of the trading experience is increasingly the execution pipeline between user intent and chain inclusion. That includes:

• transaction construction

• routing

• submission strategy

• mempool and builder interaction

This is what many teams miss. They upgraded the chain environment, but not the logic sitting on top of it.

So the app still behaves like it was built for slower conditions. It treats propagation as a commodity. It assumes that if the underlying chain is fast, the user outcome will be good by default.

That assumption is wrong.

Fast chains do not automatically create fast trading UX

If you run a trading terminal with embedded wallets, your user does not separate infrastructure layers in their head.

They do not think:

The chain was fast, but the transaction construction path was suboptimal.

They think:

My trade failed.

Or:

I got a bad fill.

Or:

This app was too slow and I missed it.

That is the entire commercial problem in one sentence. Fast chains improved the ceiling, but most apps still deliver a mediocre realized experience because the execution stack is underbuilt.

This is especially visible in embedded-wallet products. Once onboarding friction is gone, the product implicitly promises instant action. The user signed up in seconds. Funding felt smooth. The interface looks like a serious terminal. So when the trade path stalls under volatility, the failure feels even worse. The app presented itself as high-performance, then broke at the moment that mattered.

That is why the next competitive battleground for trading terminals is not basic wallet abstraction. It is execution quality.

Execution is now an application-layer problem

This is the framing shift more teams need to make.

The problem is not, broadly speaking, that chains are too slow anymore. The problem is that execution quality is now determined by application-layer decisions.

How is the transaction assembled?

How is the transaction submitted under changing conditions?

How does the app interact with the mempool, builders, and inclusion pathways that actually determine whether the user gets the outcome they expected?

Those questions now sit directly on the critical path of product quality.

That means execution is no longer a backend detail you can leave in a default state. It is a core UX system. It affects conversion from intent to trade, trader confidence during volatility, retained volume, and ultimately revenue per user.

If the user has to retry, wait, or accept unexplained slippage, your infrastructure story does not matter. You built on a fast chain and still delivered a weak trading experience.

What this means for embedded-wallet trading terminals

The broader market of trading terminals using embedded wallets is now converging on the same pattern.

Access is solved well enough. Distribution is no longer limited by the wallet setup cliff. The question is what happens after the user presses the button.

And that is where many products are still thin.

They have good onboarding, good branding, and good surface-level UX. But underneath, the execution path is still generic. It was not designed for stressed market conditions, tight user expectations, or the realities of modern EVM trading flow.

The result is predictable:

• lower trade completion rates

• worse fills

• more failed or stuck transactions

• less trust during the moments that generate the most volume

Users do not need many of these experiences before they change behavior. A few broken trades during volatility is enough to teach a user that your app is not where they should size up.

Spire is the missing execution layer on top of fast chains

This is the gap Spire Full Send is built to address.

Not as a replacement for fast chains, but as the missing execution layer on top of fast chains.

That distinction matters. Base, Ethereum L2s, and Flashblocks-enabled environments improve what is possible. Spire improves how reliably your app captures that possibility for the user.

It sits between user intent and on-chain outcome, optimizing the part that many teams still leave underpowered: the execution path itself.

That means better transaction handling, better routing outcomes, smarter submission behavior, and tighter interaction with the pathways that determine inclusion quality. In practical terms, that translates into what your users actually notice:

• more successful trades

• faster inclusion

• fewer dropped or reverted transactions

• less value leakage and more MEV-aware execution

This is why execution optimization still matters even if you are already building in a high-performance environment. Fast infrastructure is not the finished product. Apps still need an execution layer that knows how to operate on top of it.

The takeaway

Embedded wallets removed the old onboarding bottleneck.

Fast chains removed many of the old infrastructure excuses.

What remains is the part that now decides whether a trading terminal actually feels good: execution.

If you are building on Base, Ethereum L2s, or similar fast environments, and your users still experience failed trades, the answer is probably not that the chain is not fast enough.

It is that your execution pipeline is now the product bottleneck.

That is the shift. The winners in trading will not just have cleaner onboarding or faster blockspace. They will have the best execution layer on top of fast chains.

If that is the problem you are trying to solve, explore Spire Full Send:

• https://spire.dev/fullsend

Even today at sub gwei base fee a typical Ethereum mainnet fill might cost ~$0.03–$0.20 in gas. At scale, that isn’t noise. It is your margin.

And yet, most execution systems today are still treated as an afterthought.

How solvers actually operate

For most intent-based systems the lifecycle is broadly similar:

1. A user expresses an intent (swap, bridge, etc.)

2. Solvers generate quotes based on their internal pricing models

3. A winning solver is selected

4. The solver executes the transaction onchain

The industry has spent the majority of its energy on step (2): pricing.

• Better routing algorithms

• Faster quote generation

• More accurate slippage modelling

• Inventory-aware pricing

But once a solver wins, execution is typically handled in a much more fragmented way:

• Each solver constructs and submits its own transactions

• Gas bidding is done independently

• Calldata is often unoptimized

• Routing decisions are made locally, not globally

• Inclusion is left to public mempools or private RPCs with revert protection

This works, but it is far from efficient.

The hidden problem: execution inefficiency

Execution inefficiency is easy to miss because it doesn’t show up in the quote. It shows up in realized PnL.

Two solvers can quote the same price, win the same intents, and still end up with very different outcomes purely due to execution.

The gap comes from a collection of small inefficiencies:

• Slightly higher gas usage per transaction

• Redundant calldata across fills

• Suboptimal routing paths

• Poor inclusion timing

• Occasional reverts

Individually, each might look negligible. Together, they compound.

A rough rule of thumb we’ve seen in production systems:

~10% of execution cost is structurally wasted.

Not because of bad engineering, but because the system itself isn’t designed to optimize execution globally.

Where the inefficiencies come from

1) Gas inefficiency

Most solver transactions are constructed in isolation.

• No batching across fills

• No shared state reuse

• No amortization of fixed costs

If you’re submitting 10 independent fills, you’re paying 10 times for base costs that could be shared.

Even small savings—10k–20k gas per transaction—add up quickly at scale.

2) Calldata bloat

Calldata is often the most overlooked cost center.

• Repeated parameters across transactions

• Verbose encoding patterns

• No compression or aggregation

On mainnet, calldata is not cheap. At high throughput, reducing calldata by even a few dozen bytes per transaction translates directly into margin.

3) Routing fragmentation

Routing decisions are typically made per intent.

But in reality, many fills share overlapping paths:

• Same token pairs

• Same liquidity sources

• Same intermediate assets

Without aggregation, you end up:

• Hitting the same pools multiple times

• Incurring redundant price impact

• Paying repeated routing overhead

A globally optimized system would recognize these overlaps and co-route them.

4) Inclusion and timing

Inclusion is not just about getting a transaction mined. It is about when and how.

Common issues:

• Overpaying for gas to guarantee inclusion

• Underbidding and missing profitable windows

• Competing with your own transactions

• Exposure to mempool latency and reordering

Many solvers treat inclusion as a binary problem. In reality, it is an optimization surface.

5) Reverts and reliability

Reverts are often dismissed as edge cases. They’re not.

They come from:

• State changes between quote and execution

• Fragile routing assumptions

• Race conditions with other solvers

Each revert is a direct cost:

• Lost gas

• Lost opportunity

• Potential penalties (depending on protocol design)

Reducing revert rates even slightly can have an outsized impact on profitability.

Why this matters

Execution inefficiency doesn’t just affect solvers. It propagates through the entire system.

For solvers:

• Lower margins

• Higher variance in outcomes

• Reduced competitiveness in auctions

For users:

• Worse pricing (inefficiencies get priced in)

• Lower reliability (failed or delayed fills)

For protocols:

• Reduced solver participation

• Less competitive auctions

• Worse UX and retention

Thesis:

Execution quality, not liquidity, is becoming the primary differentiator in intent-based systems.

Liquidity is increasingly commoditized. Execution is not.

Aggregation as a missing primitive

The core issue is that execution today is decentralized at the wrong layer.

Each solver optimizes locally, but no one optimizes globally.

Aggregation changes that.

Instead of treating each fill as an independent transaction, you treat execution as a shared problem:

• Batch multiple fills into fewer transactions

• Deduplicate calldata

• Co-optimize routing across intents

• Manage gas bidding at the aggregate level

• Coordinate inclusion strategy

This is not just about cost reduction. It is about system design.

A well-aggregated execution layer can:

• Reduce per-fill gas costs

• Improve inclusion consistency

• Lower revert rates

• Enable more sophisticated routing strategies

And importantly, it allows solvers to focus on what they’re actually differentiated in: pricing and inventory management.

A concrete example

Consider 10 fills targeting similar token pairs within the same block.

Without aggregation:

• 10 separate transactions

• 10x base gas costs

• Repeated calldata

• Independent routing decisions

• Potential self-competition in the mempool

With aggregation:

• Fewer bundled transactions

• Shared execution paths

• Compressed calldata

• Coordinated inclusion

• Reduced contention

Even a modest improvement, say $0.01 saved per fill, scales to meaningful numbers quickly.

At 5k fills/day, that’s $50/day in recovered margin.

Where Spire fits

This is the layer Spire is focused on: transaction aggregation and execution infrastructure.

Not another solver. Not another quoting system.

A shared execution layer that sits downstream of solvers and optimizes how transactions actually hit the chain.

In practice, this means:

• Aggregating fills across solvers

• Reducing gas and calldata overhead

• We’re seeing ~10% savings in production today, in a bear market!

• Improving inclusion quality

• Zero reverts

We’re already working with relayers in systems like Across, where execution quality directly impacts both solver profitability and user outcomes.

The goal isn’t to replace solvers. It is to make them more efficient.

Where this is going

As intent-based systems expand and cross-chain execution becomes solver-driven, the pressure on execution will increase.

A few trends are already clear:

• More competition on thin margins → execution efficiency becomes decisive

• Higher throughput systems → inefficiencies compound faster

• Cross-chain complexity → execution reliability becomes harder

• Protocol-level auctions → solvers need consistent, predictable outcomes

In that world, the current model, independent, uncoordinated execution doesn’t scale.

We’re likely moving toward a separation of concerns:

• Solvers specialize in pricing and capital efficiency

• Execution layers specialize in aggregation, routing, and inclusion

The same way block builders emerged to optimize block construction, execution infrastructure will emerge to optimize solver transactions.

And the solvers that adopt it early will have a structural advantage, not because they quote better, but because they execute better.

That’s where the next 10% comes from.

This marks an important step in supporting Aztec’s fully permissionless architecture, where both sequencing and proving are open to anyone, and reinforces the role of efficient infrastructure in scaling decentralized systems.

Enabling Efficient Participation in a Permissionless Proving Network

Aztec is one of the first rollups to introduce permissionless proving, allowing any participant to generate and submit proofs for proposed blocks.

This open design strengthens decentralization, but it also introduces a challenge:

Provers must independently submit transactions to Ethereum L1, competing in the same fee market as all other users. As a result, gas efficiency and transaction inclusion become critical to profitability and performance.

Spire’s DA Builder addresses this by aggregating and optimizing proof submissions before they are posted to Ethereum, delivering:

1. Cost Reduction: Aggregated submissions significantly reduce per-proof gas costs.

2. Faster Inclusion: Optimized transaction landing improves inclusion latency in Ethereum blocks.

Together, these improvements make permissionless proving more economically viable—especially as network activity scales.

Expanding to Sequencer Support

While DA Builder is now live for Aztec provers, this is only the beginning. With the next Aztec mainnet upgrade, DA Builder will be integrated to support Aztec sequencers, enabling the most cost-efficient block building.

Unlike many rollups that start with a centralized sequencer, Aztec launched with a fully decentralized sequencer network. Nodes are randomly selected to build and validate blocks, reducing censorship risk by design.

This design empowers sequencers to choose how to land L1 block proposal transactions and how much gas to pay. There’s game theory at play: sequencers must get transactions included (earn rewards) without overpaying for gas. Rational actors will always try to minimize overhead.

DA Builder will do exactly that. By aggregating and optimizing L1 submissions, it enables sequencers to compete efficiently in Aztec’s permissionless environment.

Strengthening the Economics of Decentralized Infrastructure

As rollups evolve toward fully decentralized systems, operational efficiency becomes a key enabler of participation.

Without cost-efficient infrastructure, permissionless systems risk centralization due to high operational overhead. By improving how transactions are submitted to Ethereum L1, DA Builder helps:

• Lower the barrier to entry for node operators

• Improve profitability for participants

• Support long-term network resilience and decentralization

Adding DA Builder Today

Aztec provers can now leverage DA Builder on the Aztec mainnet, available today.

Support for Aztec sequencers will be included in the next Aztec mainnet upgrade.

If you're running an Aztec node, contact us to ensure your setup is fully optimized for cost-efficient operation.

This collaboration integrates Spire’s DA Builder into BTCS’s Builder+ operations, aligning transaction aggregation with robust block building infrastructure on Ethereum.

BTCS Inc. is a publicly traded blockchain company focused on Ethereum, building and operating scalable, revenue-generating infrastructure across the Ethereum network. Anchored by expertise in block building, validator operations, and decentralized finance, BTCS supports growth within the Ethereum ecosystem through consistent execution and long-term focus.

This new integration with Spire creates a tighter path from transaction execution to Ethereum settlement. For BTCS, it expands and diversifies order flow while strengthening its Builder+ operations.

Improving transaction delivery on Ethereum

As Ethereum evolves, with account abstraction, smart wallets, and increasingly complex application flows, reliable and cost efficient transaction delivery has become essential. Spire’s DA Builder is designed to meet this need by optimizing how transactions reach Ethereum blocks.

DA Builder aggregates transactions to:

• Reduce gas costs at scale

• Ensure fast and reliable inclusion

• Improve execution quality

• Deliver MEV protection

DA Builder is already used by leading relayers, wallet providers, and L2 networks, reflecting growing adoption across the Ethereum ecosystem.

Building Ethereum infrastructure together

This partnership reflects a shared belief that Ethereum infrastructure works best when aggregation, execution, and block building are designed together. By combining Spire’s DA Builder with BTCS’s block building expertise, we’re advancing more efficient and predictable transaction delivery on Ethereum.

We look forward to working closely together to expand this integration and strengthen Ethereum’s transaction and block building pipeline.

Together with BTCS, we’re helping shape the future of how applications execute and settle on Ethereum.

Through a new collaboration between Spire, cLabs, and Self Protocol, this appchain is powered by Self’s zero-knowledge Proof of Humanity and built using Pylon, Spire’s platform for synchronous composability. The launch demonstrates how appchains can now natively verify onchain human identity without sacrificing user privacy.

Together, we’ve unlocked a new class of applications that support compliant stablecoin usage, privacy-preserving eligibility and sanctions verification, and age-gated experiences while keeping user data protected.

Try the live demo and claim your Human NFT:

Human NFT

Claim your Human NFT - Mint your "I am human" NFT on Pylon appchain

https://human.spire.dev

Unify Ethereum chains, not silo

To build the onchain economy, we need to create a connected and unified Ethereum.

As Ethereum scales, fragmentation has become a growing challenge. Users, liquidity, and data are increasingly siloed across layers and chains, forcing new networks to bootstrap liquidity, rebuild user bases, and duplicate infrastructure. Users are left navigating degraded UX and frequent bridging. A unified chain experience enables new applications to scale globally by delivering seamless product experiences to users.

Synchronous composability is the foundation of this unified chain experience. Rather than relying on asynchronous messaging, delayed settlement, or external bridges, synchronous composability allows applications to read and act on shared state in real time, within a single transaction.

To bring this vision to life, we’re introducing a new appchain on Celo with Self, enabling anyone to use onchain human identity while preserving user privacy.

The Human Appchain uses synchronous reads to verify users' unique humanity directly on Celo. Users maintain privacy of their identity data, attestations are enforced onchain, and access to the commemorative NFT is limited exclusively to verified humans.

What the appchain unlocks

The launch demonstrates how appchains can now natively verify onchain human identity without building custom identity or sybil-resistance infrastructure from scratch. This opens up a range of opportunities for new onchain applications:

• Stablecoin usage (e.g. USDT) with identity guarantees

• DeFi with real-world credit score

• Privacy-preserving eligibility and sanctions verification

• Age-gated and compliance-ready experiences

• Secure wallet recovery via verified identity

• Fair airdrops and rewards with built-in sybil resistance

Appchains have emerged as the next phase of blockchain scaling, giving teams dedicated blockspace, custom execution environments, and application-specific performance and economics. But appchains shouldn’t live in isolation. With Pylon, appchains remain sovereign at the application layer while staying composable with Ethereum L2s like Celo. This lets builders focus on product, UX, and differentiation while inheriting shared infrastructure for liquidity, identity, and security. The Human Appchain demonstrates this model by composing directly with existing identity primitives instead of rebuilding them.

Self paired with Pylon enables a verified identity single sign-on experience for app developers on their own chain. Together, they create an identity layer that appchains can tap into when they choose to build on Celo.

The app is open-source on GitHub and demonstrates how any developer can seamlessly read from Celo in their smart contracts as if they were deployed on the same chain. See the docs and start building.

Why deploy on Celo

Celo is the leading Ethereum L2 by DAUs, with a community of over 700K users leveraging the network in their everyday lives. Having launched on mainnet Earth Day 2020, Celo is a battle-tested chain with an ecosystem committed to scaling blockchain through frontier tech. As early adopters of fee abstraction (stablecoins as gas payment), ZK infrastructure, and pioneers of mobile-first infra, the Celo community is primed for the next wave of innovation: synchronous composability.

Self Protocol provides privacy-preserving Proof of Humanity and identity verification through its zero-knowledge infrastructure enabling users to prove properties about themselves, such as uniqueness, age, or nationality without revealing underlying personal data. Instead of exposing identity details, users generate attestations simply confirming their eligibility that applications can verify. This ensures users retain custody of their identity while applications receive only what they need to enforce access, compliance, or eligibility.

Today, Self supports 8M+ users with support for biometric government-issued passports and ID cards across 129 and 35 countries, respectively. Self also supports onboarding via the Indian Aadhaar, used by 99% of the adult Indian population, making it one of the most widely accessible identity systems globally.

What’s next

The Human Appchain is the easiest way to experience how privacy-preserving Proof of Humanity works natively within an appchain.

This launch is only the first step. Verified human identity will increasingly underpin stablecoins, DeFi, consumer applications, and compliance-ready onchain experiences. Appchains combined with synchronous composability bring these capabilities to users through seamless, unified experiences.

If you’re building on Ethereum and exploring appchains, identity, or synchronous composability, contact us.

The Execution Layer Cost Crisis

While blob fees get the attention, the reality is that for rollup operators the execution layer gas costs are currently the bulk of the cost for running most rollups.

Blob fees are such a small part of the cost to advance a rollup that EIPs are being created to keep them from dropping too low and multiple proposals have been made to modify their pricing in order to improve Ethereum’s economics.

Anders Elowsson 🌻

@weboftrees

Apples of the Infinite Garden: A Children's Book on EIP-7918

Audrey the Auctioneer, Pontus the Ponderer and Therese the Tree Tender have started an apple orchard in a huge garden. The friends have a vision: feeding the world with apples. Let's follow them on their journey

129

5:23 AM • Apr 25, 2025

This cost impacts blob submission rate and therefore the time-to-finality and time-to-withdrawal for users on L2s. The following thread shows how Scroll has 7x’ed their time-to-finality likely because blob submission costs are too high to justify posting blobs more often.

donnoh.eth 💗

@donnoh_eth

to give a concrete example, @Scroll_ZKP recently switched from posting a proof every 30 minutes on average to 3h 30min (x7) on average, because not sustainable. slot times from 12s to 6s is an insignificant improvement in this context

5

11:55 AM • Jun 21, 2025

Current Reality: Each rollup pays full execution costs for their individual blob submissions.

The Numbers: You can see a breakdown of the costs of blob submission for Taiko in the dune query below.

Taiko, at the time of this post, sees an average of ~$20k/week in total blob transaction costs since Pectra. i.e. On a weekly average rollups spend ~99.999% of their total blob submission costs on execution layer transactions alone.

Looking at the data for the week of 2025-06-09 Taiko paid $21,101.58 in total fees, with less than a cent going specifically to the cost of blobs and everything else going to execution layer costs.

This means rollups are spending tens of thousands of dollars on transaction overhead rather than data availability.

The Blob Aggregation Revolution

Blob aggregation helps to solve both blob AND execution layer costs. When multiple rollups can submit blobs using the same L1 transaction the 21k min gas cost is only paid once and the cost can be split across the rollups participating in the aggregation. For Taiko that 21k gas cost is still ~$2k/week. If those transactions were paired with another rollup’s that would be ~$4k/month in savings or the ability to post blobs more often and halve the time-to-finality for the chain. If we had 10 rollups all posting together that 21k in gas would cost ~$200/week with $7,200/month in savings.

Of course, this is only a baseline savings estimate for execution costs. When blob pricing EIPs land on mainnet and/or blob saturation is reached the savings will be even greater.

Conclusion

The execution layer cost savings from blob aggregation represent a fundamental shift in rollup economics. By eliminating redundant transaction overhead rollups can achieve significant cost reductions to improve their profitability while improving reliability and user experience at the same time.

Don't miss out! Register now through our sign-up form to secure your place for our mainnet launch and start saving on execution costs immediately!

Blob aggregation does not modify the original data submitted by rollups, so their KZG commitments remain valid post-aggregation—as long as the data can be losslessly recovered.

Background

EIP-4844 blobs have a fixed size of 128KB. Because this data is too large to pass around, a lighter commitment to the blob data is calculated and used for blob verification. KZG commitments allow validators and nodes to efficiently prove that some data (like a blob) exists and has not been altered, without actually transmitting or storing the full data on-chain.

But this begs a question, what happens to a blob’s KZG commitment when it is aggregated into a shared blob? In short, the answer is that nothing happens to it. Nothing happens to the blob’s data during the aggregation process that would alter it’s KZG commitment after it has been unpacked.

To understand why this is, we need to look at how data is encoded into a blob, and how KZG commitments are calculated. Blobs in EIP-4844 have a fixed length of exactly 4096 field elements, each field element being 32 bytes, thus totaling 128KB.

KZG Commitments operate on a polynomial constructed from these 4096 fixed-size field elements, not on arbitrarily sized data directly, so if a rollup’s original data is smaller than 128KB, it must first pad or encode the data to exactly 128KB before calculating the KZG Commitment. This is what libraries like alloys-rs do when encoding data into EIP-4844 blobs.

The point to keep in mind is that blob encoding and kzg commitment computation are both deterministic processes. So long as the input rollup data doesn’t change, the kzg commitment won’t change. And as we’ll see, the aggregation/deaggregation process does not mutate the original rollup data.

Example

Overview

We’ll walk through a simple code example using the open source alloys crate, which is what reth uses internally for its eip4844 support.

In this example, we’re going to take two data strings:

let string1 = “Transaction data from Rollup 1”

let string2 = “Transaction data from Rollup 2”

we’re then going to “blobify” these strings individually, and calculate their kzg commitments. We’ll then do a very basic form of aggregation by concatenating them, blobifying the concatenated data, and then reverse that process to show that the kzg commitment stays intact.

Walkthrough

We start with some simulated rollup data, and convert it into bytes:

let rollup_1_data = "Transaction data from rollup 1";
let rollup_2_data = "Transaction data from rollup 2";
let rollup_1_data_len = rollup_1_data.len();
let rollup_2_data_len = rollup_2_data.len();

let rollup_1_data_bytes = rollup_1_data.as_bytes();
let rollup_2_data_bytes = rollup_2_data.as_bytes();

Next, we use alloy’s SimpleCoder and SidecarBuilder to encode each rollup’s data into a 128KB blob, and retrieve its KZG commitment:

let mut rollup_1_blob_builder = SidecarBuilder::<SimpleCoder>::new();
rollup_1_blob_builder.ingest(rollup_1_data_bytes);

let rollup_1_sidecar: BlobTransactionSidecar = rollup_1_blob_builder.build()?;

let rollup_1_blob = rollup_1_sidecar.blobs.get(0).ok_or("Sidecar1 has no blobs")?;
let rollup_1_commitment = rollup_1_sidecar.commitments.get(0).ok_or("Sidecar1 has no commitments")?;

We do the same for rollup two as well. It’s worth noting these two KZG commitments, as these are what the rollups would keep track of.

Next, we “aggregate” the rollup data by concatenating the raw bytes for the original rollup data strings (not the blob-encoded versions of these strings)

let mut aggregated_data_bytes = Vec::new();
aggregated_data_bytes.extend_from_slice(rollup_1_data_bytes);
aggregated_data_bytes.extend_from_slice(rollup_2_data_bytes);

We then go through the process of encoding this aggregated data as a blob, and calculating its KZG commitment. Note that this “aggregated” KZG commitment is not of much use to us in this example, although it will be different that either rollup 1 or rollup 2’s individual KZG commitments.

Finally, we deaggregate the aggregated blob by stripping it of its blob encoding, and manually parsing the bytes for rollup 1 and rollup 2

    let mut coder = SimpleCoder::default();
    let decoded_data = coder.decode_all(&[owned_aggregated_blob])
        .and_then(|v| v.into_iter().next())
        .ok_or_else(|| eyre::eyre!("Failed to decode or find data in aggregated blob"))?;
    
    let decoded_data_str = String::from_utf8(decoded_data)?;

    println!("Decoded Data: {}", decoded_data_str);
    // prints out Decoded Data: Transaction data from rollup 1Transaction data from rollup 2

    // We know the lengths of the original data, so we can split the decoded data into the two original strings
    // In reality, aggregated blobs encode offsets and lengths into a common header format
    let rollup_1_data_after_aggregation = decoded_data_str[..rollup_1_data_len].to_string();
    let rollup_2_data_after_aggregation = decoded_data_str[rollup_1_data_len..].to_string();

    println!("Rollup 1 Data After Aggregation and Decoding: {}", rollup_1_data_after_aggregation);
    println!("Rollup 2 Data After Aggregation and Decoding: {}", rollup_2_data_after_aggregation);

we now have the original string data that the rollups submitted. If this were transaction data, the rollup nodes could begin running it through the rest of their derivation pipeline. As a last step, we re-encode each string as a blob so we can calculate its KZG commitment, and confirm that it hasn’t changed since the rollup initially submitted it.

    // Now, let's encode the two original strings back into blobs and verify the KZG commitments
    let mut rollup_1_blob_builder = SidecarBuilder::<SimpleCoder>::new();
    rollup_1_blob_builder.ingest(rollup_1_data_after_aggregation.as_bytes());

    let rollup_1_sidecar: BlobTransactionSidecar = rollup_1_blob_builder.build()?;

    let rollup_1_blob = rollup_1_sidecar.blobs.get(0).ok_or("Sidecar1 has no blobs")?;
    let rollup_1_commitment_after_aggregation = rollup_1_sidecar.commitments.get(0).ok_or("Sidecar1 has no commitments")?;

    // println!("Rollup 1 Blob After Encoding: {}", hex::encode(rollup_1_blob));
    println!("Rollup 1 Commitment After Encoding: {}", hex::encode(rollup_1_commitment));

    let mut rollup_2_blob_builder = SidecarBuilder::<SimpleCoder>::new();
    rollup_2_blob_builder.ingest(rollup_2_data_after_aggregation.as_bytes());

    let rollup_2_sidecar: BlobTransactionSidecar = rollup_2_blob_builder.build()?;

    let rollup_2_blob = rollup_2_sidecar.blobs.get(0).ok_or("Sidecar2 has no blobs")?;
    let rollup_2_commitment_after_aggregation = rollup_2_sidecar.commitments.get(0).ok_or("Sidecar2 has no commitments")?;

    // println!("Rollup 2 Blob After Encoding: {}", hex::encode(rollup_2_blob));
    println!("Rollup 2 Commitment After Encoding: {}", hex::encode(rollup_2_commitment));

    // assert that the commitments are the same before and after aggregation
    assert_eq!(rollup_1_commitment, rollup_1_commitment_after_aggregation);
    assert_eq!(rollup_2_commitment, rollup_2_commitment_after_aggregation);

Full Code:

GitHub - spire-labs/kzg-commitment-example

Contribute to spire-labs/kzg-commitment-example development by creating an account on GitHub.

https://github.com

Conclusion

We’ve seen that aggregation preserves a rollup blob’s original KZG commitment, so long as the aggregation process doesn’t irreversibly alter the rollup’s data in any way.

Final Thoughts

If your an L2 and want to save costs on Ethereum DA without code changes get started with us now https://spire.deform.cc/DABuilder/

Understanding Blob Aggregation

Blob aggregation intelligently packs multiple Ethereum transactions into a compact, space-efficient unit—potentially spanning multiple blobs.

Ethereum’s blob space is limited. Competing transactions need to be packed in a way that maximizes utilization. Blob aggregation helps by grouping transactions to reduce overall gas costs, with additional savings from amortizing base costs across the group.

Think of it like a version of the “knapsack problem”—how do we fit a set of transactions into limited blob space while maximizing efficiency and minimizing cost?

How Blob Transactions Are Priced

Blob transactions consist of three fee components:

• Blob Base Fee

• Transaction Base Fee

• Priority Fee

The first two are set by the Ethereum network. Only the Priority Fee is user-defined, making it the key mechanism for signaling urgency and inclusion preference.

The Core Pricing Dilemma in Aggregated Blobs

What happens when different transactions in an aggregated blob have varying willingness to pay? How do we fairly divide the shared cost of the blob space?

Enter Shapley Values - a concept from cooperative game theory used to distribute costs (or rewards) fairly among participants based on their marginal contribution to the group.

Our Pricing Approach at Spire

At Spire, we are exploring ways to dynamically price blob usage and transaction costs, then calculate each transaction's marginal utilization. This results in a pricing model where:

• You always pay less than you would in isolation

• Costs are distributed fairly based on declared willingness to pay and actual usage

• Fast inclusion is guaranteed by setting the group’s priority fee to match the highest participant’s

The result is a system optimized for maximum inclusion and minimal latency, without undercharging smaller contributors.

Benefits of Fair Aggregation Pricing

Fair and efficient blob pricing enables:

• ✅ Reduced transaction costs by sharing gas across many participants

• ✅ Fairer pricing mechanisms using transparent, marginal-impact-based calculations

• ✅ Fast inclusion for lower-fee users, and cheaper fees for higher-fee ones

As we continue to iterate, we aim to improve fairness and efficiency to support long-term scalability and economic sustainability.

📊 Example: Shapley Value Cost Allocation

Let’s walk through a simplified example (excluding Blob Base Fee and Transaction Base Fee for clarity):

Transaction A

• Priority Fee: 2 wei

• Uses 50% of a blob

• Standalone gas cost: 42,000 wei

Transaction B

• Priority Fee: 1 wei

• Uses 50% of a blob

• Standalone gas cost: 21,000 wei

If included together, the total cost remains 42,000 wei, thanks to shared intrinsic gas savings.

To calculate Shapley Values, we look at all possible orderings in which transactions could be added and compute each transaction's marginal contribution to the total cost. We then average those contributions across all permutations. This ensures each participant pays an amount that reflects their impact on the collective cost.

Using Shapley Value cost sharing we allocate costs as:

• Transaction A pays: 31,500 wei

• Transaction B pays: 10,500 wei

• Total: 42,000 wei

📈 Outcome: Both users pay less than they would individually, while still benefiting from top-priority inclusion. Efficiency meets fairness.

Looking Ahead

This pricing model aligns with Ethereum’s long-term vision for modular scalability, economic sustainability, and equitable resource distribution. As rollups and blobspace continue to take centre stage in Ethereum’s execution landscape, fair aggregation pricing will be critical to ensuring healthy, sustainable network growth.

This is just the first iteration. As the ecosystem evolves and new dynamics emerge, we’ll revisit and refine the underlying game mechanics. Our goal is to stay ahead of the curve—continuously exploring how to make blob packaging on Ethereum as fair and efficient as possible.

This post breaks down what it is, why it matters, and where we’re headed next.

Synchronously composability is unlocked

A “based L3” is an appchain that is sequenced by underlying L2 — no centralized sequencer, no additional trust assumptions. This enables something powerful: synchronous composability with L2, just like a smart contract on L2.

In this demo, the based L3 appchain is synchronously reading data from its L2. This may seem simple, but the implications are significant. As an example, our demo utilizes oracle data from L2 at no cost while still gaining the benefits of running an appchain.

In the future, based L3s can natively tap into liquidity and users on L2. Furthermore, users can access L3 directly from L2 without bridging assets. The typical problem of appchains is isolation, but synchronous composability will solve this.

But isn’t running a chain heavy and expensive?

Not for based L3s!

Compared to common L3s today, based L3s offer lightweight operations. As L2 handles sequencing, there’s no need for a centralized sequencer. This dramatically reduces DevOps overhead.

In addition, based L3s won’t even need an additional explorer. Transactions are visible and verifiable via L2 — just like a smart contract on L2.

As you can see, based appchains break the traditional trade-offs. You get the benefits of appchains (scalability, customization, sovereignty) while still maintaining composability and lightweight deployment.

The future - levels of synchronous composability

With this demo, we’ve reached synchronous composability level 1 — synchronous reading from L2.

Soon we aim to reach higher levels of synchronous composability where using a based L3 feels indistinguishable from a smart contract on L2 — both for users and developers.

• L3 reads L2

This can saves appchains millions of dollors of infrastructure costs. For example, oracle, explore, sequencer devops cost.

• L2 reads L3

L3 can natively tap into liquidity, smart contracts, and users on L2.

• L2 <> L3 <> L3 reads and writes

Users can interact with L3 directly from L2 without needing to bridge assets — eliminating the bridging user experience friction.

We will apply features of this technology to work between L2 and L1. This means the demo isn’t just about L3s. It previews an onchain world where millions of appchains operate in sync and are secured by a single unifying network: Ethereum.

Try out the demo of based L3. If you're interested in building appchains or based rollups, come talk to us!

Live demo: https://frontend.l3testnet.spire.dev/

At Spire Labs, we've been exploring a new approach to this problem with Based Rollups. As part of this journey, we're releasing our Based Stack. It's a fork of the OP Stack designed for deploying "based rollups" that inherit Ethereum's decentralisation and security guarantees without compromising on scalability or developer experience.

Two big primitive we've delivered in our based-stack is Sequencer Elections. We've tackled this by focusing on two key areas

🧾 Election Tickets

⏳ Dutch Block Auction

Together, they form a market-driven, permissionless sequencing mechanism where anyone can win the right to produce a block on the rollup and submit it to Ethereum L1.

Most rollups use a single operator to sequence transactions. The ones that don't usually use a permissioned set of sequencers and have some form of round-robin BFT consensus. This allows fast block times and UX improvements, but creates serious downsides:

• Censorship risk: Users are stuck if the sequencer refuses to include certain transactions.

• MEV extraction: A centralised sequencer can reorder transactions for profit.

• Trust assumptions: Users must trust an off-chain actor to behave honestly.

To fix this, we need decentralised sequencing — where many actors can compete to build and submit blocks, and no single party has control.

The Based Stack introduces a novel mechanism to the L2 block-building process: the Dutch Auction!

This permissionless auction determines who gets the right to participate as a sequencer in future blocks.

Here's how it works:

• The auction begins at a high bid price with 32 sequencing slots for sale.

• Each block, the price decreases at configurable decay rate.

• Anyone can call the auction contract to buy up to the remaining tickets, locking in their right to build one or more future blocks at the current price they pay.

• Once purchased, that holder becomes eligible to propose a block.

• When the auction ends, soulbound NFTs are minted as election tickets to the participants who purchased tickets.

The auction decides who gets to be in sequencer pool.

Election Tickets are tokenised rights to participate in sequencing, tightly integrated with the auction mechanism.

• The slot winners are chosen from the pool of ticket holders every epoch.

• Winning election tickets are burnt.

• The winner should submit a block for the slot they win.

• In the future, misbehaviour (like submitting an invalid block) can lead to slashing of a staked ticket.

These tickets form the backbone of trustless sequencing in the based stack. You can prove on-chain that you earned the right to submit a block. The system can enforce rules and incentives (e.g., slashing, rewards, or rebates). They unlock game-theoretic participation, as participants strategise around ticket pricing, auction timing, and MEV opportunities.

This also opens the door to further decentralisation. DAOs could subsidise ticket purchases to promote public goods infrastructure or specific applications. We belive that a liquid, permissionless market for sequencing rights will emerge on top of Ethereum. This structure enables MEV builders and relayers to engage in a secondary market with election winners.

The election process chooses when they can sequence.

In Ethereum's L1, miners and validators compete in an open blockspace market. The Based Stack brings this ethos to L2 with election-based sequencing.

For us, the table stakes for a based rollup is one where:

• Anyone can become a sequencer through open participation.

• No entity controls ordering rights long-term.

• Consensus remains minimal, with Ethereum still securing data availability and settlement.

The Dutch auction with election ticket model is a novel mechanism for enabling this. It's simple, modular, and aligned with Ethereum's values.

The initial implementation is open source and available in our github repo. If you’re launching a rollup, rethinking L2 decentralisation, or exploring new sequencing designs, we want to build with you.

Got ideas? Questions? Drop us an email or fill out this form to get building!

As rollup ecosystems evolve, a new frontier is emerging — L3s built on top of existing L2s. This post explores how Spire’s approach, which combines shared settlement and coordinated sequencing, can extend beyond L2s, enabling rollups to function as synchronous execution environments. This architecture extends beyond traditional rollup sequencing models, offering faster, customizable intra-block execution while remaining backward compatible with existing L2 rollups.

Current rollup architectures create isolated liquidity islands, where appchains operate independently with separate sequencers and settlement layers. This fragmentation leads to:

• Capital inefficiency – Liquidity pools are confined to individual appchains, reducing capital utilisation.

• Delayed execution – Cross-rollup transactions require bridging or asynchronous settlement, introducing latency and reducing DeFi composability.

• Fragmented price discovery – Markets across different rollups lack synchronization, creating inefficiencies in pricing and execution.

• Cross-domain execution risk – Transactions spanning multiple appchains must be executed optimistically, increasing the likelihood of failure with the loss of atomicity.

These inefficiencies make it challenging to build low-latency, high-frequency applications that require synchronous settlement and atomic execution across multiple chains.

Spire solves this problem by introducing shared settlement and coordinated sequencing, eliminating liquidity islands and enabling seamless intra-block composability.

Spire extends sequencer design by introducing (1) Shared Settlement + (2) Coordinated Sequencing:

Instead of settling transactions in isolated rollup environments, Spire enables shared sequencing across L3 appchains.

• Appchains submit transaction bundles to a shared sequencer rather than operating in isolation.

• Batch execution enforces synchronous composability, ensuring all transactions within a batch either execute atomically or revert.

• Optimistic atomicity allows users to receive preconfirmations for execution before final settlement.

This architecture preserves independent appchain logic while leveraging L2 settlement guarantees, reducing fragmentation and improving execution reliability.

Spire enables programmable sequencing, allowing transactions to be dynamically ordered within a batch.

• Optimistic atomic execution ensures interdependent transactions execute in the same batch.

• Custom priority rules let appchains control ordering, execution fees, and failure handling.

• Sequencer marketplaces allow applications to select execution models that optimize for cost, latency, or MEV strategies.

These mechanisms enhance intra-block composability, delivering low-latency, deterministic execution across L3s.

A key innovation in Spire is forward sequencing, which enables execution preconfirmations. L3 sidecars can commit to transaction inclusion before final L2 settlement. Users receive execution guarantees based on real-time fee estimation and state simulation. Sequencers dynamically adjust execution order to minimise contention and optimise gas fees.

This model unlocks optimistic execution guarantees that reduce execution risk while maintaining synchronous composability.

To support next-gen modular execution, Spire provides:

• Extensible Sequencer Architectures – Customizable sequencing for L3 appchains.

• Composable EVM Execution – Full EVM compatibility for cross-appchain transactions.

• Preconfirmation APIs – Transaction simulation and execution guarantees.

• Optimistic Settlement Models – Seamless integration with L2 rollups and sidecars.

Spire’s shared settlement + coordinated sequencing model transforms how appchains interact, offering:

• Atomic execution across appchains

• Low-latency composability with deterministic ordering

• Preconfirmations for faster execution and reduced risk

• A marketplace of sequencers for customizable transaction processing

We're building the next generation of modular execution infrastructure and invite app developers to explore the L3 Based Stack. If you're looking to launch an appchain, join us in shaping the future. Send a DM on X or an email to get started!

Introduction

As appchain adoption grows, there will be an increasing need for chains to opt-into having their blobs aggregated and compressed with blobs from other appchains. Aggregation carries the following benefits:

• appchains can submit transactions to their chosen DA layer more frequently. They no longer need to wait to have enough transaction data to fill a blob before submitting, or pay the cost of submitting partially filled blobs.

• appchains can use blobspace more efficiently, particularly chains with lower tx volume.

• appchains no longer have to worry about scenarios where an L1 block runs out of available blob slots, as their blobs will be aggregated with other appchains.

In addition to aggregating blobs, this would allow appchains to specify additional parameters such as which DA layers they support, which data compression schemes they use, which L1 block they are targeting, and how they choose to update their state. In this post, we explore some possibilities for what a specification would look like.

We don’t intend for this to be a single implementation that all appchains must use. The goal is to create a neutral specification to enable general access to shared blob compression and aggregation. As Spire heavily supports the growth of appchains, we may provide an implementation of this specification to appchains running on Spire.

Appchains wishing to opt into this design can define a list of DA layers, compression schemes, and other fields that they support via json. This format is flexible, and the json can be converted to a binary or uri representation as needed.

For example:

{
		"chain_id": "123", 
    "capabilities": {
        "da_layers": [
            "beacon", "altda1", "altda2"
        ],
        "compression_schemes": [
            "gzip"
        ],
        "shared_state": false, // indicates whether or not the appchain will run its own nodes and derivation pipeline.
        "uniform_blob": false, // indicates whether or not the appchain wants to be in its own blob or a shared blob
        "target_block": 1234567, // The L1 slot in which the appchain’s blob data must be published. This might need to be specified elsewhere
        "tip": 5 gwei // A way for appchains to prioritize inclusion of their blobs in times of high aggregation requests.
    }
}

TBD. This is the information required to retrieve a unit of blob data. Fields may include:

• target DA

• compression scheme

• data length

• data offset

• chain_id/namespace

The layout of an aggregated blob could be a namespaced merkle tree (NMT), with chunks of individual blob data at the leaves, along with a rollup identifier as a namespace. NMTs provide some guarantees that the contents of the blobs will not have been forged.

An alternative approach could use a flat structure with lengths and offsets.

For context, here is a brief overview of how blobs currently work in rollups like Optimism.

Blobs are fetched from the consensus layer in the derivation step of each rollup using the GetBlobSidecars method of the L1 beacon client.

What follows is a hypothetical design of how appchains/rollups could opt in to using a blob aggregator service. After initially registering with the service by sending the above JSON data and receiving a rollup id, blob data could be sent to the aggregator:

In this design, a rollup would:

1. Send their blob data to the off-chain aggregator service, along with commitments to each blob, their rollup/chain-id, supported compression schemes, target DA layer, target L1 block, and potentially some other fields.

2. The aggregator service would then sort incoming blobs by size, target DA, compression scheme, etc. Implementation details can vary.

3. The aggregator service concatenates blobs targeting the same DA into a “super blob”, and generates and stores a NMT for allowing rollups to quickly identify their blobs within the super blob via their rollup-id.

4. The super blobs are sent to their respective DA layers via sidecars. L1 transactions targeting the Blob Aggregator’s inbox contract w/commitments to the super blobs are sent to the L1. Note that it may be necessary for the aggregator to obtain some sort of preconf at this stage, if rollups have specified a target L1 block.

5. Rollups update their state (e.g. derivation pipelines, etc) to recognize batch transactions or proofs coming from the aggregator service address. Blob data relevant to the rollup is fetched from the super blob, either by the rollup itself, or using some endpoint provided by the aggregator service

6. Rollups are responsible for providing a mechanism for confirming that the retrieved blob(s) match the ones they originally sent. For example, providing a commitment to a blob that can be verified with a public key. Additional confirmations may be required. For example, based rollups may need to confirm that the original L2 data in the blob was sequenced by the correct election winner for the L1 block, etc.

7. Rollups then use the unpacked data to update their state and advance the canonical derivation.

This specification places no restrictions on which types of compression are supported. Appchains are free to choose between file and streaming compression schemes.

We assume one compression scheme per root DA specification address.

TBD. One approach could be to simply always select the largest blob that will fit in the remaining space for the current blob.

Given an aggregated blob, appchains are able to efficiently verify and retrieve the sections of the aggregated blob relevant to them using namespaced merkle trees. Espresso uses a similar approach to allow individual rollups to easily derive their blocks from a shared stream of HotShot blocks [ref]. Every appchain will have a unique appchain-id which serves as a namespace identifier.

This specification defaults to using Ethereum’s beacon layer for blob DA. However, rollups are free to choose an alternative DA layer if they need to support faster and cheaper DA not bound to the L1’s fixed block time.

TBD. Fees could be distributed proportionally over rollups based on the percentage of a given blob that they use.

This specification is designed to be extensible. A future extension could involve sending encrypted blobs to help with fair-exchange problems with preconfers.

• Sample implementation of blob aggregation from EthGlobal Istanbull [ref]

• HackMD paper on blob sharing [ref]

• Dankrad’s paper on shard blob header format [ref]

• References to how Espresso enables easy namespace access to rollups [ref] [ref]

Get the latest from Spire:

• X(Twitter): https://x.com/Spire_Labs

• Website: https://www.spire.dev/

• Docs: https://docs.spire.dev/