Why do Supertransactions matter?
What is stopping crypto and wider blockchain usage to skyrocket?
The transaction model is unique to all blockchains that depend on it to move value and data. However, blockchain transactions today are limited in scope, constrained to executing single, siloed operations. This fragmentation leads to poor user experiences, higher costs, and complex developer workflows. Supertransactions eliminate these barriers by enabling seamless orchestration of multi-step operations across chains and protocols in a single, atomic flow.
Traditional transaction structures force users to interact with multiple interfaces, sign numerous approvals, and pay gas fees at every step of the user journey, creating a bottleneck for mainstream adoption. Supertransactions abstract these complexities, unlocking new capabilities for on-chain applications, from cross-chain swaps to multi-protocol interactions.
But Supertransactions are more than just an efficiency upgrade—they fundamentally shift how blockchain ecosystems operate. By enabling hybrid execution, they allow users to specify their desired outcomes while the underlying infrastructure handles the orchestration. This reduces reliance on intermediaries, simplifies UX, and ensures trustless, verifiable operations.
For developers and app builders, the lack of composability across chains has restricted innovation and limited the potential for building truly interoperable decentralized applications. They need to build, maintain and manage complex workflows, rely on centralised providers and delaying their time to market. For L2s and appchains, they do not have access to the wider Web3 user base and they rely on outdated technology for users to find, access and use their chain.
With Supertransactions as a foundational primitive, developers can access users across any chain, find new monetization opportunities and ultimately reimagine possibilities of on-chain applications.
What are Supertransactions?
Well, it goes without saying, it’s better than a normal transaction. A Supertransaction is a data structure containing multiple instructions on actions the user wishes to achieve. It means a user can sign a series of complex multiple operations in one click because Supertransactions natively supports any transaction type supported across any chain. It supports transaction types such as UserOps, Bridge actions, Intents, offchain Oracle triggers, any gas payment and more!
Let’s compare using everyday examples in the real world and the web3 world.
Example: Booking a hotel and flight online.
A Normal Blockchain Transaction:
- You go to one website to search for a hotel.
- Then, you go to another website to compare prices.
- After that, you go to another app to look for flights and another to compare prices.
- Each step requires you to log in, provide your payment details, and compare prices and then approve a series of steps.
Pain Points:
- Tedious process with multiple approvals and actions.
- Each step must succeed independently, or the entire process fails.
Example: Using a travel booking app (like Expedia or Kayak) for booking a trip.
Supertransaction:
- You select a flight, hotel, and car rental in one interface.
- You click "Book Now," and the app handles all the backend orchestration.
- The whole transaction is completed as a single action—you don’t have to interact with each vendor separately.
Advantages:
- Seamless experience with one click.
- Everything either succeeds together or fails together, ensuring consistency.
Let’s take a look at a web3 example.
Example: Staking an asset, but to do this, you have to swap, then bridge and then stake.
A Normal Blockchain Transaction:
- A user has to swap on a separate UI, pay the gas fees
- Then bridge the asset to the chain, pay gas again
- And lastly, stake their assets, pay gas again on that new chain
- Steps 1 and 2 can be done via aggregators, but the user would still need to sign multiple transactions and go to a different UI to stake assets
Supertransaction:
- A user uses an interface - it could be the staking app, a superapp or a wallet and sets what they want to do, in this case stake an asset
- They choose from the asset they want to use
- They sign the transaction paying fees one time and the whole sequence happens in a single action
In this entire flow, the user saves at least 4-5 steps and signatures and saves on fees as the transactions are batched and aggregated. If an intent is used during the transaction, then the user can benefit from near-instant optimisation and lower costs.
Why every chain needs Supertransactions?
Every chain is only aware about its own execution environment and with Supertransactions, it allows them to support a drastically better transaction model that dapps and wallets can utilise, whether the user is interacting only on their chain or cross chain. It’s actually very easy for any chain (EVM and non EVM) to support Supertransactions without any special integration or forks.
There are a few reasons as why chains would benefit from supporting Supertransactions:
- Any chain has the ability to synchronously compose multiple actions into one via the Composability stack. The Composability Stack allows developers to treat multiple blockchains as a single computational surface. Function calls can be seamlessly composed across chains, with outputs from one chain flowing directly into functions on another while maintaining full execution context.
- Chains can benefit from being connected to chains even outside their VM instance
- Chains can access a wider user and liquidity base compared to existing channels today. Additionally, if your chain has support for Supertransactions then developers building on your chain can access liquidity, users and assets on other chains with this being invisible to users
- Chains today need to build their own canonical bridge and integrate 3rd party bridge providers, and whilst this is important, it only solves 10% of the problem. Abstraction in the form of gas, balance and execution does not exist and relies on the dapp and user to figure out. Bridges are explicit and visible, whereas Supertransactions interop is abstracted and implicit thus making it very easy to navigate and explore your chain
- Supertransactions support multiple transaction types which developers on your chain can easily utilise for their use cases. They include instruction types like UserOps, Bridge actions, Intents, offchain Oracle triggers, any gas payment and more, if you want to unwind your position on Aave, to direct your assets into a new protocol with a higher yield on a different chain, you can do it in a single transaction, pay fees only once without ever thinking about the how and knowing that you got the best possible rate and speed.
- Supertransactions can even flourish and complement ecosystems with their own native interop such as Superchain and Polygon Agglayer (more on this in a separate post)
Why Supertransactions Advance Beyond Bridge/Intent + Execute
In many ways, the features of executing across multiple chains have been provided by certain bridges and intent protocols through the bridge/intent + execute functionality - where the developer can encode the callData which will be triggered on the destination chain once bridging is complete.
While Supertransactions enable bridge + execute by default, they also represent a significant advancement of the concept:
1. Pre-Bridge Actions
Unlike bridge + execute's rigid "bridge first, then execute" approach, Supertransactions can perform complex operations on the source chain before bridging. This allows users to prepare assets optimally through swaps, position unwinding, or other DeFi operations before initiating the bridge.
2. Multi-Source Capabilities
While bridge + execute is limited to single-source transactions, Supertransactions can pull liquidity and assets from multiple chains simultaneously. This enables apps to treat user balances across multiple chains as if they’re a single unified balance - enabling true single-signature chain abstraction. Beyond this, the action being executed on the destination chain can wait for multiple asynchronous bridging operations to complete before triggering a single call with the unified result of all of these actions.
3. Cross-Chain Composability
In the following release, Supertransactions will gain a major upgrade - the composability stack! It solves a critical limitation of bridge + execute: transaction failures due to slippage. By enabling developers to only partially prepare the destination chain action before signing, certain parameters can be dynamically injected into the call on the destination chain.
Some examples of this include:
- Using the exact amount received from bridging as the input of the function on the destination chain
- Using the output of a previous function call on the source chain as the input on the destination chain (e.g. a true/false value noting whether an NFT mint succeeded on the source chain)
Now we know why Supertransactions are important and what they are, let’s look into Modular Execution Environments, which are responsible for executing Supertransactions.
A primer into Biconomy’s MEE
Enter Modular Execution Environments. MEEs are a network of nodes in the form of bundlers, solvers and others that process and execute Supertransactions. In more technical terms, a Modular Execution Environment is any permisionless network, mainly a P2P one, which can provide credible execution for a variety of offchain and onchain instructions - contained within the Supertransaction data model.
We are increasingly having conviction that the future of interacting with blockchains will be through a blended approach - leveraging both offchain and onchain execution. We even refer this as Hybrid Execution. Because Supertransactions are structured as a recursive Merkle tree that unifies multichain operations with a single signature it means we can have transaction branches that specify exact operations across any number of chains and intent branches that are resolved in milliseconds through optimistic execution.
Both types can be mixed freely within the same multi-chain Supertransaction. For example, with Hybrid Execution, users transaction doesn’t always have to be an intent, it might be the case using a bridge might be better at that time, and place for that specific asset. Or utilising an intent on a single chain then using a bridge for a long tail L2 because no solvers exist there. This is the flexibility behind Hybrid Execution and which is ultimately enabled by Modular Execution Environments.
Biconomy’s MEE is the first MEE that is available for developers to experiment and play with our Devnet which you can access here. Stay tuned for a longer, more thorough and technical post on the concept behind MEEs.