Your Agent Needs an Identity Before It Transacts

#agents #ai #bitcoin #blockchain

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: