I've spent the last four months building Observer Protocol, an open identity layer for AI agents. The deeper I get, the more convinced I become that most of the agent identity infrastructure being built right now is making an assumption that will age badly: that agents will stay on one rail.
They won't. Here's why, and what it means for how we design KYA (Know Your Agent) infrastructure.
Humans are tribal. Agents are pragmatic.
If you're reading this on DEV.to, you probably have opinions about chains. Maybe you're an Ethereum person. Maybe you are a Bitcoin maxi. Maybe you're deep in Solana. That's fine. Humans are tribal about money. We always have been.
Agents don't care.
An agent's job is to complete a task on its principal's behalf. If a counterparty accepts USDT on TRON, the agent routes to TRON. If another accepts USDC on Base via x402, the agent routes to Base. If a third accepts Lightning, the agent opens a channel. The agent optimizes for task completion with the lowest friction and cost. It has no ideology.
The first AI agent we built Observer Protocol around is named Maxi. She was born on a Bitcoin node in Mexico and was one of the first agents in the world with her own L402 and LND endpoints. She's a Bitcoin-native agent. And yet she's multi-rail. When she needs to buy GPU inference credits, the rational move is to spend stablecoins and hold Bitcoin. Gresham's Law as runtime policy: bad money drives out good. Spend the depreciating asset, save the appreciating one.
Most humans will mirror this pragmatism for spending even when they stay tribal about saving. The spending behavior is what matters for agent infrastructure, because that's where transactions happen.
The problem with single-rail identity
Here's where this gets concrete. Right now, several teams are building agent identity and payment infrastructure. Most of it is anchored to one ecosystem:
- x402 (Coinbase) is clean, well-designed, and lives on Base. Agent identity built around x402 doesn't travel to Lightning or TRON.
- Lightning/L402 identity is powerful for the Lightning ecosystem but invisible to an x402 counterparty.
- Proprietary KYA stacks (closed-source, vendor-specific) create lock-in by design. Your agent's reputation and credentials exist only inside one vendor's system.
None of these are wrong on their own terms. x402 is a good standard. Lightning is a good rail. But if you build your agent's identity around any single one of them, you've made a bet that your agent will only ever transact on that rail.
I wouldn't take that bet to Polymarket. Not because any individual rail will fail, but because agent commerce is structurally multi-rail. Counterparties accept different things. An agent that can only prove its identity on Base can't transact with a GPU provider that settles on TRON, even if the agent has USDT in a wallet and the provider would happily take it. The identity layer becomes the bottleneck, not the payment rail.
What the smart money is converging on
a16z published a piece earlier this year co-authored by Christian Catalini and others. The core argument: agents need portable identity, blockchains are the natural coordination layer, payment rails are gravitating to crypto, verification is the new scarcity, and user control must be preserved.
But the paper I want to anchor on is more foundational. Catalini, Xiang Hui, and Jane Wu published "Some Simple Economics of AGI" in February. The thesis: for three hundred thousand years, human cognition was the primary engine of progress. AI is now driving the marginal cost of measurable execution toward zero. The binding constraint on growth is no longer intelligence. It is human verification bandwidth: the scarce capacity to validate outcomes, audit behavior, and underwrite meaning when execution is abundant.
The implication is what Catalini calls the "Provenance Premium." Any credible signal that lowers the cost of verification commands a premium. Cryptographic provenance on rails that also settle payments becomes the lowest-friction substrate for that signal.
That insight is why we built what we built.
The design consequences
If you accept that agents will be multi-rail by default, three architectural consequences follow:
1. Identity must live above settlement, not inside it.
The agent's DID (decentralized identifier) can't be chain-specific. It has to resolve across rails. We use W3C DID (specifically did:web with Ed25519 keys) because the W3C DID spec is rail-agnostic by design. The same DID resolves whether the agent is transacting via x402, Lightning, or TRON. The identity layer sits above the settlement layer, not inside it.
This is a deliberate architectural choice. Most agent identity systems today couple identity to a specific payment mechanism. We decouple them. The DID is the anchor. The payment rail is a parameter.
2. Delegation credentials must be portable and scoped.
When a human authorizes an agent to act on their behalf, that authorization needs to travel with the agent across counterparties and rails. We implement this as W3C Verifiable Credentials (VCs) with Ed25519Signature2020. A delegation credential says: "This agent may spend up to $X, on these services, until this time, on behalf of this principal." The credential is cryptographically signed by the principal's key and independently verifiable by any counterparty that can resolve the principal's DID.
The credential doesn't care what rail the transaction settles on. It cares about scope, time, amount, and principal authorization. Those constraints are rail-independent.
3. Receipts must be independently verifiable, by anyone, forever.
After a transaction settles, the counterparty signs a receipt under their own DID. The receipt carries the transaction details, a reference to the delegation credential, the authorization level, the principal DID, and the counterparty's signature. Any third party with the receipt JSON and the counterparty's published public key (via standard did:web resolution) can verify the receipt without any runtime dependency on our backend or the counterparty's backend.
The receipt survives every party going offline. That's the dispute resolution regime for crypto-native agent commerce. No card network, no chargeback database, no intermediary. The cryptographic attestation is the regime.
What we've shipped
Observer Protocol is the open protocol layer: credential schemas, verification primitives, an independently verifiable receipt format, and AIP (Agent Interaction Protocol), which standardizes how agents and counterparties exchange structured claims at runtime. AIP introduces the concept of a soft-reject: a structured, recoverable response with a remediation path the agent can act on, rather than a terminal error.
Agentic Terminal is the application layer. The individual-facing surface is Sovereign: self-custodied identity, agent registration, delegation policy configuration. Free for individuals. Designed to feel like Phoenix or Strike. Cypherpunk values, mainstream UX. We also have a full enterprise version in beta that meets the IAM (Identity Access Management) requirements for companies (especially crypto-active and adjacent ones) to manage fleets of agents.
What's live today:
- x402/USDC on Base and USDC on Solana: deployed, verifiable
- Lightning/L402 and BTC: deployed, verifiable (Maxi's native rail)
- TRON/USDT: deployed, verifiable
- ERC-8004 on Base: on-chain agent registration for independently verifiable identity
- AIP v0.5: soft-reject with remediation paths, delegation credential exchange
- MIT-licensed. No token. No plans for one.
Four settlement rails. One portable identity. One receipt format. That's the architecture.
What's not solved yet
Honest accounting, because I think this matters:
Enterprise compliance. SOC2 Type 1 is on the roadmap, not in hand. Enterprise customers will ask for it. We are engaging with potential enterprise design partners who can validate the architecture before we invest in the compliance surface.
Adoption. The protocol is live. The SDK works. The specs are published. What we don't have yet is a critical mass of counterparties running verification calls in production. That's the chicken-and-egg of any new standard, and we're solving it the way standards have always been solved: by going to the companies with the most acute version of the problem (AI infrastructure) and co-building with them.
Multi-sig and institutional delegation. The current delegation model is single-principal. Institutional use cases (treasury management, fleet governance, multi-party authorization) require a richer delegation tree. The spec supports it; the implementation is Phase 2.
Revocation latency. Credential revocation is implemented but the propagation model isn't instant. A revoked credential has a window where a fast-moving agent could still present it to an uninformed counterparty. We're working on this. It's a known hard problem in any VC system and we don't pretend to have fully solved it.
Why this matters now
AI infrastructure companies are the right first wedge. They already transact with agents. They already settle on crypto-native rails or are about to. They're technically sophisticated enough to integrate a verification layer in days, not quarters. And they have a chargeback liability problem that nobody is talking about yet: an agent purchases inference credits hundreds of times per day on a principal's behalf, the principal disputes the charge, and the AI infra company has no cryptographic proof the principal authorized it.
In traditional finance, cryptographic attestations alone can't defeat a chargeback because the card network's rules govern. But in crypto-native settlement, where the transaction settles on Lightning or USDT on TRON with no card network in between, the cryptographic attestation is the dispute resolution regime. The signed receipt the counterparty holds, signed by the principal's key authorizing that exact transaction, is the definitive answer to "did the human authorize this?"
The receipt is the regime.
Where to go from here
Observer Protocol is MIT-licensed and always will be. The schemas, verification primitives, AIP standards, receipt format, and SDK are all genuinely open. Any human, agent, AI infrastructure company, chain, or rail can implement OP independently of us.
We're actively looking for design partners: AI infrastructure companies, agent-native platforms, and chain ecosystems that want to co-shape the standard. You build on the protocol, you get a permanent seat at the table. We do the integration work.
Spec and code: observerprotocol.org / GitHub
Full architectural writeup with a working demo of the agent-to-counterparty flow: AI Infra²
If you're building agent infrastructure and any of this rhymes with where you're heading, DM me on X (@boydcohen).
Boyd Cohen, PhD
Founder, Observer Protocol & Agentic Terminal
Top comments (0)