Build a DeFi Vault with AI - MCP, SDK and Launchpad

Start with the Fusion for agents guide, and give your agent the Fusion technical reference. These explain the available tools and the protocol rules your agent needs before inspecting or building a vault.

From there, choose the part of the stack that fits your task:

• To analyse an existing vault, start with the hosted MCP server. The CLI and local MCP server also let you inspect vaults through your own RPC providers.
• To write strategy code, start with the Python SDK examples. They show how to construct contract calls and test complete workflows in simulation.
• To deploy a vault from a configuration file, start with the Fusion Vault Launchpad. It takes a JSON specification through planning, a fork rehearsal and deployment.

We’ll cover each route below, followed by the supporting documentation and links to get started.

Five Fusion concepts to know

These terms appear throughout the tools and examples:

• Vault. A smart contract that holds deposits and strategy positions. Depositors receive shares representing their stake in the vault. Fusion’s vault contracts are called Plasma Vaults.
• Fuse. An adapter contract that lets a vault perform a specific action on another protocol, such as supplying to Aave, borrowing from Morpho or swapping tokens. A fuse must be registered on the vault before it can be used.
• Substrate. An asset, pool or other parameter that a market integration is permitted to use. Substrates define the allowed targets for its actions. For example, an Aave supply configuration can permit USDC.
• Balance fuse. A contract that reports the value of the vault’s positions in a market. Fusion uses these values in its asset accounting and share-price calculations.
• Roles. The Atomist curates the vault’s configuration and permissions. The Alpha executes strategy actions within that configuration. Additional roles govern specific administrative functions.

Roles are assigned to onchain addresses. An agent submitting transactions acts through a signer address and is subject to that address’s permissions.

Reading vaults with MCP and the CLI

The hosted MCP server

In July, we introduced the Fusion MCP server, giving builders and operators a way to explore Fusion vaults through natural-language queries in compatible AI assistants. You can ask about a vault’s configuration, permitted actions or pricing, and the assistant can retrieve the relevant data.

Fusion Team on building a DeFi vault with an AI agent.

Fusion by IPOR (@ipor_io) on X

That announcement focused on reading and analysing vault deployments across the Fusion ecosystem. Over the summer, we’ve expanded the supporting tools and documentation, including protocol resources and reusable prompts that help agents understand Fusion’s rules and work through common tasks.

The hosted server is public and read-only. You can connect without a login, a local server installation or your own RPC key. In Claude Code, setup takes one command:

claude mcp add --transport http ipor-fusion https://mcp.ipor.io/mcp

Other MCP clients that support HTTP transport can connect to the same endpoint at https://mcp.ipor.io/mcp.

The hosted server exposes eight tools covering vault listings, vault state, oracle mappings, deployment addresses and Morpho markets. These give the assistant access to configuration details such as registered fuses, permitted substrates, role holders and withdrawal settings.

Detailed vault inspection through vault_info currently supports Ethereum, Arbitrum and Base. Coverage varies across the other tools. For deployments missing from the address tools, agents can consult the ipor-abi registry.

Giving the agent context before asking questions

Once connected, ask your assistant to read the Fusion guide resources before analysing a vault:

• fusion://glossary explains Fusion’s terminology.
• fusion://architecture describes the contracts and how they fit together.
• fusion://invariants documents configuration and execution rules.
• fusion://quickstart provides a walkthrough of vault deployment and operation.

These resources let the assistant consult Fusion’s rules alongside the vault data. For example, it can look up what an Alpha is allowed to do or which configuration steps a market requires before execution.

You can then ask questions such as:

• Which protocols and assets can this vault use?
• Who can change its configuration or execute a strategy?
• How does the vault price its assets, and which feeds does it depend on?
• What fees and withdrawal conditions apply?
• What are the parameters of the Morpho market used by this strategy?

We’ve also included prompts for common tasks: quickstart, deploy_vault, analyze_vault, trace_oracle_pricing and explain_fuse. These provide instructions for the assistant to follow. Clients that support MCP prompts may display them as slash commands.

