How algorithmic traders keep self-custody with a single API

Algorithmic traders can keep full custody of their funds while automating strategies across multiple asset classes through a single non-custodial API. The owner controls the wallet, approves every withdrawal address, and sets hard limits that the agent cannot override. This model lets the agent trade real money in stocks, crypto, perpetual futures, options, and prediction markets without ever taking possession of the funds.

How does self-custody work with a single API?

Traditional algorithmic trading often requires depositing capital into a custodial account controlled by a third party. In that model, the exchange or broker holds your funds, and your algorithm interacts with their internal ledger. You do not hold the private keys to the underlying assets, and your access depends on the platform's continued operation and policies. The single API approach described here inverts that relationship entirely. Your funds remain in a wallet that only you control, and the API acts as a permissioned routing layer between your agent and the market venues. The agent receives a scoped key that allows it to place orders, read positions, and manage exposure within boundaries you define, but it cannot initiate a withdrawal to any address that you have not previously approved. This is non-custodial by construction, not by policy, because the underlying architecture makes it technically impossible for the agent to move funds outside your control. Even if the agent is compromised or its logic malfunctions, the worst it can do is trade within the limits you set. It cannot drain the wallet.

What does the setup look like step by step?

The walkthrough from an empty wallet to a live agent follows a clear sequence that emphasizes verification at each stage. First, you create and fund a wallet where you alone hold the credentials. This wallet is the single source of truth for your capital. Second, you define your risk parameters, including total budget, per-market limits, and maximum position sizes. These are not suggestions; they are encoded into the key itself. Third, you generate a scoped API key that carries those constraints. Fourth, you connect your agent using either MCP tools for environments like Claude or Cursor, or the REST API directly. Fifth, you run the agent in paper trading mode to observe how it respects the guardrails under simulated market conditions. Sixth, and only after you are satisfied that the behavior is correct, you explicitly authorize the key for live trading. At that point the agent can place real orders, but it still cannot breach the hard limits you set during step two.

1. 01Create and fund a wallet that you control exclusively.
2. 02Define your risk parameters, including total budget and per-market limits.
3. 03Generate a scoped API key that encodes those constraints.
4. 04Connect your agent through MCP tools or the REST API.
5. 05Run in paper trading mode to validate behavior and controls.
6. 06Explicitly authorize the key for live trading once you trust the setup.

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

curl -X POST https://api.felix.trade/... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{\n    "market_type": "perps",\n    "symbol": "ETH-USD",\n    "side": "buy",\n    "notional_usd": 500\n  }'

Notice that the order is sized in US dollars, not in contracts or token amounts. The API translates that five hundred dollars into the correct number of contracts or tokens for the specific venue. You can find more detail on connecting agents without surrendering custody in How to automate trading agents with webhooks without losing custody.

How do you scope permissions without losing control?

Scoped permissions are the mechanism that makes self-custody practical for automation. A scoped key is not a universal password; it is a credential that carries a built-in policy. You can restrict it to specific market types, such as stocks and prediction markets, while excluding crypto or options. You can attach a budget cap, so that the cumulative notional value of all orders cannot exceed a dollar threshold you choose. You can set position limits, preventing the agent from concentrating more than a defined amount in any single asset. You can also restrict the key to read-only access if you want the agent to monitor markets without trading. These constraints are enforced by the API itself, not by the agent, which means a misbehaving or compromised agent cannot talk its way out of the limits. The enforcement happens at the infrastructure level, below the agent's logic.

Beyond trading limits, the system includes an exit plan and a panic switch. An exit plan defines automatic flattening conditions, such as a drawdown threshold or a time-based session close. When the condition is met, the system attempts to close all positions and cancel open orders. If the exit plan fails or you simply want to stop the agent immediately, the panic switch overrides everything. It flattens positions and revokes the API key in a single action, cutting off access faster than the agent can place new orders. Once revoked, the key is useless, and the agent loses all access until you generate a new one. This design means you retain an off switch that does not depend on the agent's cooperation. You can read more about configuring these controls in How to set guardrails for a trading agent.

• ·Scoped keys restricted to specific market types or actions.
• ·Budget caps that enforce a maximum notional spend.
• ·Position limits that prevent concentration in any single asset.
• ·Exit plans that automatically flatten under predefined conditions.
• ·A panic switch that revokes access and unwinds positions immediately.

How does one API normalize order sizing across markets?

One of the practical barriers to multi-market algorithmic trading is the variety of contract specifications across venues. A perps venue might use coin-margined contracts with a specific tick size and leverage multiplier. An options venue might quote in contracts that represent one hundred shares, with premiums quoted in points. A crypto spot market might require precision to eight decimal places, while a stock broker may only accept whole share quantities for certain tickers. The API removes this complexity by accepting orders in plain US dollars. When you or your agent sends an order for five hundred dollars, the API calculates the equivalent number of shares, contracts, or tokens at the current market price, and submits the correctly sized order to the venue. This normalization reduces the risk of sizing errors that occur when an agent miscalculates contract math or confuses notional value with contract quantity. You do not need to maintain separate sizing modules for each market type.

Because the abstraction is consistent, you can move the same strategy logic across market types without rewriting the sizing layer. A dollar-based approach also makes budget caps and position limits intuitive. You state your risk in the currency you care about, and the infrastructure handles the translation. You can read more about this unified interface in How to trade every market type through one API with real money.

Why is paper trading required before live authorization?

Paper trading exists so that you can test every assumption before real money is at risk. In paper mode, the agent executes against simulated market data and liquidity, while the full set of guardrails and budget caps remains active. This lets you observe whether the agent correctly interprets your prompts, whether it respects the scoped key limits, and whether the dollar-based sizing produces the expected notional exposures. Errors that might be expensive in live markets, such as sending an order ten times too large, misreading a symbol, or looping on a broken signal, surface in simulation without financial damage. The paper environment is identical in terms of API behavior, error codes, and control enforcement, so a successful paper test is a meaningful signal that your setup is sound. It is not a guarantee of profit, but it is a necessary filter for catastrophic configuration mistakes.

Live trading requires an explicit owner authorization step for a reason. You must manually upgrade the key from paper to live after you have reviewed the logs, verified the guardrails, and confirmed that the strategy logic behaves as intended. This deliberate gate prevents accidental live deployment. If you are evaluating an agent's performance, paper trading is the only honest baseline. More guidance on that evaluation process is available in How to evaluate paper trading for an AI agent before live markets.

What happens when an agent needs to exit or you want to stop it?

Every automated strategy needs a clear termination path, regardless of how well it is performing. The API supports exit plans that you define before the agent starts trading. These plans can specify conditions such as a target drawdown percentage, a time limit for the session, or a profit target that triggers a full flatten. When the condition is met, the system attempts to close all positions and cancel open orders. If the exit plan fails, or if you simply want to stop the agent immediately because market conditions have shifted, the panic switch overrides everything. It flattens positions and revokes the API key in a single action, cutting off access faster than the agent can place new orders. The revocation is permanent for that key, and you must issue a new one if you want to resume.

After a panic or a normal exit, your funds remain in your wallet. There is no withdrawal queue, no settlement delay imposed by a custodian, and no risk that the agent locked your capital in an unauthorized account. You can rotate keys, adjust limits, and restart the agent without moving funds between accounts. It is important to remember that trading can lose money, including the entire balance allocated to the strategy. Self-custody protects you from theft by the agent or the platform, but it does not protect you from market risk or from an agent that trades poorly within its allowed budget. Hard limits exist to contain damage, not to eliminate risk or guarantee profit.