Ever since the launch of smart contract blockchains ten years ago, the way users and developers interact with them has remained roughly the same. The app encodes a transaction, the user signs the transaction and it gets sent to a blockchain node for processing and inclusion into the chain.

This model has been inadequate for a while now and developers were forced to work around it with various band-aid solutions for years. From forcing users to sign multiple transactions to achieve a single intent (approve + execute, anyone?), the inability of users to pay for gas in anything other than a native gas token to the complete UX nightmare that is permissioning an action over multiple blockchains - many models have been presented by over the years - with varying levels of success.

The best known workaround of the limitations in onchain execution has been the introduction of the ERC4337 Account Abstraction standard. This standard introduced a model of sending transactions to a dedicated Bundler and using Smart Contract Accounts. This did improve the onchain user experience by quite a lot and has seen a significant amount of adoption by developers, but the standard still faced challenges in achieving widespread adoption and not solving for specific user needs.

See, ERC4337 was a single-chain, single-VM standard and required users to migrate to non-portable Smart Contract Accounts. The reality of blockchain usage, however, was trending increasingly towards users interacting with multiple blockchains and multiple VMs at the same time. Users also wanted to keep using their EOA accounts. It became increasingly clear - existing standards just weren’t going to cut it.

‍

The Execution Revolution

Meeting the standards of modern blockchain user and developer experience requires an execution environment which elegantly operates across multiple blockchains, multiple virtual machines and multiple execution models (e.g. Intents and UserOps).

In order for developers to send instructions to such an environment, we require an executable model which is much more versatile than the transaction models of today. This new type of transaction needs to be able to contain multiple transactions, on multiple blockchains, intents for execution by solvers and even off-chain actions. Ideally, all of those instructions would be represented by a single transaction hash.

Through our R&D efforts we have created two revolutionary new concepts, which have the capability to supercharge both the user and developer experience moving forward for the next decade of blockchain innovation.

We call them the Supertransaction and the Modular Execution Environment (MEE)

‍

Supertransaction

Supertransactions are the evolution of the blockchain transaction model - backwards compatible with existing wallets and tooling, powerful in supporting modern execution models such as UserOps and Intents and fully extensible for the future of off-chain execution. So, what is a Supertransaction?

A Supertransaction is a data structure containing multiple instructions on actions the user wishes to achieve. These actions can take many forms. At launch of the standard, Supertransactions support Transactions (in the form of UserOps) and Intents. However, the design of the Supertransaction model is such that many new standards can be added to them in the future. Some of the ideas include instructions for fetching off-chain data through concepts such as zkTLS.

The core concept of Supertransactions is that the user can permit the entire flow of the supertransaction, which can span multiple blockchains and execution modalities - with a single signature. The user does this by signing the supertransaction hash. How do we get this hash? With Merkle Trees!

By putting separate executables (such as transactions or intents) as leafs of a Merkle Tree, we can derive the root hash of the Merkle Tree and use the signing of that root hash to permit the entire sequence of actions with a single signature.

Beyond that, we can dedicate one leaf to be the fee payment instruction which the nodes can check before execution. This can be e.g. a transfer of ERC20 tokens to a node address or a proof of Paymaster sponsorship or even **a proof of off-chain payment! This fee payment covers the execution of all instructions, thus natively unlocking a feature coveted by chain abstraction solutions - multi-chain gas abstraction.

But that’s not all! Supertransactions are recursive. This means that one Supertransaction can contain anotherSupertransaction as just another one of its instructions. Recursivity, while seemingly inconsequential - enables a powerful new primitive: collaborative execution. This means that one node can commit to another node to execute a part of the instructions within the Supertransaction - providing unseen levels of horizontal scalability to blockchain execution environments - a much needed feature in a world trending towards thousands of independent blockchain networks.

One example of a Supertransaction might be:

1. Swap USDT for USDC on Optimism
2. Execute an Intent which fronts USDC to Base and takes USDC on Optimism
3. Supply USDC to a Lending Protocol on Base

A logical next question is - how does a Supertransaction get executed? For this, we introduce the second concept, the…

‍

Modular Execution Environment (MEE)

There is an increasing trend in blockchain networks of moving more and more execution off-chain. The end result of this is the concept of intents - where users don’t even encode the transactions which they want executed, but simply communicate the desired end states for their account (e.g. giving 1 ETH in exchange for 3000 Dai). Another example would be an ERC4337 Bundler - an off-chain entity - using sponsorship APIs and Paymasters to cover the cost of a users transaction.

