A transaction bundle is a single user-facing transaction that contains and atomically executes multiple onchain operations — approve, swap, deposit, and bridge — under one signature. Bundles let a wallet collapse what used to require five or six discrete signatures into one signing event, shifting the burden of orchestration from the user to the smart account and its supporting infrastructure. Biconomy SuperTransactions are one of the more visible implementations of this pattern, and they sit at the intersection of ERC-4337 account abstraction, EIP-7702 EOA upgrades, and the ERC-7579 modular account standard.
​

This article explains what transaction bundles are, how they work under each of the major standards, how Biconomy SuperTransactions extend raw ERC-4337 UserOperations, and where bundles fit in real DeFi flows like approve-plus-swap, deposit-claim-repay, and gasless onboarding. It also covers cross-chain bundles and the trade-offs that come with depending on bundler infrastructure.
​

A transaction bundle is a list of calls — each with a target contract, calldata, and value — packaged together so that a smart account executes them in a single onchain transaction. The user signs once. The account contract loops through the calls and executes each one in sequence. If the account is configured for atomicity, a revert on any call reverts the whole bundle. The result is that the user sees one signing prompt and one final state, instead of five separate confirmations and five intermediate states.
​

Bundles are not new as a concept. Safe (formerly Gnosis Safe) has shipped a MultiSend contract since 2018 that batches calls inside a single transaction. What changed in 2023 and 2024 is that bundles became a first-class user-facing feature: ERC-4337 standardized smart-account UserOperations that carry multi-call payloads, EIP-7702 let regular EOAs temporarily install code so they can batch too, and ERC-7579 defined a modular account interface that wallets like Biconomy, ZeroDev, and Rhinestone all implement.
​

The benefit is concrete. Approving USDC and then swapping it on Uniswap previously required two signatures and two onchain transactions. With a bundle, the user signs once and pays gas once, and the protocol never sees the intermediate "approved but not swapped" state. Etherscan still shows one transaction; the bundle's internal calls appear as internal transactions.
​

Under the hood, a bundle requires a smart account — a contract that can hold funds and execute arbitrary calls. The account exposes an execute or executeBatch entry point that takes an array of (target, value, data) tuples. The user signs a structured message authorizing the batch. A bundler or relayer submits the signed payload onchain. The account verifies the signature, loops through the calls, and either executes them atomically or returns a list of outcomes.
​

The signature step is the part that feels different to end users. In a bundle, the wallet displays one EIP-712 typed-data object that lists every call, every target, and every value. The user reads what they are about to do once. Compare that to the legacy flow, where each step prompts a separate signature with a separate gas estimate and a separate chance for the user to give up.
​

Three standards govern how bundles are signed and executed today, and they overlap in important ways:

For the canonical reference on how the modular account interface composes with bundles, see the article on ERC-7579 and the modular smart-account standard.
​

The four most relevant specifications for transaction bundles each solve a slightly different problem. Understanding the lanes makes it easier to read any given vendor's marketing.
​

ERC-4337 is the account abstraction standard that ships smart accounts without changing the Ethereum protocol. It introduces the UserOperation struct, the EntryPoint singleton contract (deployed at 0x0000000071727De22E5E9d8BAf0edAc6f37da032 on Ethereum), and the bundler role. A UserOperation can carry batched calldata, so a single user signature authorizes any sequence of calls inside the smart account.
​

EIP-7702 activated as part of the Pectra upgrade in May 2025. It defines a new transaction type (SET_CODE_TX_TYPE = 0x04) that lets an externally owned account specify a delegate contract. For one transaction, the EOA's address can run smart-account code, including executeBatch logic. After the transaction, the EOA returns to default behavior. EIP-7702 closed the upgrade-path gap for the hundreds of millions of existing EOAs that did not want to migrate to a fully separate smart-account address.
​

ERC-7579 standardizes the smart-account interface itself. An ERC-7579 account must expose execute(bytes32 mode, bytes executionCalldata), where the mode encodes whether the call is a single, a batch, or a delegate-call. The standard also defines four module types — validators, executors, hooks, and fallback handlers — so that a wallet can mix and match modules without forking the core account. Biconomy's Nexus account, ZeroDev's Kernel, and Rhinestone's reference implementation all conform.
​