The analyze_vault prompt guides the assistant through a vault’s assets, fees, permissions and withdrawal configuration. trace_oracle_pricing focuses on the sources and dependencies used to value its assets. You can then follow up with questions about specific findings.

The deploy_vault prompt provides guidance for creating and configuring a vault. It is not a transaction tool: the hosted MCP server does not sign or broadcast transactions. To carry out a deployment, a coding agent needs an environment where it can run the Python SDK, either directly or through the Launchpad.

Inspecting vaults from the terminal

The fusion CLI gives you access to vault and market inspection without writing a Python script. It uses an RPC provider, the service through which your local tools connect to the blockchain.

If you don’t already have pipx, install it using the commands for your operating system below. On macOS and Debian/Ubuntu, use the package manager to avoid restrictions on installing packages into a system-managed Python environment.

Windows:

python -m pip install --user pipx
python -m pipx ensurepath

macOS with Homebrew:

brew install pipx
pipx ensurepath

Debian/Ubuntu:

sudo apt update
sudo apt install pipx
pipx ensurepath

Open a new terminal after running ensurepath so the installed commands are available on PATH.

Choose one installation:

• For the CLI: pipx install 'ipor-fusion[cli]'
• For both the CLI and the local MCP server: pipx install 'ipor-fusion[mcp]'

The [mcp] extra includes the CLI dependencies and provides both fusion and fusion-mcp. If you plan to connect an agent to your local setup, choose that option.

Next, configure an RPC provider:

fusion config set-provider https://your-rpc-endpoint

Use a provider with an API key, such as Alchemy or Infura. fusion vault info makes many RPC calls, and free public endpoints may rate-limit or reject them.

The provider configuration detects the chain ID. You can then inspect a vault on that network. For an Ethereum vault:

fusion vault info 0xVAULT_ADDRESS --chain-id ethereum

Replace the address placeholder with the vault you want to inspect. The CLI saves the vault to your local configuration on first use. To list saved vaults:

fusion vault list

You can also inspect Morpho Blue markets and MetaMorpho vaults:

fusion market morpho-blue 0xMARKET_ID --chain ethereum
fusion market meta-morpho 0xVAULT_ADDRESS --chain ethereum

A coding agent with terminal access can use these commands too. For example:

Use the fusion CLI and my configured Ethereum provider to inspect [vault address]. Explain which protocols and assets the vault can use, who holds its operating roles, and what its withdrawal settings mean.

The CLI reads onchain information and manages your local configuration. Vault deployment, configuration changes and strategy execution happen through SDK code.

Connecting an agent to your local setup

The local MCP server lets an assistant use your own RPC providers and saved-vault configuration through an MCP connection.

If you chose ipor-fusion[mcp] during the CLI setup above, fusion-mcp is already installed. If you installed only ipor-fusion[cli], reinstall the package with the MCP dependencies:

pipx install --force 'ipor-fusion[mcp]'

The --force flag is needed here because pipx otherwise leaves the existing installation unchanged.

Then add the local server to your MCP client configuration:

{
  "mcpServers": {
    "ipor-fusion-local": {
      "command": "fusion-mcp",
      "type": "stdio"
    }
  }
}

The name ipor-fusion-local keeps this entry separate from the hosted server registered as ipor-fusion, so you can connect both.

Configure the providers and vaults through the CLI or the MCP configuration tools. The local server exposes inspection tools alongside Fusion’s guide resources and prompts. Its blockchain access remains read-only.

Building with the Python SDK

The Python SDK gives builders and agents the tools to create and operate Fusion vaults in code. You can use it to configure a vault, prepare strategy actions, simulate their execution and submit transactions through a configured signer.

The SDK supports Ethereum, Arbitrum One and Base. Install it in your project’s Python virtual environment:

pip install ipor-fusion

Start with a runnable vault example

The vault examples show complete workflows in individual Python files. Start with the Aave V3 example, then use the Euler V2 example to explore a borrowing strategy.

Both examples use Base:

