How algorithmic traders can automate without giving up custody

Algorithmic traders have historically faced a forced choice between keeping full custody of their funds and depositing them into a centralized account to enable automated order placement. Non-custodial infrastructure removes this tradeoff by letting an agent submit orders through a single API while the funds remain in a wallet or account the owner controls. The agent receives scoped permissions to trade within strict limits, but it cannot withdraw funds, change ownership, or act outside its mandate. This architecture now extends across stocks, crypto, perpetual futures, options, and prediction markets. The owner does not need to choose between automation and control.

What does self-custody mean for an automated strategy?

Self-custody means the private keys or account credentials that own the funds remain exclusively with the trader. In traditional custodial setups, you transfer assets to a platform before you can run a strategy. The platform holds the funds and executes orders on your behalf. If that platform pauses withdrawals or suffers a security failure, your capital is exposed. In a non-custodial model, the underlying assets stay in a wallet or brokerage account that you control. The agent receives a scoped key or delegated permission that allows it to place orders, cancel orders, or read balances, but it cannot move funds to an unapproved address.

The owner retains the power to revoke access at any time without waiting for a third party. This distinction is central to non-custodial trading for AI agents, because it changes the trust model from reliance on a platform to reliance on code and permissions you set yourself. The wallet owner can inspect every permission on chain or through the API dashboard, and no backend administrator can override those permissions to seize or freeze funds. This transparency matters for anyone running unattended strategies, because the agent is active twenty-four hours a day and the owner may not be monitoring every tick.

How does an agent trade without taking custody?

The mechanism relies on permission boundaries encoded in the infrastructure layer. When you authorize an agent, you generate credentials that explicitly list what it can do. Typically, these permissions include placing orders, reading positions, and possibly canceling open orders. They do not include withdrawals, transfers, or changes to account ownership. Funds sit in a wallet or account that the agent can spend from only within the trading context. For example, if the agent is managing a perps position, it can post margin and open or close contracts, but it cannot send that margin to an external wallet. Withdrawal addresses are owner-approved only, and new addresses require a separate authorization step that the agent cannot perform.

This structure is non-custodial by construction, not by policy. The agent is mathematically incapable of taking the funds because the credentials never grant that capability. Even if the agent's server is compromised, the attacker gains only the ability to trade within the pre-set limits. They cannot drain the wallet, because the private key that controls withdrawals never leaves the owner's secure storage. This separation of trading permissions from ownership rights is what makes the model viable for algorithmic strategies that run with minimal human supervision.

What safety controls limit the agent's authority?

Scoped permissions are only the first layer. A practical system adds budget caps, position limits, exit plans, and a panic switch. These controls are enforced by the infrastructure, not by the agent's own code, so a bug or prompt injection in the agent cannot override them. The owner sets these boundaries before the agent starts, and they remain active until explicitly changed.

• ·Scoped keys restrict the API key to specific markets or order types. An agent authorized for stocks cannot accidentally place an order on a crypto perps venue, and an agent built for options cannot touch prediction markets.
• ·Budget caps set a hard ceiling on the total notional value the agent can expose across all positions. Once the cap is reached, the infrastructure rejects further orders regardless of what the agent requests.
• ·Position limits define the maximum size per asset or contract, preventing concentration beyond what the owner accepts. This limits the damage from a single bad signal or fat-finger error.
• ·Exit plans are pre-scheduled or condition-based flattening rules that close positions even if the agent loses connectivity or its host server crashes.
• ·Kill switches are manual or automated triggers that revoke the key and initiate a full flatten of all positions. This is enforced server-side, so it works even if the agent is unresponsive.

You can configure these controls through the dashboard or API before the agent starts trading. The details are covered in scoped API keys for trading agents. You should treat the configuration step as part of the strategy itself, not as an afterthought. Changing limits mid-session is possible, but it requires owner authentication to prevent the agent from relaxing its own constraints.

How is order sizing normalized across markets?

Algorithmic strategies often struggle with venue-specific contract math. A perpetual futures contract might be denominated in coins, an options venue might use notional units, and a stock broker might use share counts. Manually converting these inside an agent introduces errors.

Each venue has its own tick size, lot size, and margin formula. An agent that miscalculates by one decimal place can create an order that is ten times too large or too small. This complexity multiplies when a strategy trades across multiple asset classes.

To solve this, the API accepts orders sized in plain US dollars. When the agent requests a trade, it specifies the dollar amount it wants to expose or allocate. The infrastructure then normalizes the order into the correct size for the specific venue, whether that is a number of shares, a crypto amount, or a contract count. The agent does not need to know the tick size, lot size, or margin formula. This reduces complexity and lowers the risk of a sizing bug. The same dollar-based logic applies across all five market types, which is part of the design described in one API for every market. The owner still defines the total budget, but the agent and the API handle the translation into native units. This abstraction is especially useful when rebalancing a portfolio that includes both fractional shares and leveraged derivatives, because the dollar value is the common denominator.

What is the path from paper trading to live funds?

Before any capital is exposed, the agent should be tested in a paper trading environment. Paper trading simulates order placement, fills, and position tracking without touching real funds. It lets you verify that the agent interprets signals correctly, that safety controls trigger as expected, and that the logic handles edge cases. You can run paper trading for days or weeks to observe how the agent behaves across different market conditions. When you are ready to trade live, the transition requires an explicit owner authorization step. You generate a new scoped key or upgrade permissions, but only after reviewing the budget caps, position limits, and exit plans. The agent cannot self-authorize into live mode. Even after authorization, the owner can revoke access instantly through the kill switch. Paper trading and live authorization are separate states by design, so there is no accidental drift from simulation to real money. This separation gives you time to catch logic errors before they interact with actual market risk.

What are the risks you still need to manage?

Self-custody eliminates counterparty custody risk, but it does not eliminate trading risk. An automated strategy can lose money, including the entire budget allocated to it. Market volatility, model errors, and connectivity gaps can all create losses that no permission model can prevent. Suppose your agent is designed to buy dips in a trending market. If the trend reverses sharply, the agent will accumulate losses as each dip fails to recover. The kill switch can stop further entries, but it cannot recover the capital already deployed into losing positions. Similarly, if the model is overfit to historical data, it may fail in live conditions even if the code executes perfectly.

You should treat the agent as a tool that executes your strategy within guardrails, not as a guarantee of safety. The panic switch limits the scope of a runaway strategy, but it cannot reverse market moves that occurred before the switch was flipped. Similarly, dollar-based sizing simplifies contract math, but it does not validate whether the strategy itself is sound. Before going live, review the non-custodial trading checklist to confirm your controls, budgets, and exit plans are configured correctly. Start with a small live budget, observe behavior, and expand limits only after you have verified that the agent respects boundaries under real market stress. Trading can lose money, including everything, and self-custody does not change that fundamental fact.