Biconomy Blog
· 5 min read

Case Study: One-Click Gasless "Vampire" Flows with Biconomy Orchestration

Case Study: One-Click Gasless "Vampire" Flows with Biconomy Orchestration

This tutorial demonstrates how to leverage Biconomy's Modular Execution Environment (MEE) and AbstractJS SDK to enable one-click position migration from Aave to Venus Protocol. The implementation showcases the power of composable orchestration to execute multiple complex transactions with a single user signature.

0:00
/0:46

Overview

This implementation enables users to:

  1. Transfer any accrued aToken interest to their Companion Account (via Fusion Mode)
  2. Withdraw their entire Aave position
  3. Approve the Venus pool to spend the withdrawn tokens
  4. Mint vTokens on Venus protocol on behalf of the user

All these operations happen atomically in a single transaction flow, abstracting away the complexity of multiple approvals and cross-protocol interactions.

Understanding Fusion Mode

Since external wallets like MetaMask or Rabby cannot directly install smart account logic on EOAs, this implementation uses Fusion Mode - a passthrough mechanism that enables MEE orchestration through a Companion smart account.

How Fusion Mode Works:

  1. Trigger Signature: User signs a trigger transaction containing the hash of all orchestration instructions
  2. Funds Transfer: Funds temporarily move to a non-custodial Companion Account owned by the user
  3. Instruction Execution: All operations execute using the Companion Account
  4. Return to EOA: Resulting assets automatically return to the user's EOA
  5. Stateless Design: The Companion Account remains clean with no dust after execution

The Power of Biconomy's Composable Architecture

Runtime Balance Resolution

One of the most powerful features demonstrated here is the use of runtimeERC20BalanceOf. This function dynamically resolves token balances at execution time rather than at signing time:

runtimeERC20BalanceOf({
  targetAddress: accountAddress,
  tokenAddress: position.aTokenAddress,
  constraints: [greaterThanOrEqualTo(100n)],
})

This is crucial for DeFi operations because:

The Complete Implementation

Let's examine how the Fusion trigger and composable instructions work together:

The Trigger Transaction

The trigger is the entry point that initiates the entire orchestration:

trigger: {
  chainId,
  tokenAddress: position.aTokenAddress,
  amount: position.userATokenBalanceMantissa,
  approvalAmount: bufferAmount,  // Buffered to account for interest
  gasLimit: 500000n,
}

This trigger:

Step 1: Transfer Accrued Interest (aTokens)

const transferInterest = await nexusAccount.buildComposable({
  type: 'transferFrom',
  data: {
    recipient: nexusAccountAddress,  // Companion Account address
    sender: accountAddress,          // User's EOA
    tokenAddress: position.aTokenAddress,
    amount: runtimeERC20BalanceOf({
      targetAddress: accountAddress,
      tokenAddress: position.aTokenAddress,
      constraints: [greaterThanOrEqualTo(100n)],
    }),
    chainId,
    gasLimit: 100000n,
  },
});

This instruction:

Step 2: Withdraw Entire Aave Position

const withdrawFromAave = await nexusAccount.buildComposable({
  type: 'default',
  data: {
    to: aaveV3PoolContractAddress,
    abi: aaveV3PoolAbi,
    functionName: 'withdraw',
    args: [
      position.tokenAddress,        // Asset to withdraw
      MAX_UINT256.toFixed(),       // Amount (MAX = entire position)
      nexusAccountAddress,         // Recipient
    ],
    chainId,
    gasLimit: 100000n,
  },
});

Key insights:

Step 3: Approve Venus to Spend Tokens

const approveVenus = await nexusAccount.buildComposable({
  type: 'approve',
  data: {
    tokenAddress: position.tokenAddress,
    spender: vToken.address,
    amount: runtimeERC20BalanceOf({
      targetAddress: nexusAccountAddress,
      tokenAddress: position.tokenAddress,
      constraints: [greaterThanOrEqualTo(100n)],
    }),
    chainId,
    gasLimit: 100000n,
  },
});

This showcases another powerful MEE feature:

Step 4: Mint vTokens on Venus

const mintVTokens = await nexusAccount.buildComposable({
  type: 'default',
  data: {
    to: vToken.address,
    abi: vBep20Abi,
    functionName: 'mintBehalf',
    args: [
      accountAddress,  // Mint on behalf of user's EOA
      runtimeERC20BalanceOf({
        targetAddress: nexusAccountAddress,
        tokenAddress: position.tokenAddress,
        constraints: [greaterThanOrEqualTo(100n)],
      }),
    ],
    chainId,
    gasLimit: 100000n,
  },
});

The magic here:

Creating the Fusion Quote

The Fusion Quote packages everything together with a trigger transaction:

// Buffer the approval amount to account for interest accrual
const approvalAmount = buffer({
  amountMantissa: position.userATokenBalanceWithInterestsMantissa,
});

const fusionQuote = await meeClient.getFusionQuote({
  trigger: {
    chainId,
    tokenAddress: position.aTokenAddress,
    amount: position.userATokenBalanceMantissa,
    approvalAmount,  // Buffered amount
    gasLimit: 500000n,
  },
  instructions: [
    transferInterest,
    withdrawFromAave,
    approveVenus,
    mintVTokens
  ],
  sponsorship: true,  // Enable gasless execution
});

Key features:

Understanding the Buffer Strategy

The buffer function plays a crucial role in handling Aave's interest accrual mechanism. Here's why it's needed:

When transferring aTokens to the Companion Account, there's a nuance with how Aave handles interest:

  1. The Trigger transaction transfers the user's aToken balance to the Companion Account, but this only transfers the right to receive future interest
  2. Accrued interest remains on the EOA - it stays there as additional aTokens that weren't included in the initial transfer
  3. The first instruction (transferInterest) then pulls these remaining aTokens (the accrued interest) to the Companion Account

The buffer ensures we approve enough aTokens to cover both:

This two-step process ensures the entire aToken position (principal + all accrued interest) is captured for the migration. The implementation effectively allows the user to transfer all of their aTokens AND all accrued interest to the Companion Account, ensuring no value is left behind on the EOA.

Advanced Concepts Demonstrated

1. Cross-Protocol Composability

This implementation seamlessly bridges two major DeFi protocols (Aave and Venus) in a single transaction. The MEE handles all the complexity of:

2. Dynamic Amount Handling

Traditional transactions require knowing exact amounts upfront. With MEE's runtime values:

3. Smart Contract Account Benefits

The Nexus account acts as an intermediary that:

3. Companion Account Benefits (Fusion Mode)

The Companion Account acts as a stateless intermediary that:

4. Constraint System

constraints: [greaterThanOrEqualTo(100n)]

Constraints ensure operations only execute if conditions are met, preventing:

Why This Matters

Traditional Approach (Multiple Transactions)

  1. User approves aToken transfer
  2. User transfers aTokens
  3. User withdraws from Aave
  4. User approves Venus
  5. User mints on Venus

Problems: 5 signatures, 5 gas payments, risk of partial execution, complex UX

Biconomy MEE Approach (Fusion Mode)

  1. User signs once (trigger transaction)

Benefits:

Conclusion

This implementation showcases how Biconomy's MEE with Fusion Mode transforms complex DeFi operations into simple, user-friendly experiences. By leveraging composable instructions, runtime values, and atomic execution through a Companion Account, developers can build sophisticated cross-protocol integrations that work with any external wallet.

The key innovations demonstrated:

This pattern can be applied to any multi-step DeFi operation, from yield optimization to portfolio rebalancing, making it a powerful tool for building advanced Web3 experiences that work with mainstream wallets.

Share Share Share Share Share Email