Bundled By Default

How Sonic V2.2 moves atomic execution from workaround to protocol primitive.

Most users do not come onchain to manage transactions. They come to complete an action: swap this token, enter this vault, open this position. The action is one thing. The execution path underneath it is usually several things, stitched together and exposed one step at a time.

That gap between intent and execution is where onchain products break down. Not because the chain is slow, but because the transaction model forces multi-step operations to be treated as a sequence of independent, unrelated events.

Sonic V2.2 changes this at the protocol layer.

The Problem: Partial Execution

Consider three common workflows and what actually happens underneath them today.

Approve and swap. A user wants to trade one token for another. The application needs two transactions: an ERC-20 approval, then the swap. Two signatures. Two confirmations. Two gas charges. If the approval lands but the swap fails (slippage, gas spike, timing), the user is left with an open approval and no trade. They have to return, check what happened, and try again.

Bridge and deposit. A user bridges USDC to Sonic and wants to deposit into a yield venue. Today, bridging and depositing are completely separate operations. The user bridges, waits for the funds to arrive, then manually initiates a second transaction to deposit. Between those two steps, the assets sit idle in a wallet. If the user forgets, gets distracted, or the deposit fails, the funds sit there doing nothing.

Collateral, borrow, refinance. A DeFi user wants to restructure a lending position: repay existing debt, withdraw collateral, supply it to a new market, and borrow against the new position. That is four transactions, each dependent on the one before it. If the repayment succeeds but the withdrawal fails, the user is stuck mid-operation with an unclear position state. If collateral moves but the borrow does not execute, the final exposure does not match the original intent.

In each case, the user wanted one outcome. The execution model delivered a checklist of independent steps where any single failure leaves the result incomplete.

This is not a UX problem that better interfaces can solve. It is a structural limitation of the transaction model. Every EVM chain has it. Smarter frontends can hide the steps behind loading screens and progress bars, but the underlying fragility remains: each step can succeed or fail independently, and no step knows whether the others completed.

Why Existing Solutions Fall Short

The industry has developed several workarounds. Each addresses part of the problem while introducing new tradeoffs.

Account abstraction and smart wallets allow batching at the wallet level, but they require users to migrate from their existing EOA to a new account type with a different security model. Every app, explorer, and tool that interacts with the account needs to understand the new standard. Adoption has been slow because the migration cost is real and the trust model changes.

EIP-7702 delegated account flows let EOAs temporarily delegate execution to a smart contract. This enables batching without full wallet migration, but it introduces a new trust surface: the user is granting execution authority to a contract they may not fully understand. The delegation itself becomes a potential attack vector.

Application-level batching handles coordination in the frontend or through custom smart contracts. This works for individual apps but does not compose across protocols. Each application reinvents its own batching logic, and multi-protocol flows (swap on one DEX, deposit on another protocol) still require separate transactions.

Wallet-level batching depends on each wallet implementing its own bundling. Coverage is inconsistent, behavior varies across wallets, and developers cannot rely on it being available.

All of these push the coordination problem upward: into the wallet, into the application, into custom middleware. None of them solve it where it should be solved, at the execution layer of the network itself.

The Solution: Protocol-Level Atomic Bundles

Sonic V2.2 introduces Bundled Transactions as a native protocol primitive. Multiple transactions can be grouped into a single atomic execution plan and processed together by the network. The atomicity guarantee is enforced at the consensus layer, not by a wallet plugin or application workaround.

Here is what that means concretely.

Related transactions can be configured to succeed or fail together. If any transaction in the bundle reverts, the entire sequence rolls back. No partial state. No half-completed positions. No approvals sitting unused while the follow-on action failed silently.

This is different from what smart contracts already provide. Nested contract calls within a single transaction have always supported atomic execution. What Sonic adds is fate-sharing across multiple independent transactions, potentially from different signers. An approval transaction and a swap transaction, each signed independently, can be bound together so that neither can land without the other.

Non-Interleaving

Bundled transactions execute in guaranteed order with no unrelated activity inserted between them. On a standard EVM, transactions submitted sequentially can be reordered by validators or interleaved with other network traffic. This is the mechanism behind most MEV extraction: an attacker's transaction is inserted before or after a target transaction to exploit the price movement.

