Observer Protocol Specification v0.1

Open standard for verified agent economic activity

Status: Draft

Version: 0.1

Published: 2026-02-22

License: CC BY 4.0

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:

Identity without custodians

Activity without trust

Measurement without bias

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

public_key

agent_id

challenge

api_key

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)"
}

Field	Type	Req	Description
`event_id`	string	✅	Unique identifier. Format: `evt_{prefix}_{seq}`
`event_type`	string	✅	See §3.2 for valid types
`op_version`	string	✅	Must be `"0.1"`
`agent_id`	string	✅	SHA256 of agent public key — canonical identity
`alias`	string	❌	Human-readable label. Non-unique. Never used for verification.
`protocol`	string	✅	Settlement rail. See §4.
`time_window`	string	✅	Day of event. `YYYY-MM-DD`. Day-level granularity only (privacy).
`verified`	boolean	✅	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
}

Field	Type	Req	Description
`settlement_reference`	string	✅	Payment hash, preimage, or txid. Used for cryptographic verification.
`amount_bucket`	enum	✅	`micro` (<1K sats), `small` (1K–10K), `medium` (10K–100K), `large` (>100K)
`direction`	enum	✅	`outbound` or `inbound`
`counterparty_id`	string	❌	public_key_hash of counterparty, if known

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

4. Protocol Registry

Value	Description
`lightning`	Bitcoin Lightning Network (BOLT11 invoice, keysend)
`L402`	Lightning Labs HTTP 402 + macaroon standard
`onchain`	Bitcoin on-chain transactions
`x402`	Coinbase x402 HTTP payment protocol (USDC/stablecoin)
`ark`	Ark Protocol (Bitcoin L2)
`fedimint`	Fedimint ecash
`taproot_assets`	Lightning Labs Taproot Assets
`other`	Any 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

Level	Description
`full`	Cryptographic proof verified on-chain or via payment preimage. Sets `verified: true`.
`partial`	Transaction hash provided but full preimage unavailable
`self_reported`	No 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.

Column	Public 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

Method	Path	Auth	Description
POST	`/register`	None	Register agent, receive challenge
POST	`/verify`	None	Submit signed challenge, receive API key
POST	`/events`	API key	Submit verified event
GET	`/feed`	None	Public anonymized event feed
GET	`/stats`	None	Aggregate protocol statistics
GET	`/agents/{id}`	None	Public agent profile

8. Versioning Policy

Version	Status	Scope
v0.1	Current	Core schema, 5 event types, Lightning + x402 verification
v0.2	Planned	Full ECDSA challenge verification, batch submission, principal linkage fields
v0.3	Planned	Multi-sig support, Fedimint + Ark validators
v1.0	Planned	Stable schema, backward compatibility guarantee, security audit

9. Known Limitations (v0.1)

signed_challenge