• Aave V3 supply vault. This example creates a vault in simulation, sets up its roles and configures an Aave V3 market with USDC as the permitted asset. It checks oracle coverage, deposits funds and executes a supply action from the Alpha address.
• Euler V2 credit-market vault. This example uses cbETH as collateral and WETH as the borrowed asset. It configures the required fuses and permissions, supplies collateral, borrows WETH, repays the debt and unwinds the position. It then checks that the outstanding debt has been cleared.

Each example previews the deployment, prints the unsigned creation calldata and an ordered transaction plan, then runs the workflow through eth_simulateV1 and checks the resulting state. The scripts never sign or broadcast transactions.

To run them, you need the SDK and a Base RPC endpoint that supports eth_simulateV1. A provider with an API key is recommended, because free public endpoints may rate-limit the simulation.

You can ask your coding agent to work through the first example:

Set up the ipor-fusion.py repository’s development environment and run the Aave V3 supply example in simulation using BASE_PROVIDER_URL. Explain each step of the transaction plan and the checks on the resulting vault state. Do not sign or broadcast transactions.

With the repository’s development environment installed, run the following from its root directory:

export BASE_PROVIDER_URL="https://your-base-rpc"
uv run python examples/simple_aave_v3_supply_base.py

The shell command above uses Bash or Zsh syntax. In PowerShell, set the variable with $env:BASE_PROVIDER_URL = "https://your-base-rpc" before running the same Python command.

The examples also expose builder functions that let you inspect the encoded calldata without connecting to an RPC provider.

Each script performs its workflow once and exits. For ongoing vault operation, we provide a separate Alpha bot example covering a continuously running strategy process.

How the SDK constructs transactions

Once you’ve run an example, you can follow how its individual calls are assembled.

The SDK provides Python wrappers for Fusion’s contracts and protocol-specific fuses. These cover vault creation, permissions, fees, withdrawals and pricing, alongside integrations with protocols including Aave V3, Morpho, Euler V2 and Uniswap V3.

The SDK’s fuse classes encode protocol actions into FuseAction objects. For example, an Aave supply action specifies the asset and amount the vault should supply. You can combine several actions into a batch, which the vault executes atomically: if an action fails, the transaction’s state changes revert.

Contract wrapper methods return a Call object containing the prepared call. With a configured context, a vault wrapper and a valid fuse action, the following illustrate separate operations (the Aave V3 supply example shows how to create each of them):

# Read the vault's total assets
total = vault.total_assets().call()

# Obtain calldata for an external signer
payload = vault.execute([action]).calldata

# Submit using a context with a private key configured
receipt = vault.execute([action]).send()

Reading a value with .call() and obtaining .calldata require no private key. Calling .send() signs locally using the key configured in Web3Context and submits the transaction. You can also use .build_transaction() to prepare an unsigned transaction with a configured signer address and RPC connection. A write-only call such as vault.execute(...) must be tested through the simulator; the SDK rejects .call() on it.

These calls follow the vault’s permissions. An address executing strategy actions must hold the Alpha role, and the vault must have the required fuses, permitted substrates and balance fuses configured.

Amounts use raw onchain units. For USDC, which has six decimals, 1_000_000 represents 1 USDC. The SDK does not scale amounts automatically. Contract addresses are published by chain in the ipor-abi registry, and vault.get_fuses().call() lists the fuses registered on a particular vault.

Testing your own strategy actions

When you start adapting the examples, VaultSimulator lets you execute a batch against simulated state and inspect the result before sending a transaction. It runs through eth_simulateV1, so you need an RPC provider that supports that method. No local node or private key is required.

For a prepared vault and action, you can record total assets before and after execution. This snippet assumes that ALPHA_ADDRESS is set in the environment to the address authorised to execute the batch:

import os
from ipor_fusion import VaultSimulator
from web3 import Web3

sim = VaultSimulator(
    ctx.web3,
    vault=vault.address,
    alpha=Web3.to_checksum_address(os.environ["ALPHA_ADDRESS"]),
)
sim.observe("before", vault.total_assets())
sim.execute([action])
sim.observe("after", vault.total_assets())

result = sim.run()
if result.all_success:
    print(result.get("after") - result.get("before"))

