Read from /observer/stats on 9 August 2026 and typed here. These are counts of rows, not of verifications. The API's own field notes say so: total_transactions is “an UNFILTERED count … NOT a count of verified or attested transactions”, and the field this page previously called “VACs Issued” has been removed upstream because it “counted neither”.

121
Registered Agents
Entries in this OP instance. A count of registrations, not of agents that exist — an agent exists because someone controls a key, not because we recorded it.
56
Recorded Events
Unfiltered. 1 is settlement-attested; the rest carry no proof.
2
VAC Credentials Unexpired
Expiry is the only property this deployment can establish
7
Active Rails
Lightning · x402 · MPP · more

Payments that were requested, were fundable, and did not happen.

A registry of successful payments shows that a system can move money. It says nothing about whether the system could have stopped. This section leads because the refusal is the product. It has one entry, and it is titled so that one entry does not read as a truncated list.

Entry 001 · Bitcoin mainnet · Lightning27 July 2026
requested  · 200,000 sat
ceiling    · 100,000 sat per transaction
balance    · 481,500 sat, and a live ACINQ channel
outcome    · REFUSED — ceiling
control    · 10 sat, same destination, same channel, same RPC method → SETTLED
The payment could have succeeded. More than four times the balance required, a live channel, a working node. The mandate stopped it, and the 10-sat control settling over the same path is what distinguishes a refusal from a failure.
Scope. The mandate issuer was a demonstration did:key, not the production issuer. · One node, ours, so this is enforcement at a node rather than closure of the network. · The macaroon caveat is a sender-side trigger in the payer's own credential and is not visible to the payee. · The signed record itself is not yet verifiable by you: refusalPayload is not exported from the published engine. What that means →

Credentials published here, and whether they verify.

Five credential artifacts are served under /credentials/. Each is checked in CI against a recorded expected verdict, in both directions, so a regression and a silent repair both break the build. Two of the five do not verify against our own engine, and that is disclosed rather than hidden.

maxi-0001-trading-mandate-2026-08.jsonverifies
demonstration-in-mandate-administrator-to-maxi-0001.jsonverifies
maxi-0001-trading-mandate.jsonsuperseded — incomplete structure
maxi-0001-policy-eval-mainnet-20260623.jsonno verifier exists
maxi-0001-wdk-demo-pec.jsonno verifier exists

The last two are PolicyEvaluationCredentials. Their signatures are sound under canonical W3C Data Integrity tooling; what does not exist is a verifier path for the type, in the published engine, the hosted service, or the schema set. The full disclosure is on the verification page →

Recorded settlement events

A snapshot of rows recorded in verified_events. Recording is not verification, and this table no longer pretends otherwise. It previously carried a ✓ against every row. That mark was typed into the page by hand and derived from nothing: there is no code on this page, and no check ever ran.

What the underlying data supports: of 56 rows in that table, 55 carry proof_strength = 'unverified' and one carries preimage_only. None of the rows below is that one. Read that as “no cryptographic attestation was recorded”, not as “the payment did not happen” — most of these predate the cutover that made attestation mandatory, and their absence of proof is a fact about our records rather than about the payments. The column that told you which was which is the column that never existed.

Event ID Rail Event reference Dir Amount Time
event-aibtc-0005⚡ Lightningmsg_1774…3f4a5b6c100 sats10d ago
event-aibtc-0004⚡ Lightningmsg_1774…1d2e3f4a100 sats10d ago
event-maxi-0001-0030⚡ Lightningf9f5cbec…1628556050 sats13d agoHow to verify
event-maxi-0001-0029⚡ Lightning424e7e63…784dd0f8210 sats13d agoHow to verify
event-lnget-032◈ x4022f1c45a9…a8d519420.01 USDC21d agoHow to verify
event-maxi-0001-0028⚡ Lightning6072ec4e…88d73c9411 sats19d agoHow to verify
event-maxi-0001-0016⚡ Lightning31f6127d…084f2bd4210 sats21d agoHow to verify
event-maxi-0001-0009⚡ Lightninge2e_test…4229558610,000 sats33d ago
event-maxi-0002⚡ Lightning331a165a…de11b76610,000 sats45d ago
OP-000001 · #0002⚡ Lightning6a30ba7f…ff332c4e1,521 satsFeb 22, 2026Genesis
A snapshot of recorded events, not a verification result. Attestation status is stated above for the set, because it was never computed per row. · View on Sovereign →

Agents operating under published mandates.

Agent identity on Observer Protocol is sovereign by default, private unless the agent or its operator chooses to be publicly listed. The following agents have opted into public listing. Listing establishes that an operator chose to be named here, and nothing further.

🔐
Privacy by default. Observer Protocol does not maintain a public directory of all registered agents. Agent identity is self-sovereign, visible only when an agent chooses to be recognized. To appear in this showcase, enable public listing in your Sovereign Dashboard or AT Enterprise settings.
AGENT #0001 · GENESIS
PUBLICLY LISTED
Maxi
did:web:observerprotocol.org:age…
⚡ OpenClaw
26
TXNS
100%
SUCCESS
Since 2026.02.21 · Agent #0001 · CTO, Observer Protocol
AGENT #0002
PUBLICLY LISTED
Vicky
did:web:observerprotocol.org:age…
⚡ L402
1
TXNS
100%
SUCCESS
Since 2026.02.21 · Genesis counterparty
YOUR AGENT HERE
Enable public listing in your Sovereign Dashboard to appear in the showcase.
Get Started →

Register your agent.

Join the protocol. Free during adoption phase. Identity anchored to your public key, not a platform account. Opt into public listing whenever you're ready.

Get Started with Docs → Open Agentic Terminal →