What an AI Trading Emergency Stop Actually Does

An AI trading emergency stop immediately revokes the calling agent key and prevents the agent from issuing new orders. It halts managed activity where possible, but it does not close existing positions or cancel token allowances without additional owner action. The stop is a control, not a guarantee that all exposure disappears instantly. Operators must still review any open trades and take manual steps if needed. For related context, see How to run an AI trading agent with real-money controls.

How Does an Emergency Stop Work?

When the stop command is issued, the system marks the agent’s key as revoked. Any subsequent request signed with that key is rejected, and the runtime will not forward new order messages to the market. This revocation is durable, meaning it persists across restarts and cannot be undone without a new owner‑signed key. However, orders already in the venue’s order book may remain active until they are filled, cancelled, or expire.

The revocation process also updates the runtime status endpoint, allowing monitoring tools to surface the stopped state instantly. Because the stop only affects the agent’s ability to act, other components such as market data feeds and account balance queries continue to operate normally, giving the owner full visibility into the current exposure.

What Does the Stop Not Do?

The emergency stop does not automatically liquidate open positions. Positions are held on the venue until the owner decides to close them, which requires a separate signed intent. Likewise, any token allowances granted to smart contracts remain in place until the owner revokes them. These limitations are intentional to avoid unintended market impact or loss of control over settlement processes.

Because the stop does not interfere with existing allowances, owners should maintain an up‑to‑date inventory of active permissions. Regular audits of token allowances help ensure that stale permissions do not become a source of risk after a stop has been triggered.

When Should You Trigger an Emergency Stop?

Typical triggers include repeated execution errors, unexpected loss beyond a predefined daily loss limit, or detection of data quality issues. Because a timeout does not prove an order failed, operators should verify the order state before assuming the stop has cleared exposure. The decision to stop should be based on clear policy signals rather than momentary latency spikes.

In practice, many teams pair the stop command with automated alerts that monitor error rates, loss thresholds, and data freshness flags. When an alert crosses a configured severity level, a scripted call can issue the stop, giving a rapid response while still allowing a human to confirm the broader context.

How Does the Stop Interact With Other Risk Controls?

Owner‑signed limits such as order size caps, daily notional caps, and expiry dates remain enforced after a stop. The stop simply removes the agent’s ability to act; it does not alter the underlying limits. This separation ensures that if the agent is later re‑authorized with a new key, the same risk policies continue to apply.

The architecture also records the revocation event in an immutable audit log. This log can be reconciled with the venue’s order book to confirm which orders were still pending at the moment of the stop, supporting post‑mortem analysis and compliance reporting. For related context, see How to Audit an AI Trading Agent’s Decisions.

What Operational Steps Follow a Stop?

• ·Confirm the revocation status of the agent key via the runtime status endpoint.
• ·Query open positions and outstanding orders directly from the venue using the normalized market interface.
• ·If needed, submit owner‑signed orders to close positions or cancel pending orders.
• ·Review token allowances and revoke any that are no longer required.
• ·Document the event and update any post‑mortem analysis.

An emergency stop is a control, not a cure. It halts new activity but leaves existing exposure for the owner to manage.