Where dollar-based order sizing can mislead a trading agent

Felix lets an agent specify orders in plain US dollars, and the API translates that amount into each venue's contract math. This abstraction removes the need for the agent to know lot sizes, tick values, or margin formulas, but it also hides the exact mechanics of how the dollar value maps to real exposure. Developers who trust the abstraction without hard external limits can accidentally allow oversized positions, leverage amplification, or rounding mismatches that drain a budget faster than the agent intended.

What does dollar-based order sizing actually abstract away?

When an agent sends an order through Felix, it does not need to calculate contracts, shares, or lot sizes. The API takes the dollar amount, fetches the current market data from the venue, and computes the equivalent number of units given the current price, the venue's minimum order size, and its tick increments. This means the same agent code can buy $500 of a stock through a stock broker, $500 of a crypto spot pair through an exchange, and $500 of notional exposure through a perps venue without changing its internal logic. The agent reasons about capital allocation in the same currency it uses for its budget, which reduces cognitive load and lowers the chance of unit conversion errors.

Underneath the abstraction, however, each venue uses different rules. One venue might allow fractional shares, another might require whole-share lots, and a perps venue might use a contract size that fixes the notional value per unit. The API normalizes these into a single number, but the normalization is a bidirectional mapping. The agent sees $500, but the venue sees a specific number of units at a specific price, and the two are only roughly equivalent once the order executes. The developer must understand that the abstraction is a convenience layer, not a guarantee of perfect translation, and that convenience can mask details that matter for risk.

Where can rounding and notional mismatch leak money?

The first leak is rounding. Suppose an agent wants to buy $100 of an asset trading at $33. If the venue requires whole-share lots, the API can only buy two shares for $66 or three shares for $99. It cannot buy the exact $100. Depending on the rounding policy, the agent might end up with $99 of exposure or the order might be rejected, leaving the agent idle while the market moves. In fast markets, the price can shift between the time the agent decides on $100 and the time the order reaches the venue, so the dollar value at execution is never guaranteed. Even in crypto spot markets where fractional units are common, the venue might still enforce a minimum decimal precision that chops off a small tail of the intended amount.

The second leak is minimum notional values. A developer might write an agent that rebalances a portfolio in $25 increments. If one venue has a $10 minimum order but another has a $50 minimum, the same logic will behave differently across markets. The agent might think it has achieved a target allocation when the order was silently rejected or rounded down to zero. Over time, these micro-failures compound into drift between the agent's intended portfolio and the actual holdings. An agent that does not check fill reports against its intended dollar targets will accumulate tracking error that grows with every rebalance cycle.

The third leak is slippage on large orders. A $10,000 order in a thin market may fill at an average price far from the quote the agent saw. Because the agent specified dollars, it has no direct intuition about depth of book. It does not know whether $10,000 consumes one price level or ten. The executed notional can be higher than intended, or the average fill price can push the effective dollar exposure outside the budget. The agent may also pay more in fees than expected if the larger size pushes it into a higher fee tier. These effects are not bugs in the API; they are normal market mechanics that the dollar abstraction simply does not expose.

• ·Rounding to lot or tick size can reduce or increase the intended notional by a few percent per trade.
• ·Minimum order thresholds can cause silent rejections that the agent must detect and handle.
• ·Slippage in low-liquidity markets can make the effective dollar cost diverge from the requested size.

How does leverage turn a dollar size into a larger position?

On spot markets, $500 of capital generally buys $500 of assets. On perpetual futures and some margin venues, the mapping is not one-to-one. The agent might allocate $500 from its budget, but the venue can apply leverage to that margin, creating a notional position of $2,500 or $5,000. The agent specified a dollar amount, but the dollar amount referred to the margin reserved, not the total economic exposure. If the developer assumes the agent is only risking $500, the actual liquidation or funding risk can be many multiples higher. The agent does not see the leverage multiplier in its order request, so it cannot autonomously correct for it unless the developer explicitly builds that check.

Felix exposes the order in plain dollars, but the developer must still configure the venue's margin settings separately. An agent that sends a $1,000 order to a perps venue with 20x leverage is controlling $20,000 of notional value. The agent itself may not be aware of the leverage multiplier unless the developer explicitly fetches account state and enforces a cap. Hard limits for perpetual futures should be set at the API level so the agent cannot accidentally increase leverage by changing a parameter it does not fully understand. The API can reject an order that would exceed the pre-configured notional cap even if the dollar amount itself looks small.

The danger is compounded when the agent is doing portfolio math in dollars. It might calculate that it wants 10% of a $10,000 account in a given asset, send $1,000, and end up with $10,000 of notional exposure because of leverage. The portfolio math breaks because the abstraction layer translates capital into exposure differently across market types. A developer who runs the same agent across stocks, crypto, and perps without adjusting for this translation will see wildly different risk profiles even when the agent thinks it is making equal-sized bets. The dollar unit is the same, but the economic meaning is not.

