How developers can start self-custody algorithmic trading

Self-custody algorithmic trading means your trading agent executes orders through an API while your funds remain in a wallet that only you control. You grant the agent scoped permissions to spend within limits, but the agent cannot withdraw funds or change where money leaves. Felix provides one API and one key that normalizes access to stocks, crypto, perpetual futures, options, and prediction markets without taking custody of your capital. This model lets developers automate strategies without depositing funds to a third party or surrendering control of their assets.

What does self-custody mean for algorithmic traders?

Algorithmic traders usually face a choice between convenience and control. If you deposit funds directly to a venue, you accept custody risk and operational overhead. You must manage withdrawals, handle API downtime, and trust that the venue's internal controls match your security model. Self-custody reverses this relationship. Your wallet holds the assets. The agent receives an API key that can submit orders and manage positions, but cannot move funds to an unauthorized address. This is non-custodial by construction, not by policy. The system enforces the boundary cryptographically and architecturally. Even if the agent is compromised, the attacker cannot drain the wallet. They can only trade within the limits you set, and they cannot alter withdrawal addresses because those are owner-approved only. This model is especially important for developers who run automated strategies while they sleep. You do not need to trust the agent with your capital. You only trust it with a bounded budget and a narrow set of actions. The infrastructure sits between your wallet and the market venues, normalizing orders and enforcing limits without ever taking possession of your funds. Developers are accustomed to handling secrets and API credentials. Self-custody extends that discipline to capital itself. You do not need to trust a custodian's database or their withdrawal policies. You control the wallet. You control the keys. You control the limits. For a deeper look at the architecture, see non-custodial trading for AI agents.

Why do developers need scoped keys instead of exchange credentials?

Developers who build bots for traditional venues often receive API keys that can trade, withdraw, and transfer. A single leaked key can empty an account. Scoped keys solve this by splitting permissions into narrow, explicit grants. A Felix scoped key can be restricted to specific market types, dollar budgets, and position sizes. It can be forbidden from withdrawing entirely. This means a developer can generate a key for an agent that trades prediction markets, set a $500 monthly budget, and know that the agent cannot pivot to perps or move funds out. The scope is enforced by the infrastructure, not by the agent's prompt. This removes an entire class of accidents where a misinterpreted instruction or a looped script causes catastrophic loss. You can rotate or revoke the key without moving funds or contacting a support desk. The revocation is immediate and cryptographic. Scoped keys also simplify secret management in your codebase. You can embed a key in an environment variable knowing that its maximum exposure is the predefined cap. If you run multiple agents, you give each a separate key with non-overlapping budgets. This isolation prevents one agent's error from cascading into another's capital. The principle is straightforward: the agent should have exactly the access it needs, for exactly the markets it trades, and no more. This is the foundation of safe algorithmic deployment.

How do you connect an agent without giving up control of funds?

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

curl -X POST ... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "market_type": "crypto",
    "direction": "buy",
    "budget_usd": 150
  }'

Your agent does not need to understand venue-specific contract math. You express intent in plain US dollars. The API translates the intent into the correct lot size, tick size, and margin requirements for the underlying venue. You can connect Claude, Cursor, or any MCP client to the same key and trade across stocks, perps, options, and prediction markets without managing multiple integrations. The funds remain in your wallet. The agent merely sends signed instructions that the infrastructure validates against your scoped limits before execution. This separation of concerns is critical. The agent reasons about strategy. The infrastructure reasons about safety, sizing, and routing. You retain the ability to inspect, pause, or revoke the connection at any time without changing wallet ownership or moving funds between accounts. For developers, this means you can write logic in Python, TypeScript, or any language that speaks HTTP, and you do not need to maintain adapters for each venue's idiosyncratic order formats. You focus on alpha generation. The platform handles venue normalization.

What safety controls should you configure before going live?

Before you authorize a live key, you should define the worst case and work backward. Start with a hard budget cap that reflects money you can afford to lose entirely. Trading can lose money, including everything you allocate. Add position limits so the agent cannot concentrate more than a fixed percentage of the budget in a single instrument. Configure an exit plan that automates take profits and stop losses at the infrastructure level, not inside the agent's reasoning loop. This ensures that even if the agent halts, the network, or the model provider fails, your positions are protected by rules the agent cannot override. You should also install a panic kill switch that flattens all positions and revokes the key. The kill switch is owner-controlled and out-of-band from the agent. Think of these controls as layers. The budget cap is the outer perimeter. Position limits are the inner perimeter. Exit plans are the automated response. The kill switch is the emergency brake. Each layer is independent of the agent's code or the model's behavior. They are enforced by the same infrastructure that routes orders. You set them before deployment, and they persist until you change them. For guidance on building a kill switch, see how to build a kill switch your trading agent cannot override.

How do you test and promote an agent from paper to live trading?

Felix offers paper trading so you can test integration and logic without capital at risk. Paper trading mirrors the live API behavior, but fills are simulated. Use this phase to verify that your agent respects scoped limits, formats orders correctly, and handles errors. Do not assume that paper profitability predicts live results. Slippage, latency, and market impact differ when real money is on the line. Many beginners overfit to paper behavior. The fills you see in simulation may not reflect the depth of the order book at a live venue. Treat paper trading as an integration test, not a performance backtest. When you are ready to go live, you must explicitly authorize a new scoped key for real trading. This is a deliberate, owner-initiated step. The system will not promote a paper key automatically. You should allocate a small budget first, monitor logs, and only increase limits after observing stable behavior under real conditions. Suppose you start with a $200 weekly cap. After two weeks of correct execution, you might raise it to $500. If the agent breaches a limit or exhibits unexpected behavior, revoke the key and return to paper. This iterative promotion reduces the risk of deploying untested logic with full capital. For a discussion of paper trading gaps, read why paper trading misleads beginners who build AI agents.

How do you monitor and shut down an agent safely?

Running an agent is not a set-and-forget operation. You need audit logs that show every order, fill, rejection, and scope check in one place. Centralized logging lets you detect drift, such as an agent repeatedly retrying failed orders or edging against position limits. Review logs daily during the first weeks of live trading. Look for patterns that indicate the strategy is behaving differently than in paper mode. If you trade across multiple market types, monitor correlations. A position in a perps venue and a correlated option can create hidden leverage that blows through your budget cap even if each individual position looks small. The same underlying asset traded in different forms can amplify risk in ways the agent does not perceive because it sees each market independently. You must own the portfolio-level risk management. Over time, you may automate monitoring alerts that notify you when an agent approaches a limit or when a new market correlation appears. Until then, manual review is a small price for preserving capital. For guidance on log analysis, see how to evaluate audit logs and observability for trading agents through one API. When you need to stop, use the kill switch. Do not rely on asking the agent to stop. The kill switch is infrastructure-level and immediate. After activation, rotate your keys and review the incident before restarting. Document what triggered the shutdown and adjust your scoped limits or exit plan before redeploying. This discipline turns a potential disaster into a controlled experiment.