
We recommend understanding Fusion Execution before executing code, but if you’d like to skip the theory - read the code guide
Fusion Mode Flow
1
Trigger Signature
The user signs a trigger transaction that includes the hash of all orchestration instructions. This signature authorizes the full orchestration with a single user action.
2
Funds Transferred to Companion Account
Funds are temporarily pulled into a Companion Account fully owned by the user. This account is non-custodial and stateless—no funds are stored there beyond execution.
3
Instruction Execution
All instructions (e.g., swaps, bridges, multicalls) are executed using the Companion Account.
4
Return to EOA
Resulting assets are sent back to the user’s EOA. The Companion Account is left clean with no dust.
5
Optional Cleanup
If an orchestration step fails—especially in multichain setups—a cleanup can revert intermediate steps, returning funds or rebalancing tokens.
Trigger Types
There are two kinds of Fusion triggers. They depend on which type of token you are using as the input token. If you’re working with tokens which supportERC20Permit
then you can use the ERC20Permit
trigger type, which makes the entire orchestration gasless. Otherwise, you must use the Onchain Tx
trigger, which requires a bit of gas on source chain to execute the approve
ERC20 transaction.
The SDK will detect whether a token supports ERC-2612 and choose the appropriate trigger type.
Fusion Constraints
- Can only consume one token per user signature.
- Token used for execution must also be used to pay for gas.
- Transaction sponsorship is possible and bypasses the gas requirement.
Fusion Flow
- Trigger: User signs a transaction (e.g.
approve
) that signals orchestration. - Orchestrate: MEE nodes execute function calls, bridges, or other logic.
- Return: Final steps return assets to the user’s EOA.
Stateless UX: Users never need to know about the orchestrator account. All resulting tokens return to the user’s EOA automatically.