Safe's MultiSend contract pre-dates ERC-4337 and remains the most battle-tested bundle primitive in production. A Safe owner constructs a payload containing a list of operations, calls MultiSend.multiSend(payload), and the contract loops through and executes each one. Safes have used this since 2018 to handle treasury operations like batched payouts, multi-hop swaps, and DAO governance settlements.
​

Biconomy SuperTransactions are a productized UX layer that builds on ERC-4337 UserOperations and ERC-7579 modular accounts to let a single user signature carry instructions across multiple chains. The data structure is a recursive Merkle tree where each leaf is either a concrete transaction (target, calldata, value, chain) or an intent that a solver fulfills against. The whole tree hashes to one digest. The user signs the digest. Biconomy's Modular Execution Environment (MEE) validates the signature and dispatches the relevant leaves to the appropriate chains.
​

Where SuperTransactions extend raw ERC-4337 is in three places. First, the Merkle-tree structure makes a single signature authoritative across many chains, not just one. A standard 4337 UserOperation lives on one chain. A SuperTransaction can carry one leaf for Base, two for Arbitrum, and one for Optimism, and the user signs once. Second, SuperTransactions support hybrid execution: some leaves are exact calls and others are intents that the MEE network resolves competitively. Third, the MEE handles paymaster orchestration and gas abstraction so the user pays once, in any token the paymaster accepts, regardless of how many chains the bundle touches.
​

SuperTransactions inherit ERC-4337's bundler model on each chain. The chain-level bundlers still validate and submit UserOperations to the local EntryPoint. The MEE sits above them, providing the cross-chain signature aggregation and intent resolution that ERC-4337 alone does not specify.
​

Biconomy is one of several vendors shipping production transaction bundles today. The implementations differ in module philosophy, bundler integration, and target audience.

Bundles unlock UX that was previously gated by the multi-signature dance. The categories below are the ones that show up most often in production traffic.
​

The most common bundle is approve-plus-swap. A user wants to swap USDC for ETH on a DEX. Without bundling, the wallet first prompts an approval transaction, the user waits for inclusion, and then prompts a second swap transaction. Inside a bundle, both calls execute in one onchain transaction. Uniswap's Universal Router handles this through a contract-level batching mechanism, but bundle-aware wallets get the same outcome with one signature against any DEX.
​

A user borrowing on Aave V3 might want to deposit USDC as collateral, claim accumulated rewards, and repay a portion of an outstanding debt — three calls into different contracts. With a bundle, the user signs once. With Aave V3 carrying $13.8 billion in TVL, this kind of multi-call interaction is the norm rather than the exception for serious users.
​

A bundle can include a paymaster instruction that lets a third party sponsor gas. A new user arriving at a dApp with no ETH can sign a bundle that mints them an NFT and then transfers ownership, with the dApp's treasury paying the bundler. This pattern is the default for consumer-facing apps targeting non-crypto-native audiences.
​

For NFT drops, a bundle can mint multiple tokens in one signature, lowering the per-mint friction. For recurring payments — payroll, subscriptions, vendor settlements — a bundle can authorize many transfers in one transaction, with the smart account enforcing per-recipient limits via ERC-7579 hooks.
​

To make the abstraction concrete, consider a SuperTransaction that bundles three operations across two chains: approve USDC on Base, swap USDC for ETH on Base, and bridge a portion of the resulting ETH to Arbitrum. The user signs one structured payload that looks roughly like the following pseudocode (real Biconomy SDK code is more verbose):

The wallet displays a typed-data prompt summarizing all three calls. The user signs the Merkle root. The Biconomy MEE forwards leaves 1 and 2 to a Base-chain ERC-4337 bundler, which submits the UserOperation through the Base EntryPoint contract. Leaf 3 is broadcast to the MEE's solver network, where solvers compete to bridge the ETH and deliver it on Arbitrum. The user sees a single transaction in their activity feed, with internal substeps tracked by the MEE explorer.
​

What the user signs is not a sequence of low-level calls, but the intent to reach a final state. What executes onchain is a deterministic series of contract calls plus an intent-fulfillment leg that the solver network optimizes for cost and speed. The signing surface and the execution surface are deliberately decoupled.
​

Cross-chain bundles introduce a new problem: the signature must be valid on every destination chain. ERC-4337 alone cannot solve this — a UserOperation lives on one chain. Several extensions and proposals address the gap.
​

