Biconomy Blog
· 16 min read

Biconomy Network Litepaper

Biconomy Network Litepaper

Abstract

This paper introduces the Biconomy Network, a permissionless peer-to-peer protocol designed to enable seamless cross-chain interoperability at the application layer - without writing smart contracts.

By providing an aggregated interface toward general message passing protocols (GMPs), bridges, and solver networks, Biconomy Network creates a unified layer that allows developers to orchestrate and compose transactions across multiple chains through a single “all chains” connection (connecting to a single “entry” node with an SDK or through a single API endpoint).

By separating the process of permissioning (signing with a private key) and committing transactions (posting to a chain) (done by the Biconomy network); from the process of validating and executing them (done by the underlying chains); it enables developers to build rich onchain apps which treat thousands of underlying blockchains as a single execution environment - without writing or deploying smart contracts.

Leveraging the Biconomy stack opens up a whole new world of possibilities for frontend and backend developers by allowing them to write scripts which act as multi-chain smart contracts. Instructions within the scripts keep a rich execution context which enables developers to share the same memory layout and data between multiple transactions on multiple chains.

The execution of these scripts is protected by onchain validation contracts, inheriting the security of the underlying blockchains - while execution liveness is guaranteed by a stake posted by the Biconomy network nodes - making the entire system truly permisionless and trustless.

Background

The Evolution of Blockchain Composability

The emergence of smart contract platforms introduced powerful composability primitives, enabling developers to combine existing protocols to create novel applications. This composability drove significant innovation during the DeFi expansion, with developers leveraging multiple protocols within single-chain environments to create sophisticated financial products.

Current Limitations

While single-chain composability proved powerful, it faced inherent limitations in execution speed and cost. The introduction of Ethereum’s rollup-centric scaling model and the emergence of alternative Layer-1 networks with distinct virtual machines (e.g. Solana) have created a fragmented landscape. Though significant progress has been made in cross-chain settlement and messaging layers, frontend interoperability remains largely unsolved.

The Developer Experience Gap

The blockchain ecosystem faces a significant imbalance: frontend developers proficient in TypeScript, Swift, and Kotlin vastly outnumber smart contract developers. However, these frontend developers face substantial technical barriers when building cross-chain applications, requiring specialized blockchain expertise for achieving basic functionality.

The Biconomy Network Solution

Architecture Overview

Biconomy Network introduces a novel peer-to-peer architecture that enables:

  • Fully composable execution across heterogeneous blockchain networks
  • Scalability to support 1000+ blockchain networks (including appchains)
  • Simplified developer interface through developer-friendly SDKs and standardized APIs

Key Differentiator

The network can be imagined as an interoperability aggregator, uniquely positioned to:

  • Trigger general message-passing messaging protocols
  • Interface with solver networks
  • Integrate with bridges
  • Mint/burn multi-chain tokens
  • Behave as an “omnichain” bundler, with the ability to commit transactions to all blockchains

The core aspect of the Biconomy Network approach is that it doesn’t pass messages or liquidity around itself. It’s simply used as a trigger which can orchestrate existing (and future) solutions to work in unison.

Network Benefits

The Biconomy network aims to become the universal interface to all blockchains for frontend and backend developers. By connecting to a single RPC endpoint, developers will be able to execute transactions across all blockchains, including both EVM and alt-VM environments.

The network is fully permissionless and censorship resistant. All guarantees in the network are provided through pure cryptography, with no voting or social consensus based mechanisms used to resolve disputes.

Interacting with the network is backwards compatible with all existing wallets and developer tooling. An app developer is able to plug-in the Biconomy network into their existing project without major migrations.

Node & Network Features

  • Just-In-Time Resource Sharing (Unified Multichain Balances) Developers need to be able to access the funds users have on any chain, without users bridging or signing multiple transactions. The process of moving funds across blockchains needs to be invisible to the user and effortless to the developer.
  • Multi-Chain Transaction Orchestration
    The Biconomy Network enables developers to encode complex, multi-chain sequences of transactions which can include calls to bridges, solvers or oracles and execute them with a single user signature. The Biconomy Network will take care of orchestrating all actions and executing them in the correct sequence.
  • Cross-Chain Composability
    Developers need to be able to dynamically compose multiple transactions, bridges and solvers across chains into a single desired “user action”. Often times, the exact input variables are not known at the time when the user signs the transaction. The Biconomy network enables developers to read the state of storage slots or token balances at execution time and dynamically inject them into function parameters.
  • Universal Gas & Gas Sponsorships
    One of the biggest points of friction in blockchains is requiring gas to execute transactions. The Biconomy network will enable users to pay for gas in ERC20 tokens across all chains (e.g. pay for transaction execution on Optimism with USDC on Arbitrum). The node itself functions as the 'token paymaster,' allowing developers to seamlessly use this feature without the need for additional integration efforts. For an even greater level of gas abstraction - app developers will be able to sponsor gas for their users.
  • Collaborative Execution
    The Biconomy network enables multiple nodes to collaborate on executing a single desired user action. This is the backbone of the ability for the network to support 1000+ blockchains. While each individual node will be specialized for their own subset of supported blockchains and operation types - the developer interacting with the network sees a unified interface supporting all blockchains and all operation types.
  • Execution Redundancy
    For popular blockchains and instruction types, there will be many nodes available at any given moment capable of execution. This ensures that execution through the Biconomy Network will be highly available, even in times of outages of multiple nodes.

