How algorithmic traders maintain self-custody when using autonomous agents

Self-custody for algorithmic trading means that your funds remain in a wallet only you control, and the agent receives a scoped key that can place trades within limits you define. The agent never holds the private key, cannot withdraw funds to itself, and cannot move assets to an address you have not approved. Felix routes orders across stocks, crypto, perpetual futures, options, and prediction markets through one API while the underlying capital stays in your possession. This changes the trust model from depositing money with a platform to giving a narrow, revocable trading mandate to a piece of code.

What does self-custody mean for an automated strategy?

In the traditional algorithmic trading workflow, a developer writes a strategy, generates an API key at a stock broker or a crypto exchange, deposits funds, and lets the program trade. The funds live on the platform, and the API key often has broad permissions that include trading, reading balances, and sometimes withdrawing. If the key is leaked, the strategy has a bug, or the server is compromised, the entire balance can be at risk. The trader must trust the platform's custody, the platform's withdrawal policies, and the platform's own security stack. For developers who treat trading infrastructure as code, this trust model is fragile. It mixes the execution layer with the custody layer, and it gives a single secret far more power than it needs. The result is that operational security for the strategy becomes indistinguishable from operational security for the exchange itself, which is a scope most developers cannot control.

Self-custody separates these layers cleanly. Your wallet, which you control with your private key or hardware signer, holds the funds. The trading agent receives a scoped key that is cryptographically restricted to specific actions. It can request a buy or sell, but it cannot move the underlying assets to a new wallet. It can spend up to a budget cap you set, but it cannot increase that cap. The agent is essentially a trader with a tightly written mandate, not a treasurer with the keys to the vault. This distinction is important because algorithmic strategies are inherently fallible. A logic error, a bad data feed, or an unexpected market event can cause a strategy to behave erratically. When the funds are under your own custody, the damage is bounded by the limits you set, not by the total balance on an exchange. You are not relying on the exchange to freeze the account or roll back trades. You are relying on mathematics and cryptography that enforce the boundaries before the order ever leaves the system.

This model also simplifies operational security. You do not need to manage withdrawal whitelists on five different venues or worry about whether a perps venue or an options venue has a different policy on API key permissions. The safety model is unified. You set the rules once, and they apply across every market type. The agent operates inside a sandbox defined by your wallet and the infrastructure, not by the terms of a custodial account.

How does the agent place orders without taking custody?

The Felix API sits between the agent and the trading venues. The agent does not talk directly to a stock broker, a crypto exchange, a perps venue, an options venue, or a prediction market. Instead, it sends an order intent to the API, which normalizes the request and routes it to the appropriate venue. The agent expresses size in plain US dollars, and the infrastructure handles the contract math, margin calculations, and venue-specific formatting. This means the developer does not need to maintain separate code paths for equities, perpetual futures, and options. The agent thinks in dollars and directions; the infrastructure translates that into the native language of each venue. You do not need to import five different SDKs or manage five different authentication flows. You write one integration, and the API manages the heterogeneity of the underlying markets.

Because the funds remain in your wallet, settlement is non-custodial by construction. When the agent requests a trade, the infrastructure constructs the transaction or order such that the resulting position or asset is still under your control. For markets that require margin, the margin is allocated from your wallet within a bounded sub-account or contract structure that you own. The agent cannot reallocate that margin to a different wallet or withdraw it. Withdrawal addresses are owner-approved only, and the approval step requires a signature from your private key. The agent, which only has its scoped key, cannot produce that signature. Even if the agent is a large language model connected through an MCP tool, it operates with the same constraints as a traditional algorithm. It cannot social engineer its way around a cryptographic boundary.

The exact request schema is in the docs; the shape looks like this.

{
  "intent": "buy",
  "market": "perpetual_futures",
  "symbol": "ETH",
  "size_usd": 1000,
  "api_key": "YOUR_KEY"
}

In this illustrative shape, the agent declares what it wants to do and how much notional exposure it seeks. The infrastructure checks the request against the scoped permissions, budget caps, and position limits before it reaches a venue. If the request violates any of those constraints, it is rejected at the API layer. The agent does not need to know the venue's tick size, margin requirements, or lot sizes. That abstraction reduces the surface area for bugs and prevents the agent from accidentally sending malformed orders that could be misinterpreted by a venue.

Why is a non-custodial setup safer for developers?

Developers are used to thinking about least privilege in software engineering. A database client should not have root access. A microservice should not have credentials for another team's cluster. The same principle applies to trading, but it is often ignored because legacy APIs force developers to choose between full access and no access. A non-custodial infrastructure enforces least privilege by default. The scoped key is generated with a specific budget, a specific set of markets, and a specific set of allowed actions. It cannot be used to read your wallet balance, change withdrawal addresses, or modify the scope itself. Those actions require owner approval through your private key.

