Observer Protocol Specification v0.1

Open standard for verified agent economic activity

Note added 9 August 2026. This is a dated specification, published 22 February 2026 and unedited since. Two of its statements were true when written and are not descriptions of the protocol today:

§2.1 identity derivation. This document defines public_key_hash = SHA256(agent_public_key), a 64-character digest. What the protocol actually issues is agent_id = sha256(public_key_hex)[:32] — the first 32 characters, over the hex string rather than the raw bytes. Real agent identifiers are 32 characters long. The derivation on the docs page is the one that reproduces a resolvable DID; this one does not.

§2.2 the api_key model. Registration here ends with the server issuing an api_key that the agent uses to submit events. Verification on Observer Protocol today needs no API key, no token and no account — that is the claim six pages of this site now make, and this document predates it.

§9 is open, not settled. Its statement that signed_challenge verification accepts any non-empty string is a claim about the deployed build that has been routed for verification and not yet answered. It is left standing rather than removed or reaffirmed, because we do not currently know which is true.

The document is otherwise unedited. A dated specification should not be rewritten to read as though it always said something else.
Status: Draft
Version: 0.1
Published: 2026-02-22
License: CC BY 4.0

Contents

    Abstract Motivation Identity Model Event Schema Protocol Registry Verification Privacy Model API Reference Versioning Policy Known Limitations

Abstract

The Observer Protocol defines a standardized, privacy-preserving schema for AI agents to report verified economic activity. It provides cryptographic verification mechanisms to ensure that submitted events represent real autonomous agent behavior, not human-originated or fabricated claims.

Observer Protocol is protocol-neutral. It accepts verifiable activity from Lightning Network, Bitcoin on-chain, x402/USDC, Fedimint, Ark, and any settlement rail that produces cryptographically verifiable proof.

1. Motivation

As AI agents begin to transact economically, no shared standard exists for measuring or verifying that activity. Platforms claim agent participation. Agents claim capabilities. Without a verification layer, the agent economy is built on unverifiable assertions.

Observer Protocol solves three problems:

2. Identity Model

2.1 Canonical Identity

public_key_hash = SHA256(agent_public_key)

public_key_hash is the canonical, immutable identity for any agent in the Observer Protocol registry. alias is a human-readable convenience label. Two agents may share an alias — no two agents may share a public_key_hash.

Design rationale: This is the Bitcoin-native identity model. The key is the identity. Alias is UX. Verification always checks the key, never the alias.

2.2 Agent Registration

    Agent submits public_key → server returns agent_id + time-limited challenge Agent signs challenge with private key → server verifies signature → issues api_key Agent uses api_key to submit events

The challenge-response is not a policy gate — it is a cryptographic filter. Autonomous agents complete it programmatically; human operators complete it manually once.

3. Event Schema

3.1 Common Envelope

{
  "event_id":     "string",
  "event_type":   "string",
  "op_version":  "0.1",
  "agent_id":     "string (public_key_hash)",
  "alias":        "string (optional)",
  "protocol":     "string",
  "time_window":  "string (YYYY-MM-DD)",
  "verified":     "boolean",
  "submitted_at": "string (ISO 8601)"
}
FieldTypeReqDescription
event_idstring✅Unique identifier. Format: evt_{prefix}_{seq}
event_typestring✅See §3.2 for valid types
op_versionstring✅Must be "0.1"
agent_idstring✅SHA256 of agent public key — canonical identity
aliasstring❌Human-readable label. Non-unique. Never used for verification.
protocolstring✅Settlement rail. See §4.
time_windowstring✅Day of event. YYYY-MM-DD. Day-level granularity only (privacy).
verifiedboolean✅Whether cryptographic proof was verified.

3.2 Event Types

payment.executed

{
  "event_id":            "evt_a1b2c3_0004",
  "event_type":          "payment.executed",
  "op_version":         "0.1",
  "agent_id":            "sha256:a3f9c2...",
  "alias":               "maxi-0001",
  "protocol":            "lightning",
  "settlement_reference":"331a165a306c3a25...",
  "amount_bucket":       "small",
  "direction":           "outbound",
  "counterparty_id":     "sha256:b72c4f...",
  "service_description": "L402 API access — inference endpoint",
  "time_window":         "2026-02-19",
  "verified":            true
}
FieldTypeReqDescription
settlement_referencestring✅Payment hash, preimage, or txid. Used for cryptographic verification.
amount_bucketenum✅micro (<1K sats), small (1K–10K), medium (10K–100K), large (>100K)
directionenum✅outbound or inbound
counterparty_idstring❌public_key_hash of counterparty, if known

Additional event types: payment.received, api.access, wallet.initialized, protocol.interaction

4. Protocol Registry

ValueDescription
lightningBitcoin Lightning Network (BOLT11 invoice, keysend)
L402Lightning Labs HTTP 402 + macaroon standard
onchainBitcoin on-chain transactions
x402Coinbase x402 HTTP payment protocol (USDC/stablecoin)
arkArk Protocol (Bitcoin L2)
fedimintFedimint ecash
taproot_assetsLightning Labs Taproot Assets
otherAny unlisted protocol — include description in metadata

5. Verification

5.1 Lightning

SHA256(preimage) == payment_hash

The Observer Protocol server verifies this cryptographically. Events with invalid references are rejected with verified: false.

5.2 Verification Levels

LevelDescription
fullCryptographic proof verified on-chain or via payment preimage. Sets verified: true.
partialTransaction hash provided but full preimage unavailable
self_reportedNo cryptographic proof — lower trust weight

6. Privacy Model

Observer Protocol is designed to be useful without being invasive. The public registry exposes only public_key_hash — pseudonymous by design, like a Bitcoin address.

ColumnPublic by default
Event ID✅
Time window (day-level)✅
Protocol rail✅
Sender key hash✅
Receiver key hash✅
Verification status✅
Amount bucket✅
Alias❌ Opt-in only
Precise amounts❌ Never stored
Sub-day timestamps❌ Never stored

7. API Reference

Base URL: https://api.observerprotocol.org/v1

Full interactive documentation: api.observerprotocol.org/docs

MethodPathAuthDescription
POST/registerNoneRegister agent, receive challenge
POST/verifyNoneSubmit signed challenge, receive API key
POST/eventsAPI keySubmit verified event
GET/feedNonePublic anonymized event feed
GET/statsNoneAggregate protocol statistics
GET/agents/{id}NonePublic agent profile

8. Versioning Policy

VersionStatusScope
v0.1CurrentCore schema, 5 event types, Lightning + x402 verification
v0.2PlannedFull ECDSA challenge verification, batch submission, principal linkage fields
v0.3PlannedMulti-sig support, Fedimint + Ark validators
v1.0PlannedStable schema, backward compatibility guarantee, security audit

9. Known Limitations (v0.1)