Agent trading: API keys vs wallet signatures

The short version: an exchange API key is standing authority over an account the exchange custodies; it fails at account scale and revokes only as fast as the exchange reacts. A wallet signature is a per-trade, bounded capability over self-custodied funds that expires by construction, but the wallet's own exposure is whatever its key can sign: the hard ceiling is the funding made available to the key, constraints and turnover caps pace how fast a compromise reaches it, and stopping it means revoking a session key or, for a raw EOA, racing to evacuate. Autonomous agents trading on-chain assets are better served by signatures, with signer-enforced policy on top in either model.

How does an exchange API key work for a trading bot?

A CEX API key is standing authority over an account the exchange custodies. The bot authenticates with the key and the exchange executes on its behalf, within the key's scopes (read, trade, sometimes withdraw). The funds sit with the exchange, and the key works until someone notices and revokes it.

How do wallet signatures work for an agent?

The agent holds its own key and signs each order individually as an EIP-712 message: sell token, buy token, amount, a hard limit price, an expiry, and the receiver. Funds stay in the agent's wallet until settlement executes on-chain. There is no standing session: every trade is its own explicitly signed decision.

Which fails worse when the agent is compromised?

They fail differently. A stolen trade-scoped API key exposes whatever the scope allows against the whole account balance until revoked, and a withdraw-scoped key is game over. On the wallet side the scale depends on what the key can sign: a raw EOA key exposes everything the wallet holds, transfers and approvals included, not just orders. Constraining the key helps only as far as the constraints compose: a smart account that can only produce bounded orders still allows many individually valid orders in a row, and a daily turnover or rate cap only paces the damage per window, since a key that stays compromised gets a fresh window when the cap resets. The hard ceiling is the cumulative funding made available to the key before the compromise is stopped; the pacing layers only govern how fast it is reached. How you stop it depends on the wallet: a smart-account session key can be revoked outright, while a raw EOA key cannot, leaving a race to evacuate funds, cancel open orders, and revoke approvals. That layering matters in both models.

How does revocation compare?

An API key is revoked through the exchange. Signed orders have an expiry, but orderbook cancellation can race an in-flight fill; finalized onchain invalidation provides a stronger boundary. Standing token approvals and any wallet-module/session permissions must be reviewed separately.

Which should an autonomous agent use?

Choose based on the assets and permissions needed. Wallet signatures give direct authorization over onchain actions, but token issuers can still impose freezing or transfer restrictions and contracts retain their own risks. Exchange APIs may suit fiat rails or exchange-only markets. On Ophis, standard signed ERC-20 orders provide bounded execution with solver-paid settlement gas; approvals and other wallet transactions still cost gas.

Go deeper

What the signature actually contains: what is EIP-712. How to structure the wallet side: how an AI agent should hold custody. The end-to-end agent flow, including the keyless MCP server, is at docs.ophis.fi/ai-agents.