Why should developers set hard limits outside the agent?

A trading agent should not be trusted with unlimited discretion over how many dollars map to how many contracts. The agent reasons in natural language or in algorithmic steps, but it does not have perfect information about venue rules, margin tiers, or liquidity. Hard limits belong in infrastructure that the agent cannot modify. Felix provides scoped keys, budget caps, position limits, and a kill switch that operates outside the agent's reasoning loop. These controls are not guardrails inside the agent's prompt; they are enforced by the API and the wallet architecture, which means the agent cannot talk its way around them.

Developers should treat the agent as a strategist and the API as the enforcer. The agent proposes a dollar size based on its model or signal. The API checks that size against a pre-approved budget cap, a per-market position limit, and a maximum leverage tier. If the proposal violates any of these, the API rejects it before it reaches the venue. Scoped API keys let you define these boundaries at the key level, so even a compromised or misaligned agent cannot spend beyond its cage. The key is bound to a specific wallet, a specific set of markets, and a specific maximum outflow, which limits the blast radius of any mistake.

You should also define an exit plan before the agent starts. A panic switch that flattens positions and revokes the key is not a failure mode; it is part of the normal safety architecture. Running an agent safely means assuming the agent will eventually request a bad trade, and building the system so that the bad trade never reaches the market. The kill switch should be wired to a separate channel that the agent does not control, such as a manual admin panel or an automated monitoring job that watches for drawdown thresholds. When the switch triggers, the API flattens all positions and invalidates the key, cutting the agent off from further activity regardless of what it intended to do next.

How can developers test sizing logic without risking capital?

Paper trading exists so you can observe how dollar-based orders translate into venue-specific contracts without committing real money. Use paper trading to test the rounding behavior for each market you intend to trade. Submit orders at the minimum dollar sizes your agent uses, at the maximum sizes, and at odd values that are likely to trigger rounding. Inspect the resulting simulated positions to see whether the agent's intended allocation matches the actual allocation. Paper environments typically use the same matching engine rules as live markets, so the translation from dollars to contracts is representative, though latency and liquidity can differ.

You can also test leverage assumptions. Configure the paper account with the same margin settings you plan to use live, and verify that a $500 order produces the expected notional exposure. If the notional is ten times larger than expected, you have found a configuration error before it costs anything. Run the agent through a full rebalance cycle in paper mode and compare its internal portfolio state against the actual paper positions. Any drift you see there will appear in live trading, so fix the logic or the limits while the stakes are zero.

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

# Illustrative MCP tool call
# Replace YOUR_KEY with a scoped paper-trading key
{
  "tool": "felix_create_order",
  "arguments": {
    "key": "YOUR_KEY",
    "market": "BTC_USD_PERP",
    "side": "buy",
    "dollar_size": 500,
    "type": "market"
  }
}

The response will include the executed notional, the number of contracts or shares filled, the average fill price, and the fees. Compare these fields against the agent's internal model after every paper trade. If the agent thinks it bought $500 but the response shows $475 or $525, you have a rounding or slippage mismatch to fix before going live. You should also verify that the key used in testing is scoped to paper trading only, so that a copy-paste error cannot accidentally send a live order during debugging.

What should you verify before authorizing live trading?

Before you move from paper to live, run through a checklist that focuses on the boundary between dollars and contracts. Confirm the minimum and maximum order sizes for each market. Confirm the margin mode and leverage settings for every perps or options venue. Confirm that the kill switch is wired to a separate channel the agent cannot access. And confirm that the agent's logic handles rejected or partially filled orders gracefully, rather than assuming that a $100 request always produces exactly $100 of exposure. The transition to live trading is not a deployment milestone; it is a risk configuration change that deserves its own review.

1. 01Check that budget caps are set lower than the total wallet balance, leaving a buffer for fees and slippage.
2. 02Verify that position limits are configured per market, not just globally, so the agent cannot concentrate risk.
3. 03Test the kill switch by triggering it during a paper session and confirming that all positions flatten and the key revokes.
4. 04Review the agent's prompt or code to ensure it expects and handles rounding errors, rather than hardcoding exact dollar outcomes.
5. 05Audit the first ten live trades manually against the agent's intent to catch any mismatch between the abstraction and the venue.

Trading can lose money, including everything. The dollar-based abstraction is a powerful tool for building agentic systems, but it is only safe when the developer understands what it hides. Build your controls first, test them in paper, and assume the agent will eventually make a request that would be dangerous if allowed through. The API is there to stop that request, not just to forward it.