Why OC Agent

The authority primitive, and why it belongs in the OrangeCheck stack.

The gap in the stack

The OrangeCheck family is a set of composable primitives, each binding a verb to a Bitcoin address:

Primitive	Verb	What it binds
OrangeCheck	identity	"This address has N sats bonded for M days."
OC Lock	confidentiality	"This payload is readable only by the device registered under this address."
OC Vote	legitimacy	"This vote was cast by an address carrying a bond, on a poll with transparent rules."
OC Stamp	provenance	"This address signed this content at this time, anchored to Bitcoin block N."
OC Agent	authority	"This address authorized this other address to take actions matching this scope set until this time."

The first four all describe what the principal did themselves. OC Agent is the first primitive that concerns what another party is allowed to do on the principal's behalf.

You can approximate agent authority on top of the other four, but none make it first-class:

• OC Stamp + scope text — no grammar for the scope, no revocation feed, no binding between agent key and stamped content.
• OC Lock-wrapped delegation instructions — confidentiality ≠ authority. Readable by the intended agent, but nothing to verify after the fact.
• OrangeCheck attestation of a delegation — attestations describe the signer, not a grant to another party.

OC Agent is the minimal additional protocol that fills the gap without forking or replacing any sibling.

Why not existing capability systems?

OAuth / OIDC

OAuth bearer tokens work. They are the wrong shape here:

• Identity is whatever the issuer says it is. No portable key.
• Scope strings are issuer-specific; readers need to know the issuer's conventions.
• Revocation is an issuer call; offline verification is impossible.
• No stake model. No reputational cost behind a bearer token.

OAuth fits "humans delegating to third-party services under an issuer's account system." OC Agent fits "self-sovereign Bitcoin identity delegating to autonomous processes."

UCAN / Biscuit / Macaroons

These are closer — capability tokens with programmatic scope, chained delegation, and offline verification. What they lack for this use case:

• Issuer is typically an Ed25519 / server key, not a Bitcoin address.
• No inherent stake signal.
• No native anchoring layer for priority ordering against revocations.
• No canonical transport that composes with the pre-existing Bitcoin identity ecosystem.

UCAN is excellent for what it targets. OC Agent targets Bitcoin-identity-bound authority with reputational stake and OpenTimestamps-anchored priority.

PGP-signed policy files

People still do this. The problems:

• PGP identity is a keyserver, which has failed every security review for twenty years.
• No revocation feed anyone queries.
• No scope grammar; the text is prose.
• No way to cite the action that exercised the policy.

Why scope strings

We considered three shapes:

1. Free-form string. Rejected: unverifiable.
2. Embedded DSL. Rejected: verifier complexity balloons; worst-case sub-scope decidability becomes undecidable for a realistic feature set.
3. Declarative scope strings with a constraint registry. Shipped. Simple enough to parse in a hundred lines, powerful enough to express "send at most 1000 sats via Lightning to this node, ten times, until Friday," and structurally limited so sub-scope containment is always decidable.

Scope strings are the protocol's contract with both humans and verifiers. A user reading ln:send(max_sats<=1000,node=03abc…) in a wallet prompt understands it immediately. A verifier applies a fixed algorithm and gets a deterministic answer.

Why bond the grant, not the action

Per-action bond declarations would be more granular but make verification worse:

• Each verification becomes an N-way attestation re-resolution.
• Principal's total exposure is decoupled from the riskiest actions.
• The OrangeCheck attestation is a slowly-changing signal. Sats bonded for 180 days doesn't want to be debited per-action.

Binding the bond to the delegation is the right granularity: "I put N sats of reputation on the line to say this agent will behave within scope until expiry." The bond commits to the grant, not to any individual act.

Why OTS for priority

The question "does this revocation predate this action" is the one OC Agent cannot answer purely from signatures. Both sides can claim any signed_at.

Options considered:

1. Trust declared timestamps. Forgeable.
2. Require every action to cite a recent Bitcoin block hash. Proposed in draft. Works but forces every agent to run a header source and produces brittle envelopes (reorgs change the cited hash).
3. Compose with OpenTimestamps. Shipped. Free, permissionless, already the anchor layer for OC Stamp. Reusing it means calendars, proof parsing, and header-bundle tooling are already in the stack.

Anchoring is optional. For low-stakes delegations, the declared signed_at is fine. For high-stakes ones, anchor both sides and let the verifier compare block heights.

Why extend OC Stamp

The first design had three separate envelope structures. We noticed:

• Agent-actions are structurally identical to stamps — canonical message, BIP-322 on id, optional OTS, optional content.ref.
• A second "stamp-ish" envelope would duplicate canonicalization, OTS integration, and Nostr discovery.
• An OC Stamp verifier looking at an agent-action should get something useful out of it, not reject-or-ignore.

Agent-actions are stamps, with two extension fields (delegation_id, scope_exercised) and a different preamble. Stamp verifiers tolerantly verify the core attestation; OC Agent verifiers additionally check the authority chain. One @orangecheck/stamp-core for the crypto, @orangecheck/agent-core on top.

Why Nostr kinds 30083 and 30085

The OrangeCheck family has reserved 30078–30099. Existing:

• 30078 — OrangeCheck / OC Lock device record
• 30080–30082 — OC Vote poll / ballot / tally
• 30083 — OC Agent delegation
• 30084 — OC Stamp envelope (shared transport for agent-actions, disambiguated by envelope kind)
• 30085 — OC Agent revocation

Using 30084 for agent-action transport is a consequence of "agent-action is a stamp."

Why "every AI agent should have a Bitcoin address"

A year from now every meaningful software agent will be doing things that have economic and social consequences: writing code, signing off on content, sending payments, voting in DAOs, representing humans in negotiations. The authority layer for that work will either be:

1. A patchwork of provider-specific OAuth tokens, each with its own scope conventions, revocation story, and trust boundary. Verification requires trusting the issuer.
2. A portable, provable, bonded grant from a Bitcoin address. Verification is local.

The first is what exists today by default. The second is what OC Agent proposes as a default that isn't tied to any platform, vendor, or account.

Binding agent authority to a Bitcoin address inherits, for free, everything the rest of the OrangeCheck stack gives us:

• A well-understood identity substrate (BIP-322).
• A staking signal with real economic cost (OrangeCheck).
• A confidentiality layer if the authority itself is sensitive (OC Lock).
• A provenance layer for each action (OC Stamp).
• A governance primitive if principal-group decisions gate the grant (OC Vote).

Agents that speak this dialect inherit the credibility of their principals' bonds, retain audit trails that survive any single provider's shutdown, and can be verified offline by anyone who understands the stack.

That is a substantially stronger posture than "whoever holds this API key."

What this is not

• Not a replacement for OAuth when the principal is a webapp user and the authorizing party is a custodian.
• Not a general-purpose capability system for distributed compute. UCAN is better for that.
• Not a legal document. A compliant envelope is not self-executing; enforcement of breach is a social or legal matter. The bond is a reputational signal, not an escrow contract.

OC Agent is the authority envelope for cases where the principal is self-sovereign, the agent is an autonomous process that needs verifiable authority, verifiers want to audit without trusting any specific server, and a reputational stake is useful as a credibility signal.

That is a real and growing domain. OC Agent makes it a first-class artifact.