Integration Overview

The common core

Every integration is the same two moves: read to decide, build to act. What differs between the models is only who signs and when — the API surface is identical.

Model 1 — Smart account

Best for

Anything that wants the guarantees the bundles are designed for: apps, agents and allocators running on ERC-4337 accounts.

Custody: the user’s own smart account.
Execution: the bundle goes out as one atomic user operation.
Gas: paid in USDC by the user’s ERC-20 paymaster. No native token on any chain.
What you need: an account on EntryPoint v0.7, a bundler and a paymaster.

const bundle = await getCalldata({ instrumentId, action: 'deposit', account, amount });

const { id } = await wallet.sendCalls({
  account,
  calls: bundle.calls.map((call) => ({
    to: call.to,
    data: call.data,
    value: BigInt(call.value),
  })),
});

This is the only model where loops, cross-chain redemption-plus-deposit, and the atomicity the simulation proves are actually available.

Execution Model

Accounts, the paymaster’s gas reserve, and the CCTP rules

Model 2 — EOA or existing wallet

Best for

Wallets, exchanges and apps with users on MetaMask, Coinbase Wallet or their own key infrastructure.

Custody: the user’s existing wallet.
Execution: the calls are sent in order, each receipt awaited.
Gas: the chain’s native token, as usual.
What you give up: atomicity. A bundle stopped halfway leaves the account holding whatever the last completed call produced.

for (const call of bundle.calls) {
  const hash = await wallet.sendTransaction({
    account,
    chain,
    to: call.to,
    data: call.data,
    value: BigInt(call.value),
  });
  await publicClient.waitForTransactionReceipt({ hash });
}

Fine for a plain deposit or withdrawal — two or three calls whose intermediate states are harmless. Not the way to open a levered loop.

Model 3 — Agent-driven

Best for

AI agents, robo-advisors and automated allocators that decide continuously and execute through a client that holds the keys.

The agent does the reading and the building; the user’s client does the signing. Nothing in the loop needs a human to be online at the moment of execution, and the agent never holds a key.

agent  ──reads──▶  /instruments, /metrics, /yield-index, /portfolios/analyze
       ──builds──▶ /instruments/:id/calldata, /bridge/calldata, /loops/:id/calldata
       ──hands──▶  the batch to the user's client, which signs it from their own account

A useful division of labour:

The agent decides	The API supplies
Which markets are worth holding	Yields, TVL, history, volatility, reward share, tier
How much to move, and when	Portfolio analysis, comparison and historical simulation
Whether the move is safe to sign	A simulated bundle with measured output, or a refusal

Because the bundle is validated before it leaves the API, an agent’s worst case is a refusal to act — not a broken transaction it talked itself into.

AI Agents

The full agent integration path

Choosing

	Model 1: Smart account	Model 2: EOA	Model 3: Agent-driven
Atomic bundles	Yes	No	Yes, via the client
Gas in USDC	Yes	No	Yes, via the client
Loops	Yes	Not supported	Yes
Cross-chain	Yes	Source burn only, in practice	Yes
Runs unattended	With the client’s policy	No	Yes
Custody	User	User	User

Does it need to run unattended?

Yes → Model 3, on top of Model 1’s execution.No → next question.

Do your users already have smart accounts, or can you give them one?

Yes → Model 1.No → Model 2, accepting sequenced calls and native gas.

Do you need loops or cross-chain?

Yes → Model 1 is required, not merely recommended.No → either model works.

Next steps

API Cookbook

End-to-end recipes, in TypeScript

Calldata API

Parameters, responses, errors

How It Works

What happens between the request and the bundle

Use Cases

Worked integrations by audience

Get Started

MCP

Core Concepts

Integration Guides

Use Cases

The common core

Model 1 — Smart account

Best for

Execution Model

Model 2 — EOA or existing wallet

Best for

Model 3 — Agent-driven

Best for

AI Agents

Choosing

Next steps

API Cookbook

Calldata API

How It Works

Use Cases

​The common core

​Model 1 — Smart account

Best for

Execution Model

​Model 2 — EOA or existing wallet

Best for

​Model 3 — Agent-driven

Best for

AI Agents

​Choosing

​Next steps

API Cookbook

Calldata API

How It Works

Use Cases

The common core

Model 1 — Smart account

Model 2 — EOA or existing wallet

Model 3 — Agent-driven

Choosing

Next steps