The Alpha address identifies the simulated caller. It must have the required permissions in the simulated state. The result shows how the batch affects the vault’s reported assets under those conditions.

Simulation also supports sequences of calls across simulated blocks. This lets you test a strategy’s lifecycle, including opening a position, adjusting it and unwinding it. A successful simulation applies to the state tested; the live transaction executes against the state available when it is included.

How to build a DeFi vault with an AI agent

With Fusion, a coding agent can help build an ERC-4626 vault by preparing its configuration and running the Fusion Vault Launchpad. The Launchpad uses the Python SDK to construct contract calls and submit transactions through a configured signer.

For a USDC vault on Base, the workflow is:

1. Load the protocol context. Give your agent the Fusion for agents guide and the Launchpad’s AGENTS.md.
2. Prepare the specification. Start with the Aave V3 example and define the permitted assets, role holders, fees and withdrawal settings.
3. Test the vault. Generate a deployment plan, then rehearse deployment, deposits, strategy execution and withdrawals on a local fork.
4. Review and deploy. Check the rehearsal results and approve the exact configuration before the agent proceeds with live deployment.

The SDK’s Python examples explain the individual calls behind these steps. The Launchpad brings them into a deployment workflow driven by a JSON specification.

The Launchpad is MIT-licensed and remains a work in progress.

Defining the vault

The strategy file at strategies/<name>.json brings the vault’s configuration together in one place. It specifies:

• The target chain and underlying asset.
• The protocols the vault may use and the assets or markets each fuse may access.
• Price feeds and accounting configuration.
• Fees and withdrawal settings.
• The addresses holding each role.
• Whitelist and share-transferability settings.

A companion Markdown file records the strategy description and the operator’s decisions. The deployment pipeline applies the configuration in up to 17 idempotent steps and checks the result by reading the vault’s own contracts. Steps a strategy doesn’t need are skipped, so the plan may show fewer steps.

Launchpad strategy examples

The Launchpad includes two strategy specifications on Base:

• A USDC vault supplying to Aave V3. The example-usdc-aave-base strategy demonstrates a vault using a single lending venue. Its rehearsal deposits USDC, supplies it to Aave and completes an instant withdrawal through the configured withdrawal queue.
• A leveraged wstETH/USDC strategy on Morpho Blue. The example-wsteth-usdc-loop-base strategy uses a collateralised market, a flash loan and a token swapper. Its rehearsal builds and unwinds the position, then completes a scheduled withdrawal through the request, release and redeem process.

There are two Aave examples because they serve different tasks. Use the SDK’s Python example to understand and adapt individual contract calls. Use the Launchpad’s Aave specification as a starting point for configuring, rehearsing and deploying a complete vault.

Both Launchpad examples contain Anvil test addresses. The pipeline prevents those placeholders from being used for a live deployment.

You can use an example to give your coding agent a concrete starting request:

Use the Aave V3 example in the Fusion Vault Launchpad to prepare a USDC vault on Base. Walk me through the configuration decisions, generate the deployment plan and rehearse the deposit, supply and withdrawal flow on a fork. Stop before live deployment.

The repository’s AGENTS.md tells the agent how to gather those decisions, prepare the files and report the results.

Preparing and testing the plan

Once the repository and its dependencies are installed, you can generate a deployment plan for the Aave example:

python -m deploy strategies/example-usdc-aave-base.json

This dry run prints the intended contract calls with decoded arguments and writes a plan file. It requires internet access and uses a public Base endpoint when RPC_URL is unset. It needs no private key or manual RPC configuration and broadcasts no transactions.

You and your agent can review the selected contracts, permissions, fees and withdrawal settings, update the specification and generate another plan.

The next step is a rehearsal against a local fork: a local copy of the target chain’s state where you can deploy and use the vault. The Launchpad uses Anvil, Foundry’s local node, for this rehearsal.

You need Foundry, an archive-capable RPC endpoint to create the fork and an Anvil test account. Set RPC_URL to the local fork’s address and DEPLOYER_PRIVATE_KEY to an Anvil test account’s key.

