Skip to content
Examples

Multichain Orchestration Overview

Limitations of EOAs & Bundlers

The EVM blockchain execution stack has been severely limited by the idea that one user signature equals exactly one onchain function call. The most notable example of this has been the notorious approve + execute flow, which is a more than familiar nuisance for all EVM users.

While this basic case is slowly being resolved by the introduction of batchExecute calls on smart accounts and standards like ERC-5792 or EIP-7702, modern blockchain apps require much more complex actions than a simple batch of static function calls.

Blockchain is becoming multichain

With the proliferation of multiple EVM L2s/L3s and non-Ethereum L1s - modern apps work in an environment where user accounts and balances, protocol contracts and liquidity are spread across many independent blockchains.

Challenges of controling for dynamic runtime conditions

Additionally, the exact callData for all function calls is not always known ahead of time, since it can be influenced by slippages incurred by swaps, bridges, intents or by some other runtime conditions.

Biconomy MEE - The ultimate onchain execution stack

These, and many other challenges drove us to build the ultimate transaction execution stack. Multi-chain native and fully composable (able to control for runtime conditions), Biconomy orchestration is built to enable modern blockchain developers to build fully chain abstracted experiences and one-click flows.

Why Multichain Orchestration?

By using Biconomy multichain orchestration developers can get:

  • Single signature complex & multi-chain DeFi flows.
  • Unified multi-chain user balances.
  • Single signature onboarding to chains.
  • Scheduled actions (e.g. dollar cost averaging).
  • Comining multiple bridges/solvers or GMPs into a single execution flow.
  • Cross-chain composability.

The Biconomy Multichain Orchestration Solution

  • Single Signature, Multi-Chain Execution
    The new Biconomy stack enables developers to encode complex multi-chain, multi-transaction sequences which the user approves with a single signature.

  • Standardized Stack & Comprehensive Coverage
    The orchestration stack enables developers to use any token and interact with any protocol. The developers can use the shortcuts available within the AbstractJS SDK.

  • Gas Abstracted
    The user can pay for the execution of the entire sequence of operations with native tokens or ERC20 tokens on any chain.

  • Asynchronous
    The Biconomy orchestration stack can execute asynchronous actions, such as triggering bridges, solvers, waiting for oracles, etc...

  • Composable
    Biconomy orchestration is fully composable, meaning that you can inject the output of one function call into any paramter of the next function call, without writing smart contracts and even across multiple chains.

  • EOA & Smart Account Support
    Multichain orchestration works nativelly for all accounts - both native EOAs, smart accounts and EIP-7702 enabled EOAs.

  • Non-Custodial
    The execution is fully trustless and non-custodial, with all premission validation done onchain by validator contracts.

Example

How does it work?

Encode all Orchestration Instructions

The developer uses the Biconomy AbstractJS SDK or our API to encode all of the instructions needed to achieve the desired action. In this case, they would include:

Move Funds Cross-Chain

Using a bridge or a solver to move the USDC from Optimism to Base

Swap

Swapping the exact amount of USDC which was received from the bridge to USDT by using Uniswap on Base

Supply

Supplying the exact amount of USDT received from Uniswap to a lending protocol on Base

Boost Yield

Taking the exact amount of "lending position" tokens and supplying them to a yield booster protocol on Base.

Get a Quote for Execution from the Modular Execution Environment

The set of nodes which execute the orchestration steps are called the "Modular Execution Environment" or "MEE" for short. The developer sends the request for orchestration to MEE and gets back a quote on the total price of execution for all steps.

Along with the price, the node will return the hash of the instructions being executed. This hash is generated by building a Merkle Tree from the instructions data - the hash is the Root Hash of the Merkle Tree.

This data structure is called a Supertransaction.

Approve the Orchestrator Smart Account to Spend USDC from the EOA

The user signs the transaction which will approve the orchestration smart account to spend 999 USDC from their EOA. The app prompts the wallet for the user to sign the transaction and posts the transaction onchain. This is the only signature that the user needs to do.

This transaction is a mostly normal EVM approve call, save for the fact that, while encoding the transaction, the developer needs to append the hash of the orchestration instructions after the useful callData of the EVM function call. When using the Biconomy AbstractJS SDK, this is encoded automatically.

This means that, in a single signature, the user is permitting both the transfer of USDC to the orchestrator smart account and all of the additional instructions.

Send Instructions & Tx Hash to the Relayer Node

Call the /execute endpoint of the MEE Node (done automatically by the AbstractJS SDK) and provide it with the Tx Hash of the trigger transaction. This will start the orchestration procedure.

Wait for Completion

Usually, the last step of the orchestration is to send all of the funds which the user received back to the EOA which triggered the orchestration (but potentially on a different chain). This means that the existance of the orchestration smart account can be completely hidden from the user in the UI.

All the user knows is that they used their EOA to sign a single transaction, which then triggered a complex multichain sequence which resulted in some other desired token on their EOA.