Network Implementation

The Biconomy network is powered by a unified data model called the Supertransaction. A Supertransaction represents a sequence of on-chain and off-chain instructions which the Biconomy Network needs to execute along with the payment information on how the user wishes to pay the execution fee.

  • Compact & Versatile Data Structure
    Supertransactions are encoded using a Merkle Tree data structure which enables them to represent an arbitrary number of instructions with a single hash - called the Supertransaction Hash.
  • One Signature Approves All Instructions
    By signing the Supertransaction Hash with their private key, the user is permitting the Biconomy Network to execute all of the actions contained in a Supertransaction.
  • One Fee Used to Pay for All Instructions
    All actions on the Biconomy Network, no matter how many chains, solvers, bridges or other providers they span - are always paid with a single fee. This fee can be paid by the user or sponsored by the app developer.
  • Trustless Validation of Execution
    During execution, all validation of instructions within the Supertransaction is done on-chain. This prevents the Biconomy Network nodes from executing anything beyond what the user explicitly signed with their private key.
  • Execution Protected by Proof of Stake
    Every action within the Supertransaction is protected by a cryptographic stake. If the node doesn’t execute the transaction within the given parameters, they are slashed.
  • Enabling Collaborative Execution
    The nodes can collaborate to execute a single Supertransaction. If a node lacks support for certain blockchains or instruction types within the Supertransaction, it can handle the portions it supports and get other nodes in the network to execute the rest. This is handled by the pathfinder node.
  • Trustless Collaboration
    Collaborative execution is trustless, protected by staking. Each node posts their own stake committing to their own subset of instructions.

Modular Execution Environments

The Biconomy Network is an expansion and a decentralized implementation of the modular execution environment (MEE) standard recently introduced by Biconomy. A Modular Execution Environment is defined as any execution environment capable of executing Supertransactions.

Modular Execution Environments are inspired by both the Modular Blockchain thesis and the capabilities of ERC-4337 account abstraction.


MEEs represent a natural evolution of the modular blockchain thesis, expanding the concept of specialized layers beyond consensus, data availability, and settlement. While the modular blockchain paradigm separated these core functions to optimize for scalability and efficiency, MEEs specifically address the execution layer by abstracting it away from the underlying chains. This approach allows blockchain interactions to be processed, enhanced, and optimized through dedicated infrastructure before reaching consensus layers, creating a specialized middleware that can handle complex transaction patterns, cross-chain operations, and user experience improvements uniformly across disparate networks.

Whilst MEE is inspired by ERC 4337, we've been able to demonstrate it far exceeds their capabilities and serving a different purpose. ERC-4337 aims to simplify the user experience of interacting with blockchains and having a separate execution layer (Bundlers / Paymasters) is just a consequence of enabling those functions. In contrast, MEEs begin with the core premise of a dedicated execution layer (MEE Nodes) as their foundation, enabling a comprehensive ecosystem of advanced functionalities to be constructed on top.

The Biconomy Network nodes can work in both centralized and decentralized modes. A node can easily be switched from a centralized to decentralized mode by having enough staking tokens delegated to it. This has the added benefit of enabling MEE integrators to test out their stack in a centralized environment and connecting to the broader Biconomy Network ecosystem at any point in the future.

Organizations and developers can run their own MEEs and/or plug into the Biconomy Network. A centralized MEE cannot do collaborative execution, but instead acts as a multi-chain bundler & paymaster with the ability to orchestrate transactions.

Complete Backwards Compatibility

For EVM chains, developers can join the network by simply deploying any ERC7579-compatible Smart Contract Account (e.g. Biconomy Nexus, Safe, or Kernel,..) and installing the k1MeeValidator module. Signing transactions and managing permissions works seamlessly with existing wallets (like MetaMask, Rabby, Zerion and more) or through alternative authentication methods including Passkeys and OAuth. The MEE architecture fully supports EIP-7702, allowing even standard EOA accounts to access MEE functionality. This compatibility empowers users to execute sophisticated multi-chain operations using just a single signature, regardless of their wallet type.

Network Architecture & Participants

Biconomy Network works as a permisionless peer-to-peer gossip network. Anyone can join the network. For any given Supertransaction, validation & execution can be split into multiple parts handled by specialized nodes:

  1. Pathfinding - Pathfinder / Entry Node
    The network needs to find nodes capable of executing all of the instructions within a Supertransaction. This work is done by specialized nodes called Pathfinders. The Pathfinders read a registry of all of the nodes and their signaled capabilities (supported chains and supported instruction types). The Pathfinders also check the liveness of executing nodes and make sure to prioritize order flow to nodes with low latency and high availability. When a user is accessing the Biconomy Network, they are connecting to a Pathfinder node.
  2. Execution - Execution Nodes
    The nodes commit to the execution of the instructions within the Supertransaction and execute them. At the end of every instruction execution an onchain storage slot is set to “SUCCESS” (dependent on the type of instruction) which proves that the instruction has been executed.
  3. Validation / Slashing - Watchtower Node
    If all of the nodes successfully executed their assigned instructions, the validation step is executed automatically after a certain amount of time passes. After that time, the node can no longer be slashed for non-execution.If any of the nodes didn’t execute their instructions as committed - a public slash function can be called, ensuring the node is slashed. In order to make sure the nodes are regularly slashed - a specialized set of “watchtower” nodes monitor the network and call the slash function when required.

Execution Flow

The Biconomy Network uses a quote & execute flow to ensure the execution of Supertransactions. This means that the developer first requests a quote from the Biconomy Network - this quote is provided by the executing nodes, is binding and has an expiration time.

Core benefits of the quote & execute model:

  • Price predictability for users.
    The users get a quote for the cost of execution of the entire Supertransaction upfront. Biconomy Network nodes, being the more sophisticated participants, take on the risk of miscalculating the costs of execution.
  • Frontrunning prevention for Nodes.
    One big issue with relaying transactions for users (e.g. in the case of ERC-4337) is that - if the transaction has a fee which is going to the relayer - it can be frontrun by MEV bots which then take that fee to themselves. In the quote & execute model - the recipient of execution fee is hardcoded in the transaction data - making it infeasible for MEV bots to frontrun.
  • Grifting & DDOS Mitigation
    The code in the node which is doing the actual execution of the Supertransaction can be separated from the code which is offering the commitments. This means that a potentially malicious user could only spam the commitment endpoints which perform a computationally lightweight operation and can be trivially scaled to support high workloads.

1. Encode

The process of executing a Supertransaction begins by encoding the desired Instructions to an array. Every Supertransaction request must contain two fields:

  • Instructions
    The exact instructions on what Biconomy Network should execute
  • Fee Info
    The users desired way of paying for the execution of the Supertransaction

A pseudocode example of a Supertransaction with three instructions:

// Instructions to be executed by the Biconomy Network
const instructions = [
	swap(
		chain: optimism,
		fromToken: USDC,
		toToken: USDT,
		amount: 1000 // swap 1000 USDC to Unknown amount of USDT
	), // Swap 
	bridge( // Triggering a solver/bridge
		fromChain: optimism
		toChain: arbitrum,
		// Inject exact amount of USDT received from swap
		amount: inTimeBalanceOf(USDC) 
	), 
	// Automatic orchestration of destination-chain action, the supply
	// function will be executed **after** the funds arrive from bridign
	supplyToLendingProtocol( 
		token: USDC,
		amount: inTimeBalanceOf(USDC) // Example of cross-chain composability
	)
]

// Encoding the fee payment information
const feePaymentInfo = {
	type: 'payWithERC20Token',
	onChain: optimism,
	token: USDC
}

// A complete Supertransaction contains both the instructions and 
// the desired payment type
const stx: Supertransaction = {
	instructions: instuctions,
	feePaymentInfo: feePaymentInfo
}

2. Fetch Quote(s)

The user will send their Supertransaction request to the Node which they’re connected to. This node will trigger the Pathfinder (centralized in the beginning, decentralized after) to find the available execution paths among the nodes.

After finding the available paths, the executing nodes need to commit to their willingness for execution. They do this by providing a non-binding quote stating:

  1. That they are able to execute the part of the Supertransaction the Pathfinder selected for them.
  2. The total cost of their execution.

