A practical checklist for non-custodial trading through one API

Trading through a single API across stocks, crypto, perpetual futures, options, and prediction markets does not require depositing funds into a custodial wallet. Felix keeps the architecture non-custodial by default, meaning the owner retains control of the wallet while the agent receives scoped permissions to trade within limits. The agent can open and close positions, but it can never withdraw funds to an external address or move capital outside owner-approved destinations. This article provides a practical checklist for configuring that arrangement safely.

what does non-custodial mean when an API is involved

In this context, non-custodial means the API key itself is bound by constraints that prevent it from taking custody of your funds. The underlying capital remains in a wallet that only you control, and the agent is granted a scoped key that can place orders, manage positions, and read market data. It cannot add new withdrawal addresses, move funds to itself, or revoke your own access. Even if the agent’s environment is compromised, the attacker gains only the ability to trade within the pre-defined limits, not the ability to steal the wallet. This is a structural guarantee enforced by the key scope, not merely a policy promise. It is important to remember that trading can lose money, including the entire budget allocated to the agent, so the safety model is designed to prevent theft, not to prevent losses from market movement. The distinction matters because many traders assume non-custodial means safe, but the real risk is market risk inside the boundaries you set.

how do scoped keys keep the agent inside its lane

Scoped keys are the primary mechanism that enforces boundaries on an agent. When you create a key, you define exactly which markets it can access, which actions it can perform, and how much capital it can deploy. For example, you might authorize an agent to trade crypto and perpetual futures while blocking access to options and prediction markets. You might also set a maximum single-trade size of one thousand dollars and a daily budget of five thousand dollars. The API rejects any request that violates these bounds, regardless of what the agent decides to do. This means the agent operates inside a hard perimeter that you define before it starts. You can create multiple scoped keys for different strategies or different agents, each with its own constraints, and rotate them regularly without changing the underlying wallet. How scoped API keys work without custody explains the architecture in more detail. The key is the only credential the agent holds, so revoking the key instantly removes access without requiring changes to the underlying wallet or any on-chain operations.

what budget and position limits should you set before the first trade

Before the agent sends its first order, you should decide how much capital it is allowed to risk and how it can size positions. The API normalizes order sizing in plain US dollars, so you do not need to translate contract multipliers, lot sizes, or margin requirements for each venue. A five-hundred-dollar order is a five-hundred-dollar order regardless of whether the underlying market is a stock, a crypto pair, or a perpetual future. This simplifies the checklist because you can think entirely in dollar terms and compare risk across market types without learning venue-specific contract math. You can set a universal maximum trade size and know that it applies consistently to every market the agent touches.

• ·Set a total budget cap that the scoped key cannot exceed over a defined period.
• ·Set a maximum position size per trade in US dollars that the agent cannot override.
• ·Set a maximum number of concurrent open positions so the agent cannot stack unlimited risk.
• ·Define a drawdown or loss threshold that triggers an automatic pause or notification.
• ·Require the agent to log every intended trade before execution so you can audit its reasoning.

These limits are enforced at the API level, not by the agent’s logic, so a bug or prompt injection cannot bypass them. The system evaluates the requested order against the key scope before it reaches the venue. If the order would exceed the cap, the API returns an error and the agent must adjust. Common position sizing mistakes covers additional patterns that cause agents to deploy capital incorrectly, such as doubling down after a loss or splitting one large order into many small ones to evade limits. Start with a budget you can afford to lose entirely, because markets can move against any position and stop-losses are not always filled at the exact price you specify.

how should you prepare exit plans before the agent goes live

Every entry should have a planned exit before the trade is opened. An agent without exit rules can hold a losing position indefinitely, close a winner too early, or add to a losing trade in ways that compound risk. You should configure the following controls before authorizing live trading. The exit rules should be part of the agent’s system prompt and also reflected in the API configuration where possible, so there are two layers of enforcement.

