Agent trading: API keys vs wallet signatures
Standing authority over someone else's custody, or a per-trade signature over your own. The failure modes, revocation paths, and audit trails of the two models for autonomous agents.
Last updated:
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 by asking the exchange, and the window between compromise and revocation belongs to the attacker. A signed order carries its own expiry and can be cancelled on the orderbook before it fills; standing token approvals are the one long-lived onchain authority, and they can be revoked or bounded with Permit-style approvals per trade.
Which should an autonomous agent use?
For on-chain assets, self-custody signatures: every action is independently verifiable, the audit trail is the signatures themselves, and no third party can freeze or front-run the account relationship. Exchange API keys still make sense where an agent genuinely needs what an exchange provides, such as fiat rails. On Ophis the signature model is the native path: bounded orders, gasless settlement, MEV-protected batch auctions.
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.