The pathfinder will then assemble available routes for execution and return them to the user, ordered by execution cost or some other variable (e.g. average latency of selected nodes, % successful execution by selected nodes, etc…).

3. Sign Quote & Broadcast To Nodes

The user will accept one of the offered paths returned by the Pathfinder. Since the payment data is represented within each path, the Supertransaction Hash of each available path is completely different. The user permits the execution for a selected path by signing the Supertransaction hash of that path with their private key and sending the signed hash, along with the full Supertransaction instructions and payment object - back to the Pathfinder / EntryNode. The Pathfinder / EntryNode will then distribute the signed object to the executing nodes for execution and to the Watchtower node to slash the executing nodes if they offend.

4. Claim Execution Fee & Broadcast Node Commitment

The Nodes, once receiving the signed Supertransaction hash from the user - can claim their share of the execution fees by signing the Supertransaction hash with their own private key. In order to achieve a better gas efficiency when claiming the funds, the funds can be claimed in a single transaction for all nodes.

Claiming the execution fee is an essential part of the execution guarantees / slashing process. Because claiming the execution fee can only be done by posting the Supertransaction hash signed by the executing node onchain - the node is essentially broadcasting its commitment to execute all its assigned Instructions in the Supertransaction. This commitment can then be used to slash the node in case of non-execution.

5. Execute Instructions

The executing nodes will execute all of their transactions in the required order. The orchestration of the transaction execution is done through special instructions in the Supertransaction maxTime and minTime. Every node must execute before maxTime otherwise they get slashed.

Since multichain execution can depend on conditions which are not immediately satisfied - e.g. one of the instructions can be a supply function call which requires 1 WETH to be available on Arbitrum, which first needs to be bridged from Polygon - nodes have no way of knowing whether a transaction is failing due to conditions not being met or it just being a case of the developer encoding an invalid transaction.

For that reason, if maxTime has been reached and the transaction is still reverting in simulations, the node will force the execution of this transaction even if it’s invalid. If the node didn’t force the execution of this transaction, it would open itself up to the risk of being slashed. The node is able to force the execution of an invalid transaction by posting the transaction onchain and having the actual call revert internally, within the Smart Account contract (the actual transaction is successful, but the proxy call within the Smart Account fails and the UserOp event is emitted with success=false)

6. Slash Offending Nodes (Optional)

If any of the nodes in the process do not execute the transactions they’ve committed to executing, they will be slashed. The slashing is done by calling the public slash function of the Slashing contract onchain. This function can be called by anyone, the Watchtower node only serves as a utility service to make sure that the slashing actually happens.

The slash function is called with the following parameters:

  • The Nodes commitment to execute the instruction (signed Supertransaction hash)
  • The hash of the actual instruction which was not executed

Since the types of Instructions on the Biconomy network can be heterogenous (e.g. execute UserOp, front liquidity, trigger a cross-chain message) - every type of Instruction has it’s own dedicated “slashing conditions” contract - which checks for some condition on or off chain to see whether the node needs to be slashed.

In order to remain future-proof, the Biconomy Network is agnostic towards the types of Instructions that the Nodes can commit to, as long as the Instruction type has an associated Slashing contract.

In the initial release, the Biconomy Network will be shipping with the UserOpExecutionSlashing contract, which will enable Nodes to commit to execute a specific UserOp on some chain.

Execution Sequence Diagram

Composability Stack

Executing multiple Instructions (transactions, message passings, moving tokens) across multiple chains comes with implicit issues of composability. Since the execution outputs of onchain transactions, bridges or solvers are not deterministically known ahead of time, it’s usually impossible to encode function callData which controls for all of those variables.

The Modular Execution Environment (MEE) stack, including the Biconomy Network, has a backwards compatible solution for dynamically injecting exact values of storage slots or function outputs - at runtime!

In practice, this means that you can fully control for slippage or runtime issues by encoding a script which will “pull” the required data during execution time. The fetching of the data for injection is done fully on chain! The result of this is that the injection of dynamic data is completely trustless.

In an example: Imagine you want to:

  1. Swap Token A for Token B
  2. Bridge Token B from Chain X to Chain Y
  3. Supply the exact amount received from bridging to a yield farm on Chain Y

In this example, we have several unknowns:

  1. Due to slippage on DEXs, when swapping Token A for Token B, we can either a) fix the amount of Token A which we will supply, but then we wont know exactly how much of Token B we will receive or b) fix the amount of Token B we will receive, but then we won’t know exactly how much of Token A we must supply.
  2. Bridging and solving providers always take a fee to move the tokens from one chain to another. Beyond this, if they’re doing a cross-chain swap - they will have slippage. This means that we can’t know exactly how much of Token B we will receive on Chain Y until the token actually arrives onchain.