With Sonic bundles, the execution order within a bundle is locked. Nothing external can be placed between step one and step two. For operations where the result depends on a specific sequence (supply collateral, then borrow against it), this guarantee is structural, not probabilistic.

Every transaction in a bundle must explicitly consent to being part of that specific bundle. Consent is cryptographic: each signer approves not just their own transaction, but the full execution plan that defines the bundle's structure, ordering, and rollback conditions.

This prevents a class of attacks where an adversary bundles a victim's pending transaction with their own. On Sonic, legacy transactions cannot be included in bundles, and bundle-marked transactions cannot execute outside their designated bundle. A transaction either runs as part of the exact plan its signer approved, or it does not run at all.

Composable Execution Plans

Bundles are not limited to simple linear sequences. Sonic supports two execution modes that can be nested:

AllOf (default): Every transaction in the group must succeed. If any fails, the entire group rolls back. This is what you want for approve-then-swap flows where partial execution is worse than no execution.

OneOf: Transactions execute in order until one succeeds. This supports fallback logic: try swap route A, and if it fails, try route B. The first success ends the sequence.

These modes can be nested to express conditional logic. Run transaction A, then try either B or C. If both B and C fail, roll them back but keep A. This enables sophisticated multi-step flows that would otherwise require custom orchestration contracts.

No Migration Required

Bundled transactions work with existing EOA wallets. MetaMask, Rabby, Ledger, Trezor. No smart wallet migration. No new account type. No delegation.

The mechanism uses a standard EVM access list entry to mark transactions as bundle-only. This is compatible with existing signing infrastructure. From the wallet's perspective, it is signing a normal transaction with an additional access list field.

The resulting blocks are fully Ethereum-compatible. Bundled transactions appear as normal transactions in the final block (the envelope is discarded). Existing block explorers, indexers, and analytics tools work without modification.

What This Looks Like in Practice

Take the approve-and-swap example from earlier.

Before V2.2: The application sends an approval transaction. The user signs it. The application waits for confirmation. Then it sends the swap transaction. The user signs again. If the swap fails, the user has an open approval and no completed trade. Two signatures, two gas payments, two points of failure.

After V2.2: The application prepares both transactions, bundles them into an AllOf execution plan, and presents the bundle for signing. The user signs each transaction with the guarantee that neither can execute without the other. The bundle is submitted to the network and processed atomically. Both land, or neither does.

For the lending example: repay, withdraw, supply, borrow. Four transactions, one execution plan, one atomic outcome. The user's position either fully restructures or stays exactly where it started.

How Bundles Compose with Sponsorship

Bundled transactions work naturally with Sonic's gas sponsorship system. A protocol can sponsor gas for an entire bundle, and the sponsorship only activates if the bundle succeeds.

This changes the economics of onboarding. A new user can execute a complex multi-step flow (bridge, swap, deposit) with sponsored gas, and the sponsor only pays if the entire flow completes. Failed bundles cost the sponsor nothing. This makes aggressive sponsorship economically sustainable rather than a calculated risk.

For Builders

Sonic V2.2 provides three RPC methods for working with bundles:

sonic_prepareBundle accepts a proposed bundle and returns sign-ready transactions with the correct execution plan hash embedded in their access lists.

sonic_submitBundle handles envelope creation and network submission.

sonic_getBundleInfo returns the execution status of a submitted bundle: pending, executed (with block number and position), or unknown.

Multi-transaction gas estimation is supported: the gas limit of each transaction in the sequence is estimated based on the state after the preceding transactions execute. Debugging support includes RPC entry points for tracing bundle execution to identify exactly where and why a rollback occurred.

No registration is required. No fund management contracts. No approval workflows. Prepare the bundle, get signatures, submit.

From Transactions to Outcomes

Speed was the first layer. Sonic already settles in under a second.

Bundled transactions are the second layer: making sure that what settles is the outcome the user actually intended, not a partial result they have to clean up.

As more complex financial activity moves onchain (trading, lending, market making, treasury management, autonomous agents), the execution model has to keep up. Operations that depend on order, state, and completeness cannot be treated as a series of independent hopes.

Sonic V2.2 makes atomic multi-step execution a protocol-level default. Not a wallet feature. Not an app-level workaround. Not an account type migration.

Bundled by default.