Onchain Agents vs Offchain Agents

Strip away the marketing and only two things separate the two categories.

• ▸Custody — does the agent hold keys it can sign with? An offchain agent borrows permission from a platform (an OAuth token, an API key) that a human granted and can revoke. An onchain agent holds, or is delegated, signing authority over a wallet. It doesn't ask a platform's permission to move value; it asks the chain.
• ▸Settlement — where does an action become final? Offchain, "done" means a row changed in someone's database, and that someone can change it back. Onchain, "done" means a transaction is confirmed on a public ledger — final, timestamped, and visible to anyone.

Everything people argue about — reversibility, trust, provability — falls out of those two. The reasoning loop (observe, decide, act) is the same on both sides. What changes is whether the "act" step writes to a private API or signs a transaction the whole world can audit. For how that signing authority is actually scoped, see how agents use wallets.

An offchain agent lives entirely in Web2. It triages an inbox, updates a CRM, writes code, books a meeting. It authenticates with OAuth scopes or API keys, and its permissions are whatever the host platform grants — no more, no less.

That model has real advantages, and it's a mistake to treat onchain as automatically "better":

• ▸Reversible. A wrong action is usually a support ticket, not a permanent loss. There's an undo button somewhere.
• ▸No gas, no settlement cost. Calls are effectively free, so high-frequency, low-stakes work is cheap.
• ▸Fast and mature. Web2 APIs are battle-tested and don't wait on block times.

The trade-off is that trust is contractual, not cryptographic. You trust the platform to honor the OAuth scope, keep logs honest, and not change the rules. That's fine for most automation. It stops being fine the moment an agent needs to hold a balance, get paid by a stranger, or prove to a third party what it did without that third party trusting the same platform.

An onchain agent adds the one capability no API key grants: it can sign transactions from a wallet it controls, often built on account abstraction like ERC-4337 so spend limits and permission scopes are enforced at the wallet level. Two things follow.

Economic agency. It can hold a balance, pay another service per request — for example over the x402 payment standard — get paid, and coordinate with agents it has never met, without a platform brokering the relationship. That's permissionless coordination, and it's what the offchain model structurally can't do.

A public record. Every action settles on a ledger anyone can read. That history is what makes a performance claim *checkable* instead of self-reported: an agent's wallet-verified track record can be reconstructed from chain data rather than taken on faith. It's worth being precise here — onchain activity proves *what happened*, not that an agent is safe, well-run, or worth funding. "verified onchain" is a different claim from "safe"; the Sato Score is explicitly a transparency and liveness signal, not a safety or returns grade. The cost of all this is bluntness: onchain execution is irreversible, and a public trail can also leak an agent's strategy to anyone watching.

In practice the question is rarely "onchain or offchain." Most real agents are hybrids: they reason over offchain data (market feeds, social signals, documents) and touch a chain only for the steps that genuinely need it. A research agent might gather and summarize entirely offchain, then accept USDC for the finished report onchain. A trading agent reasons against offchain price feeds and signs the swap onchain.

A quick way to decide which rail a given step belongs on:

1. Does value need to move, or be owned, or be proven to a stranger? → onchain.
2. Is it private, high-frequency, reversible, or purely informational? → offchain.
3. Does it touch funds but need a human in the loop? → offchain reasoning, onchain settlement behind an approval step and a spend cap.

The practical risk in hybrids is that they inherit *both* failure modes — Web2 API breakage and irreversible onchain execution — so guardrails matter more, not less. If you're assembling one, start from a framework that bundles wallet, permissions, and tools; browse the options in the directory.