This project
Wire Format & Verification
The normative wire shape and verification procedure. Published here; this site is the specification of record. Working draft — reviewable, not yet frozen.
→ PAPERVerifiable Subscription for Agent Communication
S. Chandra, Stellarminds.ai. Working paper, version 0.1, August 2026. The argument for why the primitive should exist; this specification states how it works.
↗What it defends, and what it does not
Field tampering, structural forgery, history tampering, and rewind on one side; payload truth, forking, withholding, timestamp truth, key custody, and resource bounds on the other.
Vector corpus
Deterministically generated positive and negative vectors — dropped entry, tampered payload, wrong anchor, head behind entries, partial page, rewound head, extra field, unknown version — replayed by the reference suite.
sm-feed
The reference implementation: build, sign, chain, serve, and verify, plus compaction and equivocation. One runtime dependency.
Standards this builds on
Edwards-Curve Digital Signature Algorithm (EdDSA)
Ed25519, the signature scheme every entry and head is signed with. Josefsson, Liusvaara.
↗ RFC 8785JSON Canonicalization Scheme (JCS)
Sorted-key serialisation, so two implementations agree byte for byte on what was signed and hashed. Rundgren, Jordan, Erdtman.
↗ W3C CCGThe did:key Method
Identifiers derived directly from a public key, so a signature checks without a resolution step — and a feed cannot rotate keys without changing identity.
↗ RFC 3339Date and Time on the Internet: Timestamps
The format of issued_at and generated_at, both caller-asserted. Klyne, Newman.
Related work
Signed append-only logs are well established. The systems below share ground with this format; several are direct antecedents. See the Introduction for the comparison.
Certificate Transparency 2.0
Established the model for proving a log complete and consistent, and the direct model for the equivocation work here. Obsoletes RFC 6962, which remains the deployed version and the reference for the Merkle consistency proof algorithm. Laurie, Langley, Kasper. See also Trillian and Sigstore's Rekor.
↗ IETF SCITTSupply Chain Integrity, Transparency and Trust
Single-issuer signed statement transparency, and the nearest standards-track neighbour. A Receipt establishes that a statement was registered at a position, not that a relying party received every statement an issuer made — the architecture records, at §9.3, that an issuer may “refuse to register their Statements with a Transparency Service, or selectively submit some but not all the Statements they issue”. That gap is what a contiguous sequence closes, and it is why this format is a complement rather than an alternative.
↗ IETF KEYTRANSKey Transparency
Public keys published in a cryptographically protected append-only log, so a malicious entry is equally visible to the key's owner and to their contacts. The working group's subject is the equivocation problem of §7, treated at protocol scale and with a monitoring model this format does not assume.
↗ IETF COSECOSE Receipts
A CBOR encoding for inclusion, consistency and non-inclusion proofs over verifiable data structures. The proof vocabulary this format declines to need, having chosen a linear walk over a tree (§8).
↗ C2SPtlog-witness · tlog-cosignature
A deployed witness protocol: a log requests cosignatures on a checkpoint, and a witness — keeping only the last checkpoint it verified — cosigns after checking a consistency proof. It requires a Merkle consistency proof, so it does not apply unchanged to a linear chain; it is the model the witness layer of §9 should follow rather than reinvent.
↗ PROTOCOLSigsum
A transparency log built on minimalism and distributed trust, reducing complexity by deliberately not following the Certificate Transparency design. The closest philosophical sibling to this work: witness cosigning is part of the log rather than a reactive gossip-audit protocol, and a witness holds O(1) state.
↗ PROTOCOLSecure Scuttlebutt
A signed hash-chained append-only feed per identity — the closest structural prior art. Differs in that it arrives as a complete social protocol: identity model, replication, gossip network.
↗ PROTOCOLHypercore
Signed append-only logs with cryptographic history and efficient replication, using a Merkle tree where this format deliberately does not.
↗ PROTOCOLAT Protocol
Per-account signed repositories committed over a Merkle search tree, with a federation and identity model attached.
↗ PROTOCOLNostr
Signed events over relays. Gives authenticity and integrity per event; makes no completeness claim about the set a client receives from any relay.
↗ W3CActivityPub
The decentralised social networking protocol, with HTTP Signatures for authentication in practice. Authenticates activities without chaining them.
↗ RFC 4287The Atom Syndication Format
The baseline this is measured against: a widely deployed feed format that asks the subscriber to trust the server for completeness. Nottingham, Sayre.
↗ W3CBitstring Status List
A different answer to the withdrawal problem: publish a compressible bitstring of revocation states and have a verifier poll it. It supplies current status without a history; this format supplies a complete history without currency (§5.1). A consumer needing both needs both.
↗Context
Project NANDA
The Internet of AI Agents — discovery, identity, and the ecosystem this primitive is aligned with.
↗ PROTOCOLA2A — Agent2Agent
Agent Cards publish an agent's capabilities for discovery. Card signing is optional and no revocation mechanism is specified: the announcement half of the capability profile (§A) without the withdrawal half that motivates it.
↗ PRIMITIVEAgency Receipts
The signed, hash-chained record primitive whose Ed25519, JCS and did:key construction this reuses.
↗ PRIMITIVEAttested Actions
Action-evidence records in the same family — a natural payload for a feed to carry.
↗