If the agent's server is compromised, the attacker gains only the ability to trade within the remaining budget. They cannot sweep the wallet. They cannot change the scope to allow larger trades. They cannot withdraw to an address they control. This is a fundamental reduction in blast radius. In a custodial setup, a leaked API key can mean total loss. In a non-custodial setup, a leaked scoped key means at most the loss of the remaining budget cap, and that loss is further bounded by position limits and kill switches. The difference is structural, not merely contractual.

The safety controls are enforced by the infrastructure, not by the agent's code. This is critical. You do not need to trust your own strategy to behave. You do not need to audit every line of code to prove it will never exceed a certain risk threshold. The infrastructure enforces the hard limits independently. How autonomous trading systems enforce hard limits the agent cannot cross explains this in detail. The unified model also means that a single set of controls protects you across every market type you choose to trade. How a single API keeps AI trading agents safe across every market covers the architecture of that safety layer.

What controls should algorithmic traders set before going live?

Before an agent touches real markets, you should define a set of hard constraints that the infrastructure enforces independently of the strategy. These controls create a safety perimeter around the agent. Consider setting the following:

• ·Budget caps limit the total notional value the agent can deploy over a given period. Once the cap is reached, the API rejects further orders until you manually raise it or the period resets.
• ·Position limits restrict the maximum exposure per asset, per market, or in total. They prevent the agent from concentrating the entire budget into one trade.
• ·Exit plans define conditions, such as drawdown thresholds or time limits, under which the agent must reduce exposure. The infrastructure enforces these, so the agent cannot ignore them.
• ·A panic or kill switch flattens all positions and revokes the scoped key. This is your emergency brake for security incidents, market crashes, or strategy degradation.

Testing should begin in paper trading. Paper trading uses the same API and the same order sizing logic, but it does not move real funds. It lets you verify that the agent interprets signals correctly, that the guardrails trigger as expected, and that the integration with your data pipeline is stable. Only after you have audited the behavior should you authorize a live key. How to paper trade an AI agent with hard limits it cannot cross describes how to run these tests safely. Before you authorize live trading, you should also audit the guardrails to confirm they match your intended risk profile. How to audit your trading agent guardrails before going live provides a step-by-step checklist for that review.

What happens when the strategy fails or the agent misbehaves?

All automated strategies fail eventually. A model that worked in backtesting may break in live markets because of regime change, liquidity shifts, or data errors. When that happens, the first line of defense is the drawdown limit. If the agent's positions lose a predefined percentage of the budget cap, the infrastructure can halt trading automatically. This is not a guarantee of preserving capital, but it prevents a runaway strategy from trading indefinitely into deeper losses. Trading can lose money, including everything, and hard limits exist to cap the speed and scale of that loss. The drawdown limit is a circuit breaker, not a safety net. It stops the bleeding, but it does not heal the wound.

The second line of defense is the kill switch. You can trigger it manually, or you can set automated triggers based on metrics you define. When activated, the switch flattens positions and revokes the scoped key. Because the funds are in your wallet, you can also revoke access directly on-chain or through your wallet interface, independent of the API. This dual-layer revocation is unique to non-custodial setups. In a custodial account, revoking an API key might leave open orders or unsettled margin on the exchange. In a self-custodial model, the kill switch is designed to unwind and lock out simultaneously.

It is important to understand that these controls limit operational and custody risk, not market risk. If you allocate a budget cap of ten thousand dollars and the strategy is bad, you can lose that ten thousand dollars. Self-custody prevents the agent from stealing the rest of your funds or moving them to an unknown address. It does not prevent a bad trade from losing money. That distinction is central to how developers should think about risk. The infrastructure protects you from the agent; it does not protect you from the market.

How do you move from testing to live trading without giving up control?

The transition from paper trading to live trading is a deliberate, manual step. Paper trading exists for testing; live trading requires explicit owner authorization of a key. When you create a scoped key for paper trading, it is automatically restricted to simulation. To enable live trading, you must sign an authorization message with your private key. This message specifies the exact scope, budget cap, and markets for that key. You review the terms before signing. The agent cannot upgrade itself from paper to live. The infrastructure will not accept a live order from a paper key, and it will not accept an order that exceeds the signed scope. This design removes the possibility of an accidental deployment where a test script suddenly starts trading real money because of a configuration flag you forgot to set.

This authorization step is a forcing function. It requires you to pause and verify that the guardrails match your intent. You can authorize multiple keys with different scopes. For example, you might authorize one key for perpetual futures with a one thousand dollar cap, and another for prediction markets with a separate cap. Each key is independent. If you decommission a strategy, you revoke its key without affecting the others. This granularity is useful for developers who run multiple strategies or who want to test a new algorithm alongside a stable one.

After authorization, the agent operates within the live scope until the budget cap is reached, the exit plan triggers, or you revoke the key. You can monitor the agent's activity through the API or through your wallet's view of the positions. Because the funds never leave your custody, you always have a direct view of the balance and the open exposure. You do not need to reconcile balances across multiple exchange accounts. The single wallet and the single API provide a unified view of capital and risk, which is especially valuable for developers who treat portfolio state as a data structure that their monitoring systems can query.