In the previous articles within the Learn series, we've explored how developers can leverage the new Biconomy Modular Execution Environment standard to asynchronously orchestrate operations across multiple chains. Beyond this, working on top of the Biconomy stack offers developers the benefit of leveraging Session Key automation, gasless transactions and more...
However, all of these benefits - until recently - came with the downside of the user having to deposit funds to a Smart Account. This would fragment their assets across multiple addresses and served as a point of friction for app developers to onboard users.
Unlike before, the latest Biconomy stack - with Nexus Smart Account, Modular Execution Environments & the AbstractJS SDK now works for all EOA wallets! The users don't have to deposit or upgrade their wallets.
Companion Accounts
Companion accounts are fully featured smart accounts which are invisible to the user. They act as passthrough accounts through a following sequence:
- The user assets are transferred from their EOA to the Companion Account
- The companion account processes all the operations set by the application developer. This can include multiple function calls across one or more chains or installing session keys.
- The resulting funds are returned back to the EOA account, making the Companion Account completely invisible to the user.
Single Signature
What differentiates the Companion Account flow from usual Smart Account flows is the fact that all of this is achieved with a single user signature. By doing it this way, the experience is truly seamless for the user - making it feel as if their EOA got additional powers.
With Fusion Execution (Maximum Backwards Compatibility)
At Biconomy, we've managed to make this entire flow fully backwards compatible with all EOA accounts - including those where the wallets or chains aren't compatible with EIP-7702! We call this functionality - Fusion Execution.
Fusion Execution is achieved by packing the hash of additional instructions as extra data within the transaction to transfer assets from the EOA to the Smart Account.
Fusion Execution Modes
Fusion execution is an extensible standard, for now it supports two main execution modes:
Trigger Transaction
The trigger transaction mode works by packing the hash of the extra instructions to be executed behind the useful callData of a transaction which is transferring assets to the Smart Account. To get an idea, this is pseudocode for the packing algorithm:
const amount = parseUnits('100', 6)
const rootData = encodeFunctionData({
abi: erc20Abi,
args: [
'0x_COMPANION_ACC_ADDRESS', // Address of companion
amount // Amount to use in fusion execution
]
});
// Extra instructions are encoded in the Supertransaction
// data structure and commited onchain by the Biconomy MEE Node.
const extraInstructions: Supertransaction = {
// Example of extra instructions.
// Last instruction is always to take the
// resulting assets and return them to EOA
instructions: [bridgeToBase, supplyToAAVE, returnToEOA]
}
// Encoding the Fusion Transaction
const fusionTransaction = {
to: '0xUSDC_ADDRESS',
// The hash of the extra instructions is appended
// to the data
data: rootData.concat(extraInstructions.hash),
value: 0n
}
// Execute trigger transaction onchain
wallet.sendTransaction(fusionTransaction)
// Send extra instructions for execution to the MEE Node.
// The MEE node cannot execute anything which was not part of the
// hash that was appended to the original transaction. This is validated
// by a validator on the smart account.
meeClient.execute(extraInstructions)Trigger ERC20Permit
When using the Trigger Transaction method, the user would still have to pay for gas for the trigger transaction (though all the extra instructions can be sponsored or gas abstracted). In order to enable Fusion Execution to be gasless we can use the ERC20Permit method!
This works in much the same way as the trigger transaction method with the difference that the extra information is not packed after the callData but actually packed into the DateTime field of the ERC20Permit function call.
Using Companion Accounts with EIP-7702
While Companion Accounts offer smart account functionality to EOAs without EIP-7702 - they're not a replacement for EIP-7702. In fact, they're complementary to the standard and solve one of the biggest pain points for apps trying to leverage EIP-7702 functionality that wallets offer.
As we've noted in our comprehensive guide to EIP-7702 for apps - while EIP-7702 enables the delegation of an EOA to a Smart Account, for security reasons, these delegations are not available to apps. Meaning - the wallets won't allow apps to delegate to custom smart accounts.
But what if an app wanted to take advantage of custom functionality such as multichain orchestration or session keys? This is where the Companion accounts come into play.
Even though wallets don't plan to allow apps to delegate to their own Smart Accounts, they're planning to enable them to consume the assets on the wallet through multiple means - e.g. ERC-7710, ERC-5792 or some other means. Then, instead of using Fusion - the developer can simply encode a transaction requesting delegations to a Companion Smart Account and execute from there.
Learn More
This article is part of our Learn series. Read the rest and learn about the entire Biconomy stack: