Introduction

An agent that publishes an ongoing stream — the capabilities it offers, the events in a lifecycle it manages, the deltas in a registry it operates — is served today by RSS, by Atom, by ActivityPub, or by a bespoke webhook. For completeness, all of them are trust-the-server channels. A feed can omit an item, reorder two, or serve one subscriber a shorter history than another, and no subscriber can tell.

The resulting failure is quiet. A peer learns that an agent offers a capability. The later withdrawal never arrives. The peer holds a well-formed, signed announcement, and the absence of a follow-up is identical to the absence of any change. It keeps dispatching work to a capability that no longer exists.

Prior work

Signed, hash-chained, append-only logs are well established. Certificate Transparency [RFC 9162] defined the model for proving a log complete and consistent, and Trillian and Sigstore's Rekor are production systems built on it. Secure Scuttlebutt gives each identity a signed hash-chained append-only feed, structurally close to what follows here. Hypercore and the AT Protocol ship signed append-only repositories with cryptographic history. Nostr signs events; ActivityPub with HTTP Signatures authenticates activities.

Several of these establish completeness properly. Each also requires the adopter to take on something substantial. Certificate Transparency assumes an operated transparency log: a Merkle tree, monitors, auditors. Secure Scuttlebutt, the AT Protocol and Nostr assume a protocol — an identity model, a replication strategy, a network. Both dependencies are proportionate to what they deliver at their own scale. Neither is proportionate to an agent publishing a few dozen capability announcements a year.

The nearest standards-track work is SCITT, which defines transparency for single-issuer signed statements. Its guarantee is per-statement: a Receipt establishes that a statement was registered at a position in a log. It is explicit that this is not completeness — an issuer may submit some but not all of the statements it issues, and detecting that is left to the relying party. The question this document answers is the one SCITT sets aside, and a contiguous sequence over a single issuer's stream is the mechanism it uses to answer it. Key Transparency treats the same equivocation problem at protocol scale; COSE Receipts encodes the proof types a tree-based log needs and this one does not.

Scope

A Verifiable Agent Feed specifies the feed format and the verification a subscriber performs on it. No transport, no storage, no subscription registration, no network. The payload is opaque, so one format carries any agent's stream.

Each entry is Ed25519-signed by the issuer and commits by hash to its predecessor. A subscriber walking a contiguous run from an anchor it holds verifies authenticity, integrity and completeness in one pass. A signed head fixes the feed at a position and exposes a later rewind.

The chain is strictly linear. Completeness is established by walking it, at O(n), where a Merkle log answers in O(log n). There is no inclusion proof for a single historic entry: a subscriber walks, or adopts a signed checkpoint and inherits the issuer's word for the history behind it. At the scale of a certificate log this trade is wrong, and Certificate Transparency remains the correct construction. At the scale of an announcement feed it is not.

Limits

A valid page establishes that the subscriber received an authentic, complete run of entries the issuer signed. It establishes nothing about whether those entries are true, and nothing about what the issuer showed anyone else. Both limits are stated in the specification alongside the rules they qualify.