ERC-7964 cross-chain signatures define a structured signature format that smart accounts can verify on any chain where they are deployed at the same address. SuperTransactions use a similar pattern internally — the Merkle root is signed once, and each chain's account contract verifies the same digest. Other approaches include LayerZero's lzCompose and Hyperlane's Interchain Accounts, both of which let a contract on one chain authorize execution on another chain through a cross-chain message.
​

For stablecoin orchestration in particular, cross-chain bundles compose well with intent-based routing. A bundle can include an intent leaf — "deliver $X of USDC on chain Y" — and let a solver network handle the execution path. Eco Routes selects between CCTP, Hyperlane, and other rails based on cost and finality, which lets a bundle author skip the routing decision entirely.
​

Transaction bundles are not free. The complexity moves rather than disappears.
​

Gas estimation gets harder. A bundler must simulate the full call sequence to predict gas, and a revert on any leaf invalidates the simulation. ERC-4337 specifies a separate validation phase to bound this cost, but the validation itself takes gas. In practice, a UserOperation on Ethereum mainnet costs roughly 30 to 50 percent more gas than the equivalent EOA transaction would cost, after accounting for the EntryPoint overhead.
​

Bundler dependency is a real centralization risk. Every UserOperation must be picked up by a bundler and submitted onchain. If only one or two bundlers serve a chain, they become a censorship vector. Major bundlers today include Pimlico, Stackup, Alchemy, and Biconomy itself, but the number is small relative to traditional Ethereum block builders.
​

Atomicity is not free either. ERC-7579 supports both atomic and best-effort batch modes. Atomic mode is safer (a partial failure reverts everything) but more expensive. Best-effort mode is cheaper but leaves the user reasoning about which leaves succeeded.
​

Standards fragmentation remains. ERC-4337, EIP-7702, ERC-7579, and ERC-7710 (delegations) all overlap. A wallet that supports one does not automatically support the others. Application developers integrating bundles need to track multiple specifications and the wallet-coverage matrix for each.
​

Bundles solve the multi-signature problem inside one wallet. Cross-chain stablecoin orchestration solves the multi-rail problem outside the wallet. The two compose. A SuperTransaction or a 4337 UserOperation can carry an intent leaf that requests stablecoin delivery on a destination chain, and Eco Routes selects the underlying rail (CCTP, Hyperlane, or another option) based on cost and finality. The user signs once. The bundler executes the local calls. Eco Routes handles the cross-chain stablecoin leg. The compounded UX win is that a payment that used to involve three signatures and two bridges now involves one signature and one final balance change on the destination chain. For developers integrating both layers, the relevant primitives are cross-chain intent protocols on the orchestration side and ERC-7579-compatible smart accounts on the signing side.
​

No. Transaction bundles are the general pattern of executing multiple calls in one signed transaction. Biconomy SuperTransactions are one implementation, layered over ERC-4337 UserOperations and ERC-7579 modular accounts, that adds cross-chain signature aggregation and intent resolution. Safe MultiSend, ZeroDev Kernel, and Coinbase Smart Wallet ship other bundle implementations.
​

Not necessarily. EIP-7702, activated in the May 2025 Pectra upgrade, lets a regular externally owned account temporarily delegate to a smart-account implementation for one transaction. The EOA gets bundle execution without changing addresses. Persistent smart-account migration is still required for advanced features like session keys and multisig recovery.
​

Safe's MultiSend bundles calls inside a single onchain transaction submitted by a Safe owner. ERC-4337 bundles are submitted by a separate bundler role and validated through the EntryPoint contract. The two can compose: a Safe configured as an ERC-4337 account can send UserOperations whose calldata is a MultiSend payload, blending both batching primitives in one transaction.
​

It depends on the execution mode. ERC-7579 defines an atomic mode where any revert reverts the whole batch, and a best-effort mode where each call succeeds or fails independently. Most consumer-facing bundles use atomic mode so users never end up in an intermediate state. Treasury and payroll bundles sometimes use best-effort mode to avoid one bad recipient blocking an entire payout run.
​

Every EVM chain that has an ERC-4337 EntryPoint deployed and at least one bundler. Ethereum mainnet, Base, Arbitrum, Optimism, Polygon, BNB Chain, and Scroll all qualify. EIP-7702 requires the Pectra upgrade, which has shipped on Ethereum mainnet and is rolling out across L2s. ERC-7579 is a wallet-side standard and works wherever a 7579 account contract is deployed.
​