On EVM networks, the MEE stack solves the problem of composability through the usage of Smart Account (ERC-7579) Fallback Handlers. The great thing about fallback handlers is their ability to intercept the transaction callData and modify it - in a completely trustless/deterministic way, onchain. The composability Fallback Handler works in the following way:

  1. Read the original transaction
    The original transaction needs to be encoded in a special way (as a call to an executeComposable function on an ERC-7579 smart contract account) and then the fallback handler will be able to read it and deduce which parameters were set by the developer ahead of time and which need to be “pulled” from chain.
  2. Access current blockchain state
    The fallback handler will, for every parameter which needs to be dynamically injected - read the associated storage slot or call the associated on-chain function call - to get the exact data which needs to be injected. For every dynamic parameter, the exact storage slot from which it’ll pull data is encoded ahead of time by the developer. The fallback handler is a Smart Contract and can only read from that storage slot.
  3. Inject the Dynamic Parameters
    Once it has the data, the fallback handler will inject the dynamic parameters into the requested functions.
  4. Execute
    The fallback handler will execute the encoded function with the injected parameters.
  5. Store
    The fallback handler will, optionally, store the execution results or the post-execution blockchain states into a predetermined storage slot - to be consumed by the next transaction.

Cross-Chain Composability

Beyond enabling composability from function calls (e.g. balanceOf some token during execution time) or injecting from storage slots on the same chain, the MEE stack enables cross-chain composability by creating a multi-chain memory layout for every Supertransaction. This means that Instructions can share the same execution context - even across chains.

Deriving the Memory Layout
The memory layout for each Supertransaction is derived from:

  1. The Supertransaction hash
  2. The address of the contract being called by the fallback handler
  3. The method being called by the fallback handler
  4. The slot identifier (each function call can store multiple items, represented by identifiers)

The layout is derived in the following way:

keccak256(superTxHash, contractAddress, methodSignature, slot)

Every function call which is going through the Fallback Handler is able to store variables into these storage slots after the execution of the target contract is over. The developer can decide whether to store certain storage slots or the outputs of certain function calls (e.g. store a getLastMintedId call on some NFT).

Fetching the Storage
The MEE stack is agnostic on how the developer wishes to fetch the state of the storage slot on another chain. This can be done thorough general message-passing protocols, through ZK proofs of state, through oracles, etc… This is handled by trusted singleton deployments of contracts which know how to read to and write from the derived storage slots. The apps themselves would then trust the service provider (e.g. LayerZero, Polymer, Chainlink, …) to transfer the information in a correct manner.

The Fallback handler would make sure to only call the exact storage slots derived from the same Supertransaction for all Instructions within it. This means that each transaction contained within would share the same memory layout - enabling developers to easily write scripts which span multiple chains. The Fallback handler, trusted singletons and cross-chain providers would make sure that the entire process is trustless and that no man-in-the-middle attacks are possible.

Encoding composable transactions
Since the encoding structure of the call to executeComposable is well known, composability can be abstracted away from the user through the usage of an SDK package. An example of a composable flow in an SDK would be:

const amountToBridge = parseUnits('100', 6) // 100 USDC
const supertx: Supertransaction = {
  instructions: [
    acrossPool.on(optimism).bridge({
      args: [
        usdc.addressOn(optimism), // Bridge USDC from OP
        usdc.addressOn(arbitrum), // to USDC on Arbitrum
        optimism.id,// Bridge from Optimism
        arbitrum.id, // Bridge to Arbitrum
        amountToBridge
      ]
    }),
    uniswap.on(arbitrum).swap({
      args: [
        usdc.addressOn(arbitrum), // Swap USDC on Arbitrum,
        usdt.addressOn(arbitrum), // to USDT on Arbitrum 
 
        // Dynamically inject the amount of USDC
        // which arrived from Optimism, compensating
        // for any slippage a bridge might have had
        runtimeBalanceOf(usdc.addressOn(arbitrum))
      ]
    })
  ]
}

Conclusion

The Biconomy Network is a comprehensive stack, enabling fully composable transaction execution across many chains. Through the scalable architecture of collaborative execution and recursive commitments, the Network is able to scale to support a 1000+ chain future. It is able to trigger Solvers, cross-chain messaging providers and execute transactions based on runtime data - provided from onchain storage slots, or provided by oracles. It provides gas abstraction and gas sponsorships.

Biconomy Network is your universal interface to all blockchains!

Share Share Share Share Share Email