If the current trends were to continue, and there is no good reason for them not to, the future of interacting with blockchains will be through a blended approach - leveraging both offchain and onchain execution.

A Modular Execution Environment is any permisionless network which can provide credible execution for a variety of offchain and onchain instructions - contained within the Supertransaction data model.

As the word itself suggests, modular execution environments are able to cater to a wide range of different types of execution requests by users - from transactions, intents and requests for sending cross-chain messages to performing offchain actions through oracles or credibly accessing offchain data with ZK proofs.

Perhaps the most exciting feature of MEEs is the composability stack – a collection of smart contracts deployed across supported chains that makes cross-chain operations seamless. In other words, you can use the output from an Ethereum smart contract as input for any L2/Solana program, or vice versa.

Imagine rebalancing a yield position from one chain to another. What used to require multiple signatures, custom contracts, and careful coordination now becomes a single fluid operation:

1. Pay gas in USDC on Optimism
2. Unwind your position on Mainnet
3. Bridge assets to another chain
4. Deploy into a new yield strategy

All with one signature, one transaction, zero custom contracts.

‍

The Biconomy Protocol

The Biconomy protocol is the first Modular Execution Environment. It is a permisionless peer-to-peer gossip network using Proof of Stake guarantees to provide credible execution of Supertransactions. It enables multiple independent nodes to collaborate on the execution of a single Supertransaction as well as provide support for execution of transactions (in the form of UserOps) and Intents.

The Biconomy Protocol achieves the functionality of a Modular Execution Environment through the use of cryptographic commitments. In order to execute a Supertransaction, a Node must sign the Supertransaction Hash, which then obliges it to execution. The Node guarantees for the execution as outlined in the Supertransaction by the stake it has posted onchain. If the Node fails to execute any of the steps of the execution - the Node gets slashed.

The validation of whether the Node performed execution or not is done fully onchain through custom validation modules. Each validation module fits to a specific type of instruction in a Supertransaction. For onchain execution, the Protocol uses Smart Contract Accounts and an ERC7579 module system to perform pre-checks for execution. What is important is that this is both smart account AND EOA compatible. For EOAs, it works with the Fusion module (coming soon) as well as 7702.

The Biconomy Protocol provides a secure and trustless way of executing Supertransactions, aligning to principles of full decentralisation and immutability. There are no limitations to joining the Protocol beyond owning a certain amount of Biconomy tokens - meaning nobody can censor the execution on the Protocol. Once deployed, the protocol contracts themselves will be versioned and immutable, with no admin access by anyone.

The Protocol works on standardised smart contract account systems pioneered by Biconomy through our extensive research in the Account Abstraction stack. This means, that beyond just executing Supertransactions - users get support for the latest that Account Abstraction has to offer - with things such as Sessions, Passkey logins and Sponsored transactions available by default, along with all the benefits chain abstraction provides.

‍

The Road Ahead

We're at the beginning of a new chapter in blockchain infrastructure. MEEs aren't just an incremental improvement – they're a fundamental rethinking of how we approach blockchain execution. They maintain full compatibility with existing standards while opening up entirely new possibilities for developers.

Imagine:

• A liquidation protection system that monitors positions across lending protocols on multiple L2s, automatically rebalancing assets when needed – all through a single signed operation
• Cross-chain arbitrage bots that execute sophisticated trading strategies across DEXs on different chains, orchestrated through one coordinated Supertransaction
• Privacy-preserving applications that seamlessly blend on-chain transactions with off-chain zero-knowledge proof generations, all scheduled and executed as one unified flow
• Automated portfolio management systems that rebalance positions across yield strategies on different chains based on real-time APY data from oracles
• NFT marketplaces that execute bundle trades across multiple L2s, handling payments, transfers, and bridging in one elegant sequence
• Smart contract wallets that implement automatic gas tank refilling across multiple chains when balances run low, without requiring user intervention
• Social dApps that group together profile updates, content posting, and cross-chain friend interactions into smooth, unified operations
• Decentralized insurance protocols that can automatically process claims and distribute payouts across multiple chains based on oracle-verified real-world events
• Treasury management systems that optimize yield across dozens of protocols on different chains, executing complex rebalancing strategies through a single signature

As we continue to build out the MEE ecosystem, we're excited to see how developers will leverage this new capability to create experiences that were previously impossible or impractical to build.

The future of blockchain execution is modular, and it's arriving sooner than you think.

Ready to start building with MEEs? Sign up to the waitlist. Documentation and developer resources coming soon. Stay tuned for updates.

‍