• ·Set a stop-loss rule for every position, defined in plain US dollars or as a percentage of the entry price.
• ·Set a take-profit target or a trailing exit rule that captures gains without requiring manual intervention.
• ·Define a maximum holding period after which the agent must reduce or close the position, regardless of profit or loss.
• ·Configure a panic or kill switch that flattens all positions and revokes the scoped key if a major anomaly occurs.

These rules should be part of the agent’s system prompt or strategy configuration, but they should also be mirrored by the API’s safety controls where possible. A stop-loss defined only in the agent’s mind can fail if the agent crashes or hangs. A stop-loss enforced by the API or the venue is more reliable. Exit plans and take-profit automation provides a deeper guide on structuring these rules. Testing the kill switch in paper mode is essential. You should verify that triggering it closes positions and disables the key within seconds, and you should repeat this test after any change to the strategy or the key scope. If the kill switch fails in paper mode, do not authorize live trading.

what is the safest path from paper trading to live authorization

Felix provides paper trading so you can test the full flow without risking capital. Paper mode uses the same API shape, the same order sizing logic, and the same scoped key constraints as live trading, but it executes against simulated markets. This is not a guarantee of future performance, and paper results often differ from live results due to slippage, liquidity, and latency. Still, paper trading is the right place to validate that the agent respects limits and that your monitoring tools work correctly. Use paper mode to confirm that the agent handles errors gracefully, that it does not retry failed orders in ways that violate rate limits, and that your logging pipeline captures every action.

1. 01Run the agent in paper mode for a sustained period to observe its behavior across different market conditions, including volatile periods.
2. 02Verify that the scoped key enforces budget caps, position limits, and market restrictions exactly as intended, even when the agent sends rapid successive orders.
3. 03Test the exit plans, stop-losses, and kill switch repeatedly to confirm they flatten positions and revoke access without manual cleanup.
4. 04Review audit logs to ensure the agent’s reasoning and actions are transparent and consistent, and that no unexpected venue interactions occur.
5. 05Authorize the live key with a small initial budget, then scale only after observing stable behavior over multiple sessions.

Live trading requires explicit owner authorization of a key. The system will not allow an agent to trade real money until you manually approve the transition, and the authorization step is deliberately separate from the key creation step. How to place your first automated trade in any market walks through the mechanical steps. Even after authorization, keep the initial budget small. Trading can lose money, and an agent that behaves correctly in paper mode may still encounter edge cases in live markets, such as partial fills, rejected orders due to margin changes, or price gaps that bypass stop-loss levels. Scaling up should happen gradually, with new budget caps set at each stage rather than giving the agent unlimited access from the start.

how do you monitor the agent and revoke access when something breaks

Continuous monitoring is the final layer of the checklist. You need visibility into what the agent is doing across all five market types in real time. The dashboard should show open positions, unrealized profit and loss, available budget remaining, and recent key usage. Set alerts for when the agent approaches its budget cap, opens a position larger than expected, or trades in a market that was supposed to be restricted. The API normalizes data across venues, so a position in a perps venue and a position in a stock broker appear in the same unified view. You should also monitor the latency between the agent’s decision and the order confirmation. Unusual delays can indicate connectivity issues, venue problems, or unexpected behavior that warrants investigation. Good observability includes not just financial metrics but also the sequence of API calls. If the agent starts calling endpoints it has never used before, or if the frequency of requests spikes, treat that as a signal to review the strategy or revoke the key until you understand the change.

Revocation should be a one-click action. If the agent behaves unexpectedly, if market conditions change suddenly, or if you simply want to stop, the kill switch should flatten all positions and invalidate the scoped key immediately. After revocation, generate a new key only after you have diagnosed the issue and updated the safety parameters. Never feel obligated to keep an agent running. The goal is to let the agent trade inside a bounded sandbox that you control completely. If the sandbox needs to close, you should be able to close it in seconds. Reviewing the logs after a revocation is a critical habit. Look for patterns in the agent’s decisions that led to the problem, and adjust the prompts, limits, or exit rules before restarting. An agent that is restarted without diagnosis is likely to repeat the same mistake. You should also verify that no orphaned orders remain open after the kill switch runs, because partial fills or delayed confirmations can sometimes leave unexpected positions active.