Agents

An agent is any off‑chain program — typically an LLM‑driven autonomous loop — that holds an Ethereum key and transacts against the markets contracts. The contract surface has no special notion of "agent"; agents are just EOAs the host has chosen to trust.

This page is about patterns, not APIs.

What an agent typically does

Hosts integrate agents at three points in the market lifecycle:

Creation. The agent proposes markets based on feeds, internal signals, or user prompts. The preferred future path is hosted draft submission through client.drafts.submit(...), not hand-assembling factory calls.
Resolution. For AiOracle markets, the agent is the sole admin. It fetches evidence from configured sources, picks the winning option, and submits the resolution. See oracles.
Housekeeping. Agents routinely poll for markets that have passed their challenge window and call finalizeMarket() so participants don't have to. Because finalization is permissionless, any agent can do this for any market.

Key custody

An agent is an EOA. Where its private key lives dictates its trust model:

Local HSM or KMS — Standard for production. AWS KMS + viem's KMS signer is a common stack.
TEE / confidential VM — Strongest isolation; the key never leaves the enclave. Common in oracle networks.
Multi‑sig or account abstraction — Useful when multiple agents (or humans) must co‑sign before a transaction goes out. Wrap the agent behind a 1‑of‑N Safe and add humans as escape hatch.

Whatever you pick, the agent's address is on‑chain and permanent. Rotating keys means deploying a new market with a new admin set — existing markets cannot swap admins.

Limiting agent authority

Markets are contract‑scoped. An agent that is admin on market A has no power over market B. Exploit blast radius is bounded to the markets where you granted authority:

Scope agents narrowly. One agent per category of market, or per customer, rather than a single god‑agent with blanket authority.
In MultiAdmin markets, include human co‑signers alongside the agent. The agent proposes, humans confirm.
Audit agent transactions via Base's transaction APIs — every call emits an event, and most hosts stream these into their monitoring stack.

Liveness

Agents that don't run don't resolve markets. If your agent is the sole resolver for a market, its failure is a market failure. Mitigations:

Run two independent agent processes with shared idempotency — whichever lands first wins the resolution transaction.
For MultiAdmin, mix agents with humans so market liveness doesn't depend on any single service.
Monitor the agent's balance, uptime, and transaction success rate.

Payment

Agents need ETH on Base for gas. Fund the agent's address ahead of close times and alert on low balance — a resolver that's out of gas during the resolution window is functionally the same as one that crashed.

Anti‑patterns

Single agent as sole admin on high‑value markets. Mix in a human or a second agent.
Agent keys on laptops. Use a KMS, not a .env file.
Agents that both buy in and resolve. This is the textbook definition of market manipulation. Don't do it. The contract does not prevent this; your policies must.

SDK direction

Agent-facing integrations should end up using the same surfaces as apps:

client.drafts.* for hosted creation
client.markets.* for direct lifecycle actions
future advanced signed-hosted flows only where the product really needs them

That keeps agent integrations aligned with the normal product model instead of forcing a separate "agent-only" SDK story.