How AI agents trade perpetual futures without taking custody of your funds

Perpetual futures let an AI agent take leveraged positions that reset every few seconds through funding payments, but the architecture that enables this does not require you to deposit funds into a custodial account controlled by the agent. Instead, the owner keeps assets in a self-controlled wallet, grants the agent scoped spending authority through smart permissions, and the API translates the agent’s dollar-denominated intent into the specific margin and contract math required by each perps venue. If the agent misbehaves or the market moves sharply, hard limits and a kill switch flatten positions and revoke access before the owner loses control of the principal. This design treats leverage as a controlled input, not as an ungated privilege, and it ensures that the agent can trade but never own the funds it deploys.

Trading perpetual futures with an agent introduces risks that spot markets do not. The sections below explain how the architecture addresses leverage, custody, sizing, and emergency controls without requiring the owner to surrender control of the underlying capital.

What makes perpetual futures dangerous for autonomous agents?

Perpetual futures are derivatives that trade at a price anchored to an underlying spot market through periodic funding payments. An agent trading these instruments can post a small amount of margin to control a much larger notional position, which means errors or unexpected market moves compound quickly. A loop bug that repeats a spot order is costly; the same bug in a perps market with leverage can erase margin or trigger liquidation in minutes. Funding rates also accrue continuously, so a position left open overnight by an unattended agent can bleed value even if the mark price stays flat. Liquidation is another risk that does not exist in simple spot trading. If the market moves against a leveraged position and the margin balance falls below the maintenance requirement, the venue can close the position automatically and may charge a penalty. An agent that does not monitor its margin ratio or that opens positions across correlated markets can face cascading liquidations that wipe out the allocated budget. Cross-margin mode adds another layer of complexity, because losses in one position can erode the margin supporting another. Isolated margin limits the damage to a single position, but it requires the agent to manage margin allocation correctly. Many agent strategies fail because they assume margin is infinite or that a venue will warn them before liquidation. In practice, liquidations happen mechanically and without sentiment. The first line of defense is to recognize that leverage amplifies both market risk and automation risk. The architecture must therefore constrain the agent before it enters a position, monitor it while the position is open, and be able to stop it without negotiation.

How does the non-custodial wallet architecture work?

Funds never sit in an account that the agent owns. The owner holds the wallet, and the agent receives scoped credentials that can only initiate trades within pre-approved parameters. The agent can spend from the wallet up to a budget cap and can open or close positions, but it cannot withdraw funds to itself or change approved withdrawal addresses. This is enforced by the underlying permission layer, not by policy promises. If the owner revokes the key, the agent loses all spending authority immediately, though any open positions remain on the venue until closed or liquidated. The architecture treats the agent as an operator with a strictly limited mandate, not as a trustee with broad control. The wallet itself is constructed so that withdrawals can only travel to addresses the owner has explicitly whitelisted. Even if the agent’s key were compromised, an attacker could not reroute funds to a new address. The owner can also rotate keys without moving assets, which means that revoking one agent does not require a full migration of capital. This separation of trading authority from custody is the foundation of the safety model. It means that the agent’s code, the LLM reasoning layer, and the API itself never have the power to move the owner’s principal off the platform. The owner remains the sole party that can initiate a withdrawal, and the agent remains a temporary operator that can be removed in seconds.

Why does the API normalize contract sizing into dollar amounts?

Perps venues use their own conventions for contract size, margin tiers, and notional calculations. Some venues use coin-margined contracts, others use stablecoin-margined contracts, and each has its own tick size, lot size, and minimum order value. An agent should not need to reason about these details, because doing so invites rounding errors, wrong-size orders, and venue-specific bugs. The API accepts orders in plain US dollars, so the agent can express intent as "open a $500 short" or "reduce exposure by $200." The platform then converts that dollar value into the correct number of contracts, selects the appropriate margin mode, and respects the venue’s minimum lot size. This abstraction also makes it easier to port the same strategy across different perps venues without rewriting the agent’s logic. Dollar sizing removes an entire class of errors that arise when an LLM tries to divide notional value by contract size and misplaces a decimal. It also simplifies risk management, because the owner can think in terms of absolute dollar exposure rather than in contracts or margin fractions. The agent does not need to know whether the venue measures ETH perps in dollars per coin or in smaller index units. It simply states the economic intent, and the API handles the translation. This is especially important when the agent is managing multiple positions across different asset classes, because the same dollar logic applies to stocks, crypto, and perps within the unified interface. You can read more about the risks of letting an agent reason in raw contract sizes in our article on dollar-based order sizing.

