Skip to main content

What you are about to do

Pick an instrument, ask 1Tx for the calls, and send them from an account you control. Three HTTP requests and one signature — no contract of ours is involved, and nothing is deployed.
Amounts in the calldata API are always raw token units, never decimal strings. 1000 USDC is "1000000000", not "1000.00".

Prerequisites

  • An API key from app.1tx.fi/api-keys.
  • An account that holds USDC on a supported chain — Base, Arbitrum, Unichain or Monad.
  • A way to send EVM calls. An ERC-4337 smart account is the recommended target (it can send the whole bundle atomically and pay gas in USDC); a plain EOA works if it sends the calls in order.
1

Find an instrument

Ask for the highest-yielding active USDC markets on Base:
Each row carries an instrumentId, its currentApy, tvl, tokenAddress and yieldTokenAddress. The id is all you need from here.
Sorting by raw APY ranks incentive spikes first. Add enrich=true&tier=Core&maxCv=0.2 to rank on yield that has held up — see the Instruments API.
2

Build the calls

Ask for a 1000 USDC deposit on behalf of the account that will sign:
The response is the bundle: calls in the order to send them, requires (what the account must already hold), expectedOut as measured by the simulation, and a simulation block proving the calls ran at quoteBlock.
A bundle whose simulation reverts is never returned — you get a 400 instead, so a 200 is already a statement that these calls work against current state.
3

Send them from a smart account (recommended)

One batch, one user operation, atomic — and gas paid in USDC by your own ERC-20 paymaster:
wallet_sendCalls (EIP-5792) is the shape the bundle is built for. Under the hood your account, bundler and paymaster do the rest; 1Tx neither sponsors gas nor sees the signature.
4

…or send them in order from an EOA

Wait for each receipt before sending the next: an approve that has not landed makes the deposit after it revert. An EOA loses the atomicity the simulation assumed — if you stop halfway, the account keeps whatever the last completed call produced.
5

Check the position

To exit later, call the same calldata endpoint with action=withdraw and either a raw underlying amount or amount=max for the whole position.

Depositing from another chain

The funds are on Base and the instrument is on Arbitrum? That is two bundles, not one call:
1

Burn on the source chain

Send that bundle on Base. It approves Circle’s TokenMessengerV2 and burns, with your own account as both mint recipient and destination caller.
2

Wait for the attestation

Poll Circle’s Iris API with the source transaction hash until the attestation for the burn is ready. A 404 simply means the burn is not indexed yet.
3

Deposit on the destination chain

Request /instruments/:id/calldata on Arbitrum after the USDC has been minted, sized to what actually arrived, and send it. Building it earlier would pin the simulation to a block where the funds are not there yet.
Because the burn names your account as destinationCaller, only you can redeem it. There is no relayer to trust and no way for anyone — us included — to intercept the transfer.

Next steps

How It Works

Recipes, swap legs, and what the simulation does and does not prove

Execution Model

Smart accounts, gas in USDC, and cross-chain without a relayer

Calldata API

Every parameter and response field

Levered Loops

Borrow, swap and re-supply in one signed batch