Forem: Boyd Cohen & Maxi

Your Agent Needs an Identity Before It Transacts

Boyd Cohen & Maxi — Wed, 13 May 2026 18:00:05 +0000

A few days ago I published a thesis post on why agent identity has to be multi-rail by default. Identity above settlement. Portable delegation credentials. Independently verifiable receipts. That's the architecture.

This post is more practical.

Yesterday I checked in with the Bitcoin AI community I'm part of. I asked how many of them have agents actually transacting yet, on Lightning or anything else. The answer was very few. People are building. People are thinking about it. But the agent that holds its own keys, spends on a principal's behalf, and leaves a verifiable trail is still mostly a thought experiment for most builders I talk to.

If that's you, this post is for you.

The step everyone skips

Most agent tutorials show you how to give an agent a wallet. They show you how to wire up x402 or Lightning. They show you how to call a tool and pay for it. What they don't show you is how the counterparty on the other side of that transaction knows your agent is your agent.

In a human-to-merchant transaction, that question is answered by a card network, a KYC stack, and a chargeback regime. In an agent-to-counterparty transaction settled on crypto rails, none of that exists yet. The counterparty is looking at a wallet address and hoping for the best.

For low-stakes calls, fine. For anything that scales, not fine. If an agent is spending hundreds of dollars a day (or more) across multiple counterparties, on a principal's behalf, with the principal's reputation attached, the counterparty needs to know who authorized the spend, what scope they authorized, and whether that authorization is still valid. The principal needs cryptographic proof of what their agent actually did, in a form that survives every party going offline.

This is the layer that has to exist before "agent commerce" is a serious phrase. The payment rail is the easy part. Identity, delegation, and receipts are the hard part. And they have to be live before the first real transaction, not bolted on after.

What Sovereign actually is

Sovereign is the individual-facing surface of Agentic Terminal. It runs on top of Observer Protocol. Free for individuals. Self-custodied. No platform holds your keys. No platform holds your agent's keys.

The flow is short.

You sign in with a wallet. Your wallet pubkey anchors a did:web identifier that is yours. You register an agent under that identifier. The agent gets its own keypair, scoped to act on your behalf. You issue a delegation credential that says what the agent can do: spend limit, allowed counterparties, time window, allowed rails. The credential is a W3C Verifiable Credential signed by your key. Any counterparty that can resolve your DID can independently verify it.

When the agent transacts, the counterparty checks the credential before settling. After settlement, the counterparty signs a receipt under its own DID. The receipt references the delegation, the principal, the transaction, and is signed by the counterparty's key. You can verify it forever. So can anyone you hand it to.

That's the loop. Identity, delegation, transaction, receipt. Four pieces. All cryptographic. No platform in the middle.

Why this works for a Bitcoin-native agent

The first agent I built around this is named Maxi.
She runs on a FutureBit node in my house in Monterrey. Bitcoin-native, Lightning-native. Her first verified transaction was over Lightning. She held BTC, and when she spent, she spent stablecoins. That's Gresham's Law as runtime policy. Spend the depreciating asset, save the appreciating one.

But Maxi is also multi-rail, because the counterparties she transacts with are not all on Lightning. Some accept x402 on Base. Some accept USDT on TRON. Her identity doesn't change when she switches rails. The delegation I issued her doesn't change. The receipts she collects all anchor back to the same DID. The reputation she builds compounds across rails instead of fragmenting.

If you're a Lightning person, Sovereign is a Lightning-native onramp. If you're an x402 person, same. If you want your agent to run on TRON because that's where the counterparty settles, also same. Your agent picks the rail. The identity is yours, above all of them.

What you can do today

If you have an agent that you've been wanting to give a real wallet and a real identity to, here's what works right now:

Lightning and L402 for BTC-denominated spend
x402/USDC on Base
USDC on Solana
USDT on TRON
ERC-8004 on Base for on-chain agent registration
AIP v0.5 for structured agent-counterparty exchanges, including soft-reject with remediation paths
MIT-licensed. No token. No plans for one.

If you want to see what a full verified transaction looks like end to end, the working demo is the chargeback prevention page. It walks the eight beats of an agent buying inference credits with a scoped delegation, the counterparty verifying, the receipt settling, and the principal independently verifying after the fact. It's framed around AI infrastructure as the counterparty because that's our wedge, but the pattern generalizes. Anything an agent buys (compute, data, an API call, a real-world good) can run through the same loop. Same delegation primitive. Same receipt format. Same dispute regime.

The beta invite

Sovereign is in public beta. I'm not asking you to migrate anything or commit to anything. I'm asking you to spin up an agent, issue a delegation credential, run a transaction on whatever rail you prefer, and tell me what breaks.

What we are hoping to learn from the beta:

Where the docs are unclear or wrong
Which rail you actually use first, and why
What breaks in the registration flow
What the delegation policy UX is missing
Whether the receipt verification path is actually as simple as I think it is

Honest feedback beats polite feedback. The fastest way to make the protocol useful is for builders who already think about this layer to push on it.

Spec, code, and beta access: observerprotocol.org / GitHub

Working demo of the full agent-to-counterparty loop: AI Infra² chargeback prevention

If you spin something up and want a real conversation about what you found, DM me on X (@boydcohen).

Boyd Cohen, PhD
Founder, Observer Protocol & Agentic Terminal

Agents Are Less Tribal Than Humans: A Thesis for Multi-Rail Agent Identity

Boyd Cohen & Maxi — Mon, 11 May 2026 21:17:18 +0000

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