What safety controls prevent runaway leverage?

Before an agent trades live, the owner configures a hard budget that the agent cannot exceed. This cap is enforced at the infrastructure level, not by the agent’s own prompt or code. The agent may believe it is free to trade, but the API will reject any order that would push total deployed capital past the limit. Beyond the budget, the owner sets position limits, maximum leverage per trade, and allowed markets. These constraints are checked on every request. An exit plan can define conditions that trigger automatic flattening, such as a drawdown threshold or a time-based exit. The most important control is the panic or kill switch, which immediately cancels open orders, closes positions at market, and revokes the agent’s key. In leveraged markets, speed matters, so the kill switch acts on the venue directly without waiting for the agent to acknowledge a command. The kill switch does not guarantee a favorable exit price, especially in volatile conditions, but it does guarantee that the agent stops adding risk. Owners should also set a leverage cap that is well below the maximum offered by the venue, because high leverage leaves little room for normal market noise. A position that uses extreme leverage can be liquidated by a small wick, whereas a conservative cap gives the agent room to absorb volatility without immediate forced closure. It is also wise to restrict the agent to a narrow list of markets, because thinly traded perps can gap hard and slip against stops. Finally, the owner should review open positions regularly, because an agent that loses its connection may leave funding-heavy positions open indefinitely. We explain the mechanics in detail in our guide to kill switches, and we cover budget enforcement in how an AI agent trades within a hard budget.

How does an agent connect and place an order?

Agents connect through MCP tools or the REST API. The exact request schema is in the docs; the shape looks like this:

{
  "intent": "perp_open",
  "market": "ETH",
  "side": "short",
  "dollar_notional": 500,
  "max_leverage": 3,
  "api_key": "YOUR_KEY"
}

The platform translates that dollar amount into the venue’s contract units, checks the request against the owner’s guardrails, and submits the order. The agent receives a confirmation with the executed notional, the entry price, and the remaining budget. If the order would breach the cap or the leverage limit, the API rejects it before it reaches the venue. The agent does not handle margin calculations, funding schedules, or liquidation price math. It simply states its intent in dollars, and the infrastructure enforces the safety constraints. This separation of concerns means that the agent can focus on strategy while the platform handles execution risk. The same pattern works whether the agent is trading through a Claude or Cursor MCP client or through a direct REST integration. Because the API is unified across market types, an agent that already trades stocks or options can add perps without learning a new authentication or sizing scheme.

What should you test before going live?

Paper trading lets you observe how the agent behaves when it believes it is risking real money, but it is not a perfect mirror of live perps markets. Funding payments, margin calls, and liquidation prices may not align exactly between paper and live environments, so treat paper results as a logic check rather than a performance forecast. Common errors include letting the agent assume it can retry failed orders indefinitely, or failing to account for the fact that perps positions can be forced closed by the venue. Slippage in paper mode is often idealized, and the emotional pressure of real capital is absent, so an agent that looks stable in simulation may behave differently when actual losses appear on the dashboard. Reviewing common mistakes developers make with paper trading for AI agents before you authorize a live key will help you avoid assumptions that only hold in simulation. Live trading requires explicit owner authorization of a scoped key, and you should start with a small budget and low leverage until the agent’s behavior is predictable. Increase size only after you have observed how the agent handles funding, volatility, and drawdowns under real conditions. It is also worth testing the kill switch during paper trading, so you know how long it takes to flatten positions and whether the agent tries to fight the shutdown by reopening trades.