In PowerShell, set environment variables with $env:NAME = "value". For example, use $env:RPC_URL = "http://127.0.0.1:8546" for a fork running on port 8546, as in the deployment guide. The guide provides the exact setup commands, including the key for Anvil account #0.

Once those variables are set, run:

python -m deploy strategies/<name>.json --broadcast --rehearse

Replace <name> with your strategy’s filename. The deployment commands shown here fit on one line and need no shell-specific line continuation.

The rehearsal deploys and configures the vault on the fork, verifies its configuration and then exercises the strategy. The checks cover:

• Depositing funds into the vault.
• Executing every declared fuse through the strategy’s rehearsal script.
• Checking asset pricing and accounting, including double counting.
• Completing a withdrawal.

The resulting reports give you a record of the vault’s behaviour under the rehearsal conditions. A separate comparison tool checks the planned calls against those executed during the run, so you can review differences before proceeding.

Reviewing a live deployment

The operating guide requires a successful fork rehearsal, a review of the planned and executed calls, and explicit operator approval for the exact specification being deployed.

Before a live broadcast, the operator must also confirm three points:

• They have reviewed the addresses holding each role.
• They understand that the vault needs hardening before production use.
• They know that listing on the IPOR front end requires coordination with the IPOR Labs team.

Live deployment uses the operator’s funded deployer account and private RPC endpoint, configured in the local .env file:

python -m deploy strategies/<name>.json --broadcast --i-understand-this-is-live

The agent instructions require credentials to stay out of the conversation, logs and strategy files. Production-hardening guidance covers role handover to multisigs, execution delays, fee recipients and market limits.

You can check the deployed vault again at any point:

python -m deploy strategies/<name>.json --verify-only

Throughout the workflow, the agent can resolve contract addresses, prepare configuration files and run rehearsals. The operator decides the strategy’s intent, role holders, fees and access settings, and approves live deployment.

The Launchpad covers vault creation, configuration, rehearsal and verification, with guidance for production hardening. Ongoing strategy execution and monitoring sit outside its scope.

Documentation and references

The Fusion for agents guide introduced at the start of this article explains when to use the MCP server, SDK, API and deployment registry. The supporting references provide the contract details and operating rules an agent needs as it works through a task.

Documentation agents can read

The reference at ipor.io/llms.txt brings Fusion’s vocabulary, role and market IDs, contract links and common revert errors into a text format an agent can read directly. It also documents accounting conventions and limits in tool coverage. The index at docs.ipor.io/llms.txt helps agents locate documentation pages and their Markdown versions.

These details matter when an agent prepares code. Vault shares use the underlying asset’s decimals plus two, and the ERC-4626 maximum functions do not account for roles, available liquidity or redemption locks. The guide explains those rules alongside the configuration requirements for fuses, substrates and pricing.

For coding agents, the SDK repository includes a deployment skill covering vault creation, role setup, market configuration, deposits and execution. Its instructions share the same text as the MCP’s configuration rules and quickstart resources. The skill provides guidance for writing SDK code; running that code still requires the relevant environment and permissions.

The Launchpad’s AGENTS.md covers its own workflow, including the decisions reserved for the operator and the checks required before live deployment. Its documentation also covers setup, the strategy-file format, rehearsal, verification and production hardening.

Following the sources

Use the deployed contracts and the ipor-abi registry to resolve contract behaviour and addresses for the target chain. The SDK examples show how to construct calls, while the Launchpad documentation explains how to apply and check a complete deployment specification.

For historical vault and market data, use the separate Fusion API. Its responses refresh on a schedule, so an analysis should account for the data timestamp. The MCP’s inspection tools, the SDK’s simulation results and the API’s historical data each describe a particular state or time period.

Closing remarks

You can start with a vault you already use, an SDK example you want to adapt or a specification for a new deployment. Give your agent the relevant guide, choose a concrete task and review the data, code or deployment plan it produces.

We’ve made the code, examples and operating guides public so you can inspect how each workflow is built and use it as a starting point for your own work.

If a step is unclear or a workflow fails, share a reproducible example through the relevant repository’s contribution process.

Happy vault building!

More links to get started