How Felix keeps crypto agent trading safe

Felix keeps crypto trading safe by making the agent non-custodial by construction. The owner keeps funds in a self-controlled wallet, and the agent receives only a scoped API key that can trade within hard limits but can never withdraw or steal. Safety controls include budget caps, position limits, exit plans, and a kill switch that flattens positions and revokes access instantly. Orders are sized in plain US dollars, and the API normalizes venue-specific contract math so the agent does not need to handle leverage formulas or lot sizes directly.

What does non-custodial mean when an agent trades crypto?

In most automated trading setups, the user deposits funds to a platform, exchange, or bot service. The operator, or a hacker of that operator, can then move or steal those funds. Felix removes that risk by design. The wallet that holds the crypto belongs to the owner alone. The agent never receives a private key, seed phrase, or withdrawal permission. Instead, the owner creates an API key with a narrow scope. That scope can include placing orders, reading balances, and canceling open trades. It cannot include adding withdrawal addresses, changing account ownership, or moving assets to another wallet. Withdrawal addresses are owner-approved only, and that approval happens outside the agent's session. Even if the agent's logic is hijacked through a prompt injection or a compromised MCP client, the key's permissions form a hard boundary. The attacker could potentially place bad trades, but only within the budget and market limits already set. They could never empty the wallet. This architecture applies across all five market types, including crypto spot, perpetual futures, and options. The same non-custodial guarantee holds whether the agent trades on a single venue or across several through the unified API. Because the funds stay in the owner's wallet, there is no counterparty risk from the agent infrastructure itself. If the Felix API were to go offline, the owner still controls the underlying assets and can interact with the venue directly or move funds to cold storage. The agent is merely a permissioned user of the account, not a custodian. This is the foundation of the safety model. You can read more about the underlying design in MCP trading safety first principles.

How do scoped keys and budget caps limit what an agent can do?

Scope is the primary control surface. When an owner provisions a key for an agent, they define which markets it can access, the maximum notional size of any single order, the total daily or weekly budget, and whether it can use leverage. These rules are enforced server-side by the Felix infrastructure, not by the agent's own code or by a prompt that the agent might ignore. If the agent attempts to place an order that exceeds the notional cap, the API rejects it before the request reaches the venue. If the agent tries to trade a market that is not in the allowed list, the request fails. This means that a bug in the agent's reasoning, a misunderstanding of units, or a malicious instruction injected through an external prompt cannot expand the owner's exposure beyond the pre-set fence. Budget caps work in tandem with position limits. A budget cap might allow the agent to spend up to five thousand dollars per day. A position limit might restrict any single trade to five hundred dollars. Together, they prevent the agent from concentrating too quickly in one asset, while still allowing meaningful activity across a portfolio. Drawdown limits add a dynamic layer. The owner can set a maximum acceptable loss, either in absolute dollars or as a percentage of the allocated budget. If the running PnL hits that floor, trading halts automatically. The agent does not get to argue or retry. The session ends until the owner resets it. These controls are configured before the agent starts, and they are immutable from the agent's side. For a deeper guide on configuring these values, see How to set spend caps and drawdown limits. The exact request schema is in the docs; the shape looks like this:

{
  "scope": {
    "markets": ["crypto", "perps"],
    "max_order_usd": 500,
    "daily_budget_usd": 5000,
    "allow_withdrawal": false
  },
  "kill_switch": {
    "max_drawdown_pct": 10,
    "auto_flatten": true
  }
}

These fields are illustrative. The actual schema may include additional parameters for market-specific logic, but the principle remains the same. The owner defines the boundary, and the system enforces it. Because the agent connects through MCP tools or the REST API, it cannot bypass these checks by formatting the request differently. The enforcement happens at the infrastructure layer, below the agent's visibility. Even if the agent were to discover a hypothetical bypass in its own code, the server-side validation would still block the request.

What happens if the agent starts losing money?

Losses are an expected part of trading, and an agent can lose money just as a human can. The safety model does not promise profits. Instead, it limits how fast losses can accumulate and how far they can go. The first line of defense is the exit plan. Before the agent starts, the owner configures pre-registered exit instructions. These can include stop-loss prices, take-profit targets, trailing stops, or time-based exits. The system monitors fills and unrealized PnL continuously. When a condition is met, the system sends exit orders directly. It does not delegate the decision back to the agent. This prevents a scenario where the agent, due to a reasoning loop or a bad prompt, refuses to close a losing position. The second line of defense is the drawdown limit. If the portfolio value drops by the configured amount, trading is suspended and the agent cannot increase risk. The third and final line is the kill switch. The owner can trigger it manually through a dashboard or an authenticated API call. Some owners also configure automatic triggers tied to the drawdown limit. When activated, the kill switch revokes the agent's key immediately, cancels all open orders, and flattens every open position. The agent cannot override this. It cannot un-revoke the key or place new orders to hedge. The owner must explicitly create and authorize a new key if they want to resume. This is a hard stop designed to contain damage. It is important to test the kill switch in paper trading before going live, so that the owner knows the latency and the exact behavior. In live markets, especially crypto, slippage and gaps can mean that the exit price is worse than the stop level. The kill switch closes the position, but it cannot guarantee a specific fill price. Trading can lose money, including the entire allocated budget, and these controls reduce the probability of an uncontrolled spiral rather than eliminating loss.

How does plain-dollar sizing prevent contract math errors?

Crypto venues, especially for perpetual futures and options, require traders to think in contracts, lot sizes, leverage ratios, margin tiers, and multipliers. An AI agent that reasons in natural language is prone to errors when converting a dollar amount into the native units of a venue. A mistake in decimal placement or leverage calculation can turn a small intended trade into a massively oversized position. The Felix API removes this entire class of risk by accepting orders in plain US dollars. The owner or agent states the notional amount they want to trade, and the system calculates the correct number of contracts, checks the available margin, and submits the native order to the venue. For example, if the agent wants to buy two hundred dollars worth of a major crypto perpetual future, it sends an order for two hundred dollars. The API handles the conversion to the venue's contract size, applies the current leverage settings, and ensures the total notional does not exceed the scoped limit. The same logic applies to options. The agent can express a desire to buy one hundred dollars of a call option, and the system translates that into the appropriate number of contracts. This abstraction also makes risk management consistent. The budget cap, the position limit, and the order size are all denominated in the same unit. The agent does not need to query tick sizes, minimum lots, or notional values. It thinks in dollars, and the system enforces in dollars. This reduces the cognitive load on the agent and prevents a common source of automated trading accidents. It also means that risk checks are easier to audit. An owner can read a log and see that the agent tried to spend five hundred dollars, rather than trying to reverse engineer whether three point seven contracts at one hundred twenty five dollars per contract with twenty times leverage was within the rules.

How do you test safety controls before live trading?

Every safety feature in the live environment has a matching equivalent in paper trading. The owner can run the agent against simulated markets with the same key scopes, budget caps, drawdown limits, and exit plans. This allows them to observe how the agent behaves when it hits a limit, when a stop loss fires, or when the kill switch is triggered. Paper trading uses the same API paths and MCP tools, so the integration code does not change. The only difference is that fills are simulated and no real money moves. When the owner is satisfied that the agent respects the limits and that the safety controls behave as expected, they can move to live trading. This transition requires explicit owner authorization. The agent cannot graduate itself from paper to live. The owner must create a live-scoped key, review the limits one more time, and approve it. This human-in-the-loop step ensures that the agent never touches real capital without conscious consent. It is a deliberate friction point that protects against accidental deployment. During paper trading, owners should also test edge cases. For example, they should trigger the kill switch manually while the agent has open orders to verify that cancellation and flattening work. They should also simulate a drawdown breach to confirm that trading halts. Owners should vary the simulated market conditions to see if the agent's strategy produces unexpected concentrations or violates the spirit of the budget even while respecting the letter of the limit. Testing should also include scenarios where the agent sends malformed or ambiguous requests, to confirm that the API rejects them safely. For a step-by-step guide on this process, see A practical checklist for building your first LLM-powered trading agent.

What risks remain even with these controls?

The safety model is designed to prevent theft, uncontrolled spending, and runaway positions. It is not designed to guarantee profits or prevent all losses. The agent can still make bad trades within its budget. If the market moves sharply, a stop loss may fill at a worse price than expected, especially in low-liquidity crypto markets. The owner can still lose the entire amount allocated to the agent. There is also model risk. The agent's strategy might be flawed, overfit to past data, or based on incorrect assumptions. The safety controls do not validate the strategy. They only enforce the boundaries within which it operates. Operational risk is another factor. If the owner misconfigures the budget cap, setting it too high relative to their total capital, the agent can lose more than the owner intended. Similarly, if the owner forgets their wallet credentials, Felix cannot recover the funds because the system is non-custodial. There is also system risk. API downtime, venue outages, or blockchain congestion can delay orders and prevent the kill switch from firing instantly. In extreme cases, a venue might fail or restrict withdrawals, which is outside Felix's control. The owner should only allocate capital they can afford to lose completely. For a discussion of common configuration errors, see Common mistakes running Claude trading agents with self custody. The controls reduce the blast radius, but the explosion can still happen inside the fence.