Agent Context Distribution Protocol (ACDP) — Chain Verification and Evidence Bundles

Document: RFC-ACDP-0017 Version: 0.5.0 Status: Community Standards Track (Final; §10–§11 registry amendments (0.5.0) Draft)

This RFC specifies chain verification: one consumer-side algorithm that verifies a whole derived_from graph, offline, as of a past instant T, and emits a deterministic, digestible verdict. It defines three objects:

• the evidence bundle (acdp-evidence/1): a self-describing, untrusted container for everything the algorithm consumes;
• the chain verdict (acdp-chain-verdict/1): a JCS-canonical report with two digests, one sealable at T and one over the full result;
• the event receipt (acdp-event-receipt/1): a registry-signed acceptance time for a lifecycle event. This one is a wire amendment to RFC-ACDP-0013.

The algorithm runs identically online and offline. The two modes differ only in where the evidence comes from. It depends on RFC-ACDP-0001, -0004, -0006, -0010, -0012, -0013, -0014 and -0015. It amends RFC-ACDP-0013 (§10 of this document) and RFC-ACDP-0004 §5.1 (§11).

1. Status of This Memo

This document is a Final ACDP specification at version 0.5.0, promoted 2026-10-26. It is the first Final document on the acdp/0.5.0 line, which as a whole remains Draft (VERSIONING.md). Breaking changes now require a new RFC and a version bump.

Promotion evidence. The consumer-side conformance fixtures (chain-001..chain-011, profile acdp-consumer-chain) pass against two independent interoperating implementations:

• acdp-rs acdp-chain 0.17.1;
• acdp-verifier-py at c95cf7b, written from this text alone.

Both reproduce every known-answer vector byte for byte. That is 31 verdicts: chain-001, 002, 003 and 010 scenario A, plus the 27 cross-implementation edge vectors of chain-011. Both also pass the behavioral consumer scenarios. The two implementations' disagreements were resolved in this text before promotion (CHANGELOG, 2026-10-26).

Still Draft. The registry-side amendments in §10 (lifecycle event receipts) and §11 (receipts on lineage members) remain (0.5.0) Draft, not frozen. Only one registry implementation (acdp-registry-rs, in production since 0.5.6) exercises their registry-side scenarios (chain-009 A–B). They are promoted when a second registry does. The consumer-side verification of event receipts (§10.3) is Final.

The acdp-consumer-chain profile (§13) is OPTIONAL. A consumer that never verifies chains is unaffected. The registry-side amendments in §10 and §11 bind only registries that advertise acdp-registry-receipts and declare acdp_version ≥ 0.5.0.

Nothing in this document invalidates any existing body, signature, content_hash, receipt, checkpoint or cosignature. §10 adds a new signed object; it changes none.

2. Conventions and Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 ([RFC 2119], [RFC 8174]) when, and only when, they appear in all capitals.

Timestamps are canonical millisecond-precision RFC 3339 UTC (RFC-ACDP-0001 §5.3). Every comparison in this document is between such timestamps, and compares instants.

3. Motivation

Before this RFC, ACDP could verify one body, online, now. An auditor of an agent decision needs to verify the graph of contexts behind it, offline, at the instant the decision was made. There were four gaps:

1. No chain primitive. RFC-ACDP-0006 §4.1 step 8 bounds a derived_from walk and requires partial-walk reporting (fed-010). But it defines no consumer report shape, and no reusable algorithm.
2. No offline evidence format. Every trust check reaches the network: did:web resolution (RFC-ACDP-0001 §5.11), receipt keys (RFC-ACDP-0010 §8), revocation discovery (RFC-ACDP-0014 §8), lifecycle state (RFC-ACDP-0013 §4.1). A party holding only an exported bundle could run none of them.
3. No time other than "now". RFC-ACDP-0014 compromise windows are retroactive by design. A revocation published after a decision makes a body invalid now that was correctly accepted then, and before this RFC both cases collapsed into a single revoked. Retractions had no provable time at all, because occurred_at is claimed by the actor and array order carries no clock.
4. No deterministic verdict. There was nothing a decision system could seal, and nothing an auditor could recompute and byte-compare.

4. The Evidence Bundle: acdp-evidence/1 (NORMATIVE)

An evidence bundle is a single JSON object, validated by acdp-evidence.schema.json.

{
  "evidence_version": "acdp-evidence/1",
  "roots": ["acdp://registry.example.com/11111111-1111-4111-8111-111111111111"],
  "exported_at": "2026-10-24T12:00:00.000Z",
  "contexts": {
    "acdp://registry.example.com/11111111-1111-4111-8111-111111111111": {
      "body": { "...": "..." },
      "registry_receipt": { "...": "..." },
      "lifecycle_events": [],
      "event_receipts": [],
      "log_inclusion": { "...": "..." }
    }
  },
  "did_documents": {
    "did:web:agents.example.com:producer": [
      {
        "document": { "...": "..." },
        "observed_at": "2026-10-24T11:59:58.000Z",
        "observed_by": "seam-runtime",
        "source": "https://agents.example.com/producer/did.json"
      }
    ]
  },
  "revocation_discovery": {
    "did:web:agents.example.com:producer": [
      {
        "vantage": "registry.example.com",
        "outcome": "not-revoked-complete",
        "completed_at": "2026-10-24T11:59:59.000Z"
      }
    ]
  },
  "checkpoints": [ { "checkpoint": { "...": "..." }, "cosignatures": [] } ],
  "omitted": [
    { "ctx_id": "acdp://registry.example.com/22222222-2222-4222-8222-222222222222", "reason": "withheld" }
  ]
}

4.1 Posture

The bundle is unsigned and untrusted. A verifier MUST NOT believe any member because it is present. Every stage (§7) re-derives its result from content, and the trust basis of every result says what that result ultimately rests on. A bundle that fails schema validation MUST be rejected as a whole. A verifier MUST NOT verify the parts of it that happen to parse.

4.2 Members

• contexts is keyed by ctx_id. Each entry carries the context's body and, where the exporter obtained them, the context's registry_receipt, lifecycle_events, event_receipts (§10) and log_inclusion. The map key is a claim: the identity stage (§7.2) checks it against body.ctx_id and registry_receipt.ctx_id. Key-revocation contexts (RFC-ACDP-0014 §4) that the verifier should apply are carried here like any other context. They do not need to be reachable through derived_from.
• did_documents is keyed by DID and holds a history: an array of snapshots, each with the document as fetched, observed_at, and optionally observed_by and source. Several snapshots per DID let the as-of pass choose the one in force at T (§6.2). did:key DIDs MUST NOT appear, because they resolve arithmetically. Registry DID documents (for receipt, event-receipt and checkpoint keys) and witness DID documents go in the same map.
• revocation_discovery is keyed by producer DID and holds observed RFC-ACDP-0014 §8 discovery records. Each record has a vantage (the registry authority queried), an outcome (revoked, not-revoked-complete or unknown) and a completed_at. A producer with no record has discovery outcome unknown. Its outcome is never not-revoked.
• checkpoints holds RFC-ACDP-0012 checkpoints with any RFC-ACDP-0015 cosignatures. consistency_proofs MAY carry RFC-ACDP-0012 §9.2 proofs between them.
• omitted is the exporter's honest list of contexts it deliberately left out, each with a reason: withheld (left out by policy, e.g. visibility), not_retrievable (the fetch failed) or limit (an export budget fired).
• roots and exported_at are informational. The verifier takes its roots from the caller (§6), and exported_at plays no part in any pass.

4.3 Exporting

An exporter collects a bundle by walking online under the §6.1 rules. It fetches each node with its receipt, lifecycle events, event receipts and log inclusion; snapshots every DID document it resolved, recording observed_at; and runs RFC-ACDP-0014 §8 discovery once per distinct producer, recording the outcome. Collecting and verifying are separate. An exporter MAY collect without trusting what it collects.

Exporters SHOULD prefer the receipt-bearing lineage listing (§11) to per-context retrieval, and SHOULD include every member of any key-revocation lineage they discovered (RFC-ACDP-0014 §7 requires the whole lineage for the earliest-compromised_since fold).

4.4 Embedding

A host format MAY carry an acdp-evidence/1 object as a file. Seam's evidence bundle does this, for example, with an acdp-evidence.json listed in its manifest. The host's own integrity mechanism, not ACDP's, protects the file. The verdict (§9) binds to the bundle bytes through evidence_digest.

5. Time Semantics (NORMATIVE)

5.1 Evidence time, by kind

5.2 The two passes

• As-of pass (T). Every stage is evaluated using only evidence whose evidence time is ≤ T. Evidence with no evidence time counts as not known at T, with the two exceptions §7 states: bodies, and unattested events when require_attested_events is false. This conservative rule makes a backdated retraction harmless, and a later revocation non-retroactive in the as-of answer.
• Latest pass. Every stage is evaluated using all evidence.

The as-of pass runs only when the caller supplies T. The latest pass always runs.

5.3 Revocation at T

A key-revocation context is applied in the as-of pass only if its own evidence time is ≤ T. Once it is applied, RFC-ACDP-0014 §7 runs unchanged: the compromise-boundary comparison, the earliest-compromised_since fold over the applied members of the revocation lineage, producer scope, and attribution precedence. A revocation that is not applied in the as-of pass is reported as drift (§8.4) when the latest pass applies it.

5.4 Horizon

The horizon is the greatest evidence time over all evidence in the bundle that has one. (NORMATIVE) Concretely, it is the maximum of these values:

• the created_at of every registry receipt that verifies;
• the accepted_at of every event receipt that passes §10.3 on its own (every step except step 8, which is a check across receipts);
• the timestamp of every checkpoint whose signature verifies (carried or in a log_inclusion);
• the observed_at of every did_documents snapshot;
• the completed_at of every discovery record, whatever its outcome.

Cosignature witnessed_at values are bounds, not evidence times, and do not count. Neither do pinned snapshot instants, which are caller input, or exported_at. The horizon is computed once, over the whole bundle, independent of T. A bundle with no timed evidence has a null horizon. The verifier MUST NOT read a wall clock in either pass. Offline there is no "now", and the report states the horizon in its place.

6. The Algorithm (NORMATIVE)

verify_chain(roots, evidence, options) -> acdp-chain-verdict/1
options = { as_of: T | null, limits, pinned, require_attested_events }

6.1 Walk

The verifier walks breadth-first from the roots over derived_from. The order is deterministic:

1. The roots are deduplicated, sorted by ctx_id in ascending byte order of their UTF-8 encoding, and assigned depth 0.

2. Nodes are expanded in order of increasing depth. Within one depth, they are expanded in ascending ctx_id byte order.

3. A node's derived_from entries are considered in array order. A ctx_id already admitted is a DAG join: it adds an edge and admits no new node.

4. The RFC-ACDP-0006 §4.1 controls apply, combined with AND. limits carries max_depth, max_nodes and max_fanout, which default to 10, 500 and 100. A caller MAY lower them and MUST NOT raise them above those defaults. A verifier MUST reject options carrying a limit above its default, or below the schema minimum (max_depth 0, max_nodes 1, max_fanout 0), with an error and emit no verdict. Each limit truncates rather than aborts, as follows:

   • max_depth. A node at depth max_depth is verified but not expanded.
   • max_fanout. Only the first max_fanout distinct entries of a node's derived_from are admitted.
   • max_nodes. Once max_nodes nodes have been admitted, no further node is admitted.

   Every ctx_id that is referenced but not admitted joins the frontier. Frontier entries are not nodes: they appear in frontier only, never in nodes. The report sets complete: false and names the first control that fired, in walk order.

5. The verifier MAY also enforce a wall-clock time budget. A verdict produced under a fired time budget MUST set control: "timeout" and complete: false, and is exempt from the determinism requirement (§9.3).

6. A cycle is a derived_from path from a node back to itself. It is reported as stage presence: cycle on every node that lies on the cycle. Honest registries cannot produce one, because derived_from can name only ctx_ids that already exist, so a cycle is evidence of a forged body or a forged bundle. (NORMATIVE) Cycles (here) and tainted paths (§8.3) are computed over the walk graph: the edges the walk considered, i.e. a node's first max_fanout distinct derived_from entries, from nodes that were expanded. An edge the walk did not consider plays no part in either.

A node is resolved from evidence.contexts. A ctx_id the walk admits but contexts does not carry has presence withheld when omitted lists it with reason withheld, unresolved when omitted lists it with any other reason, and absent when omitted does not list it. An online verifier collects first (§4.3) and then runs the same algorithm over what it collected. It MUST NOT fetch evidence during a pass.

6.2 DID-document selection

For a did:web key:

• In the as-of pass, the verifier uses the snapshot with the greatest observed_at ≤ T (for a pinned snapshot, its instant). Ties are broken as follows: a pinned snapshot beats an observed one; among observed snapshots, the later array position wins. With no such snapshot, the key stage is unknown with reason no_evidence_at_as_of.
• In the latest pass, it uses the snapshot with the greatest observed_at.

The chosen snapshot is evaluated under RFC-ACDP-0001 §5.11 as though it were the fetched document. There is no forced re-fetch offline. An online verifier performs the §5.11 re-fetch while collecting, and the bundle records the result.

did:key resolves arithmetically (RFC-ACDP-0001 §5.11.1) with basis self in both passes.

6.3 Pinned trust

pinned is a caller-supplied set containing any of:

• DID-document snapshots, each bound to the instant at which the caller vouches for it;
• registry DIDs whose receipt keys the caller trusts;
• witness DIDs;
• discovery vantages: hostnames whose RFC-ACDP-0014 §8 discovery records the caller vouches for. A revocation_discovery record whose vantage is pinned has basis pinned rather than observed;
• (0.5.0) keyless attesters: registry DIDs the caller accepts as RFC-ACDP-0021 key attesters (RFC-ACDP-0021 §10, §11). This member is Draft; a verifier without RFC-ACDP-0021 support rejects it as an unknown member, as for any options that fail the shape (§6.1(4)).

(NORMATIVE) pinned is a JSON object with these members, each OPTIONAL:

{
  "snapshots":  [{ "did": "did:web:…", "document": { }, "instant": "2026-09-20T00:00:00.000Z" }],
  "registries": ["did:web:…"],
  "witnesses":  ["did:web:…"],
  "vantages":   ["registry.example.com"],
  "keyless_attesters": ["did:web:…"]
}

registries, witnesses, vantages and keyless_attesters are sorted ascending by UTF-8 bytes and deduplicated. snapshots are sorted by did, then instant, and deduplicated. Two pinned snapshots with the same did and instant but different documents are an error under §6.1(4). An empty array member is omitted. A caller that pins nothing passes pinned absent, null or {}; all three are equivalent. The shape is #/$defs/pinned in acdp-evidence.schema.json, and options that fail it are rejected as in §6.1(4).

A pinned snapshot takes part in §6.2 selection like an observed one, but its basis is pinned. Pinning promotes a basis. It never overrides a failed check: a pinned key that does not verify a signature is still signature: invalid.

pinned contributes to the verdict through options_digest (§9.1), computed over the normalized object above.

6.4 Attested events

require_attested_events defaults to true. When true, the as-of pass considers only lifecycle events with a verified event receipt (§10) whose accepted_at ≤ T, and whose signature verifies under the key located as of T (§6.2). For a producer actor, that key MUST also be in the as-of snapshot's assertionMethod. (NORMATIVE) The one exception is an unsigned event whose actor is the origin registry's DID (RFC-ACDP-0013, registries not advertising receipts). It is admitted on its verified event receipt alone, and never without one. When false, an as-of pass MAY also consider an event without one, provided its signature verifies and its occurred_at is ≤ T. Such an event is labelled basis observed.

7. Per-Node Stages (NORMATIVE)

Each stage reports a value. Where the stage defines them, it also reports a basis, an evidence_time and a reason. (NORMATIVE) acdp-chain-verdict/1 defines one reason token, no_evidence_at_as_of, emitted exactly where this document names it (§6.2, §7.5, §7.6). A verifier MUST NOT emit any other reason, since the verdict bytes are compared across implementations (§9.3). Stages run in the order below, in both passes, over the evidence that pass admits. Stage values are the closed vocabularies in acdp-chain-verdict.schema.json.

7.1 presence

present, withheld, unresolved, absent, cycle, or not_yet_published. A truncated walk is reported through complete, control and frontier (§6.1), never as a node presence.

• not_yet_published applies in the as-of pass only: the node's receipt verifies and its created_at is later than T. A chain that is honest at T cannot reference such a node.
• A node with no evidence time is present in the as-of pass, with the caveat undated (§8.1). Its content verifies arithmetically, but its existence at T is unproven.

A node that is not present runs no further stages. A cycle presence carries value only. A node's derived_from member (§9.1) is emitted exactly when its latest presence is present.

7.2 identity

ok, unbound, or mismatch.

• mismatch when the bundle key ≠ body.ctx_id, when a present receipt's ctx_id, lineage_id, origin_registry or created_at disagrees with the body, or when the RFC-ACDP-0004 §2.1 first-version lineage_id derivation fails. This is the fed-011 binding, carried offline.
• unbound when the body has no verified receipt. Its identity fields are then unattested.

7.3 content_hash

ok or mismatch, by recomputing under RFC-ACDP-0001 §5.7 over the exclusion-stripped body. Basis self.

7.4 signature

ok, invalid, or unresolvable, under RFC-ACDP-0001 §5.8. It uses the key the key stage resolves. (NORMATIVE) It verifies the signature over the body's claimed content_hash, as RFC-ACDP-0001 §5.8 defines the preimage. A tampered body is caught by content_hash: mismatch, not by this stage. (NORMATIVE) When the key stage is unknown (as-of pass, no_evidence_at_as_of), the signature stage is omitted: there is no key to verify against, and the key: unknown verdict rule (§8.1) already decides the node.

7.5 registry_receipt

absent, ok, or invalid, under RFC-ACDP-0010 §8, with the registry DID document chosen per §6.2. An ok value carries key_status: current or historical.

A receipt that fails is treated as absent everywhere downstream, as RFC-ACDP-0010 §8 requires.

(NORMATIVE) An ok receipt has basis pinned when its registry_did is pinned (§6.3), and registry otherwise. The registry DID snapshot that supplied the receipt key does not make the stage rest on basis observed: the receipt is the registry's own signed attestation, and trusting the registry for it is the RFC-ACDP-0010 trust model. The observed snapshot is still what the pass selects under §6.2. (NORMATIVE) RFC-ACDP-0010 §8 step 5 (key binding) runs only when the key stage locates a producer key. When it locates none (key is unknown, or unresolvable), step 5 is deferred: the receipt is evaluated on its other steps, and the key stage decides the node (§8.1). A receipt that verifies this way keeps its key_fingerprint as the registry's attestation of the signing key, and RFC-ACDP-0014 §7 placement uses it (§7.9). So a node whose key cannot be resolved, but whose receipt names a revoked key, is key_revocation: revoked (and key: revoked, §7.6), not not-revoked. A present receipt for which no registry DID snapshot is selectable is invalid. In the as-of pass, when the only selectable snapshots are dated after T, the value is invalid with reason no_evidence_at_as_of.

7.6 key

current, historical_receipt_attested, revoked, unplaceable, unresolvable, or unknown.

• current: the signing key is in the chosen snapshot's assertionMethod, or the key is a did:key.
• historical_receipt_attested: RFC-ACDP-0010 §10 applies against the chosen snapshot.
• revoked and unplaceable: these come from key_revocation (§7.9). A revocation verdict overrides this stage.
• unresolvable: no snapshot, or a snapshot that cannot be evaluated under §5.11 or lacks the signing key, in the latest pass. The as-of-pass equivalent is unknown, with reason no_evidence_at_as_of. (NORMATIVE) That mapping covers only outcomes that depend on which snapshot is selected. A key that cannot resolve whatever the evidence is unresolvable in both passes, with signature: unresolvable. Examples are a key_id whose DID ≠ body.agent_id, an empty fragment, or a did:key that does not decode. Such a body is not a schema failure, so the bundle is not rejected (§4.1).

(0.5.0, Draft) A keyless-signed node (RFC-ACDP-0021) is evaluated with these same values: the bundle carries its acdp:key-attestation in contexts, and the stage is current or historical_receipt_attested with basis registry per RFC-ACDP-0021 §10. A verifier without RFC-ACDP-0021 support reaches unresolvable. This note adds no stage value and changes no Final rule.

7.7 log

absent, included, cannot_verify, or invalid, under RFC-ACDP-0012 §9 and §9.1. An included value carries tree_size, checkpoint_time and witnesses. witnesses is the count of distinct trusted witness DIDs whose cosignatures verify under RFC-ACDP-0015 §8, over a verified checkpoint. A witness is trusted when it is pinned (§6.3).

In the as-of pass, a checkpoint counts only if its timestamp ≤ T. (NORMATIVE) The verifier rebuilds the leaf with key_fingerprint taken from the node's verified registry_receipt (RFC-ACDP-0012 §4 requires them equal), never from the key the key stage locates. The log stage therefore does not depend on the key stage, and with no verified receipt the leaf cannot be rebuilt, which gives cannot_verify.

7.8 retraction

not_retracted, retracted, invalid, or unknown.

1. Admitting events. The pass admits a prefix of lifecycle_events: the longest prefix whose every event is admitted under §6.4 (as-of) or carries a verified signature (latest, RFC-ACDP-0013 §5). In the latest pass, an event with a verified event receipt (§10) has basis registry. (NORMATIVE) Latest-pass admission rules:
   • A producer-actor event is verified under the latest snapshot.
   • Its key MUST be in that snapshot's assertionMethod, or else in its verificationMethod and carry a verified event receipt. That second case is the receipt-attested historical key, by analogy with RFC-ACDP-0010 §10: the receipt's event_hash covers the signature as it was accepted.
   • An unsigned event whose actor is the origin registry's DID is admitted only with a verified event receipt, in either pass (§6.4). An event admitted on its signature alone has basis observed, and the retraction stage takes the weakest basis among the admitted events.
2. Deriving the state. RFC-ACDP-0013 §7.1 retraction state is derived over the admitted prefix. (NORMATIVE) The stage's evidence_time is the accepted_at of the last admitted event when that event's receipt verifies; otherwise the stage has no evidence_time. With no admitted events, the stage carries neither basis nor evidence_time.
3. unknown in the as-of pass when an event that is not admitted precedes an admitted one. The prefix is then unprovable.
4. invalid when §10.3 step 8 fails: the verified event receipts' accepted_at values decrease with index. A receipt failing any other §10.3 step (a mismatched index, event_hash, registry_did or signature, or step 9) is treated as absent, and its event has no evidence time; that alone never makes the stage invalid.

7.9 key_revocation

not-revoked, pre-compromise, revoked, unplaceable, or unknown. RFC-ACDP-0014 §7–§8 applies, with these rules:

• Applying revocations. The verifier applies the key-revocation contexts the pass admits (§5.3), under RFC-ACDP-0014 §7 producer scope. (NORMATIVE) A registry-attested revocation (RFC-ACDP-0014 §6) is applied to a node only under that section's strict default scope, read offline: the revocation's agent_id is did:web:<authority>, where <authority> is the revocation's own origin_registry, and that authority equals the node's origin_registry or the registry_did authority of the node's verified receipt. Its metadata.revoked_key_controller MUST equal the node's body.agent_id.
• Discovery records. It considers the discovery records the pass admits. A record is admitted when its completed_at ≤ T in the as-of pass, and always in the latest pass.
• Producer outcomes. A producer has a revoked discovery outcome when any admitted revocation applies to it. It has not-revoked only when an admitted record says not-revoked-complete. Otherwise its outcome is unknown. (NORMATIVE) The rules for discovery records:
  • A record never makes the stage revoked; only an applied revocation context does.
  • A record with outcome unknown is ignored.
  • An admitted record with outcome revoked makes the outcome unknown when no admitted revocation applies, because a vantage saw a revocation the bundle does not carry.
  • Otherwise, the deciding record is the admitted not-revoked-complete record that is greatest by (vantage pinned, completed_at, array position). It supplies the stage's evidence_time (its completed_at) and its basis (pinned or observed). (NORMATIVE) Revocation contexts in the bundle that do not name the key are not evidence of not-revoked: the bundle is untrusted (§4.1), and its exporter can leave the revoking context out. Only a discovery record can decide not-revoked.
• Precedence is RFC-ACDP-0014's own: refusal, then unknown, then pre-compromise, then not-revoked.
• Basis. The value carries the basis of the evidence that decided it. A revocation that decided it is registry. A discovery record that decided it is observed.

8. Verdicts and Aggregation (NORMATIVE)

8.1 Node verdict

Each pass yields one node verdict. The first rule that matches decides it:

1. refused when any of these hold:

   • presence is cycle or not_yet_published;
   • identity: mismatch;
   • content_hash: mismatch;
   • signature is invalid or unresolvable;
   • key is revoked, unplaceable or unresolvable;
   • key_revocation is revoked or unplaceable.

2. unknown when any of these hold:

   • presence is withheld, unresolved or absent;
   • key: unknown;
   • key_revocation: unknown;
   • retraction is unknown or invalid;
   • registry_receipt: invalid or log: invalid.

3. ok_with_caveats when any caveat holds. The caveats are:

   • undated;
   • identity: unbound;
   • key is historical_receipt_attested;
   • key_revocation: pre-compromise;
   • registry_receipt.key_status: historical;
   • retraction: retracted;
   • log: cannot_verify;
   • any stage resting on basis observed.

   The verdict lists the caveats that hold, as the schema's tokens, sorted ascending by UTF-8 bytes. (NORMATIVE) caveats is computed from the stages independently of which rule decides the verdict, so a refused or unknown node also lists every caveat that holds for it. In the order of the list above, the tokens are undated, identity_unbound, historical_key, pre_compromise, historical_receipt_key, retracted, log_cannot_verify and observed_basis.

4. ok otherwise.

retracted is a caveat, not a refusal. A retracted body stays valid and retrievable (RFC-ACDP-0013 §8.1). Whether to rely on it is the consumer's policy, and §8.3 supplies what that policy needs.

8.2 Chain verdict

Each pass also yields one chain verdict: the worst node verdict, in the order refused > unknown > ok_with_caveats > ok. A pass with complete: false has a chain verdict no better than unknown.

8.3 Tainted paths

For each node whose node verdict is refused, or whose retraction is retracted, the verdict lists one tainted path: the shortest path over the walk graph (§6.1(6)) from any root to that node, as a ctx_id array. Ties are broken by comparing the arrays lexicographically, element by element, in UTF-8 byte order.

Tainted paths do not change any node verdict. A descendant of a retracted or refused node keeps its own verdict, and policy acts on ancestry without re-walking.

8.4 Drift

When both passes run, the verifier emits one drift entry, {ctx_id, kind}, for each kind below that holds for a node. A stage difference that matches no kind and leaves the node verdict unchanged emits no entry. (NORMATIVE) A stage the as-of pass did not run (because the node was not present as of T) counts as not having reached the latest value, so for example a node that is not_yet_published as of T and retracted latest emits both published_after_as_of and retracted_after_as_of. The kinds are:

A clean key rotation after T is not drift. Rotation is not compromise (RFC-ACDP-0014 §9). It shows up as key: current as of T and historical_receipt_attested latest, which is a caveat change and therefore verdict_changed only if the node verdict itself changes.

9. The Verdict Object: acdp-chain-verdict/1 (NORMATIVE)

9.1 Shape

The verdict is validated by acdp-chain-verdict.schema.json. Its members are:

• verdict_version: the literal acdp-chain-verdict/1.
• roots: sorted and deduplicated.
• as_of: T, or null.
• horizon.
• limits: max_depth, max_nodes and max_fanout.
• require_attested_events.
• options_digest: sha256: + hex(SHA-256(JCS(pinned))) over the normalized object of §6.3, or null when pinned is absent or {}.
• evidence_digest: sha256: + hex(SHA-256(JCS(bundle))).
• complete, control and frontier (sorted).
• nodes: sorted by ctx_id. Each node carries depth (the shortest distance from a root), derived_from (as in the body), and an as_of and a latest object. Each pass object holds the §7 stages and the §8.1 verdict and caveats.
• chain: {as_of, latest} chain verdicts.
• tainted_paths: under as_of and latest, each sorted.
• drift: sorted by ctx_id, then by kind.
• as_of_digest and verdict_digest.

When as_of is null, every as_of member is null and drift is empty. A member that does not apply (for example, the stages of a node that is not present, or key_status on a failed receipt) is omitted, never null. The only nullable members are those the schema declares nullable. This keeps the JCS bytes unique.

9.2 Digests

• verdict_digest = sha256: + hex(SHA-256(JCS(verdict without as_of_digest and verdict_digest))). It identifies the full result, over this exact bundle.

• as_of_digest = sha256: + hex(SHA-256(JCS(the as-of projection))). The projection is the object made of these members only:

  • verdict_version, roots, as_of, limits, require_attested_events and options_digest;
  • complete, control and frontier;
  • nodes, each reduced to ctx_id, depth, derived_from and as_of;
  • chain and tainted_paths, each reduced to its as_of member and kept nested: {"chain": {"as_of": …}, "tainted_paths": {"as_of": …}}.

  It is null when as_of is null.

as_of_digest is the value to seal at T. It omits evidence_digest, horizon and everything from the latest pass, so it is stable as evidence accumulates after T. The bodies themselves are immutable, and later receipts, events, revocations and snapshots fall outside the as-of pass. An auditor holding a later bundle reruns verify_chain with the same T, limits and options, and compares as_of_digest.

A mismatch means the auditor's bundle differs from the sealer's in evidence dated ≤ T. The as-of projection pins exactly the stages that rest on that evidence, so the mismatch names what to examine. Evidence dated ≤ T that rests on basis observed can be fabricated by whoever produced the bundle. That is why such evidence is labelled, and why a sealer that witnessed the evidence SHOULD pin it (§6.3).

9.3 Determinism (NORMATIVE)

Given the same roots, bundle bytes and options, and no fired time budget, every conformant implementation MUST emit a verdict whose JCS serialization is byte-identical. In particular, its as_of_digest and verdict_digest MUST be equal.

Implementations MUST NOT add members to the verdict object. Diagnostics, durations and fetch logs belong outside it.

10. Lifecycle Event Receipts (amends RFC-ACDP-0013, NORMATIVE) (0.5.0, Draft; §10.3 consumer verification Final)

10.1 Issuance

A registry that advertises both acdp-registry-lifecycle and acdp-registry-receipts, and declares acdp_version ≥ 0.5.0, MUST mint an event receipt when it appends any lifecycle event: producer-initiated (RFC-ACDP-0013 §6) or registry-initiated. The receipt is minted atomically with the append.

{
  "receipt_type": "acdp-event-receipt/1",
  "registry_did": "did:web:registry.example.com",
  "ctx_id": "acdp://registry.example.com/12345678-1234-4321-8123-123456781234",
  "event_id": "018f6d0a-7b2e-7c4d-9e1f-3a5b7c9d1e2f",
  "event_hash": "sha256:…",
  "index": 0,
  "accepted_at": "2026-07-04T09:15:43.120Z",
  "signature": { "algorithm": "ed25519", "key_id": "did:web:registry.example.com#receipt-key-1", "value": "…" }
}

The members are:

• event_hash: sha256: + hex(SHA-256(JCS(the event, including its signature))). It binds the exact event object as stored.
• index: the event's zero-based position in lifecycle_events.
• accepted_at: the registry's clock when it accepted the event. The registry MUST NOT backdate it; it MUST be ≥ the accepted_at of the event at index - 1, and ≥ the context's created_at.
• signature: under the RFC-ACDP-0010 §5 construction, verbatim, with the receipt signing key. The preimage is the JCS canonicalization of the object minus signature.

The object is closed (acdp-event-receipt.schema.json).

10.2 Serving

The registry serves event receipts in registry_state.event_receipts, an array parallel to lifecycle_events: element i is the receipt for event i. A registry bound by §10.1 MUST include event_receipts wherever it serves lifecycle_events.

The array is append-only under the same discipline as lifecycle_events (RFC-ACDP-0013 §4.1). An idempotent retry (RFC-ACDP-0013 §6) returns the receipt already minted. It MUST NOT mint a second one.

10.3 Verification

A consumer verifies event receipt i against event i:

1. The schema validates and receipt_type matches.
2. registry_did is did:web:<authority>, where <authority> equals the context's origin_registry.
3. ctx_id equals the context's ctx_id.
4. event_id equals the event's event_id.
5. index equals i.
6. event_hash recomputes.
7. The signature verifies under a key in the registry DID document's verificationMethod, chosen per §6.2. The RFC-ACDP-0010 §9 receipt-key lifecycle applies.
8. accepted_at is non-decreasing in i, compared over the receipts that pass steps 1–7 and 9. A receipt failing any of those is treated as absent first and takes no part in this comparison.
9. accepted_at ≥ the context's created_at.

A receipt that fails any step is treated as absent. Step 8 failing on any pair makes the context's retraction stage invalid (§7.8).

10.4 What this fixes

An event receipt gives a lifecycle event a provable evidence time (§5.1). With it, as-of retraction state has a meaning. Without it, occurred_at is a claim by the actor and array order carries no clock, so as-of retraction state is unknown under the default require_attested_events: true.

11. Receipts on Lineage Members (amends RFC-ACDP-0004 §5.1, NORMATIVE) (0.5.0, Draft)

A registry that advertises acdp-registry-receipts and declares acdp_version ≥ 0.5.0 MUST include registry_receipt in every member of GET /lineages/{lineage_id}, exactly as in full retrieval (RFC-ACDP-0004 §2.1).

A consumer folding a key-revocation lineage (RFC-ACDP-0014 §7), or an exporter (§4.3), then needs one request instead of one per member. The RFC-ACDP-0014 §8 re-retrieve-by-ctx_id path remains the fallback for registries below 0.5.0.

12. Reserved: event leaves in the transparency log (NON-NORMATIVE)

A future amendment to RFC-ACDP-0012 MAY add a leaf kind that binds an event receipt's hash. That would make lifecycle events visible to log auditors as publishes already are. It is deliberately not specified here: the as-of semantics of this document depend only on §10. It is recorded in RFC-ACDP-0009 terms as deferred, for this reason: a leaf-format change regenerates the log-* goldens and should travel with its own fixtures.

13. Profile and Capabilities

• Profile. acdp-consumer-chain, registered in registries/profiles.md, with prerequisite acdp-consumer. It is OPTIONAL. Claiming it commits a consumer to:
  • §4 bundle handling;
  • §6 walk determinism;
  • the §7 stages;
  • the §8 aggregation;
  • the §9 verdict and digests.
• Registries. The §10 and §11 obligations bind registries through acdp_version ≥ 0.5.0 together with their existing profiles. There is no new registry profile and no new capability field.
• Errors. None. Chain verification is consumer-side and has no wire surface beyond §10 and §11.

14. Conformance Fixtures

chain-001, chain-002, chain-003 and chain-010 scenario A, and every vector of chain-011, carry known-answer vectors: a pinned bundle (examples/evidence/), a pinned verdict (examples/chain-verdict/) and their evidence_digest, as_of_digest and verdict_digest. scripts/conformance-runner.py recomputes the three digests and the as-of projection, and make json-validate validates both files against their schemas. A conformant implementation MUST reproduce each pinned verdict byte for byte from the pinned bundle and options. The chain-001..010 known answers come from the first implementation (acdp-rs acdp-chain). The chain-011 known answers are verdicts that acdp-rs and acdp-verifier-py each produced byte-identically from the same bundles. Every other scenario is behavioral.

15. Security Considerations

• Bundles are adversarial input. Size limits matter. Verifiers SHOULD bound the bundle byte size and the number of snapshots per DID, and MUST apply the §6.1 walk limits regardless of how many contexts the bundle carries.
• observed is the weak point, and it is labelled. A DID document has no signature and no history, so ACDP cannot prove what a did:web document said at T. Whoever produced the bundle can fabricate a snapshot dated ≤ T. Mitigations:
  • the observed caveat;
  • pinning by a party that actually witnessed the snapshot (§6.3);
  • did:key producers, whose keys are self.
• Backdating is reported, not believed. occurred_at never orders anything (RFC-ACDP-0013 §4.1). §10 gives events a registry-attested clock. A registry that backdates accepted_at is caught by the §10.1 monotonicity rule only relative to its own earlier receipts. The transparency-log leaf kind reserved in §12 would close the rest of that gap.
• No wall clock. A verifier that substitutes its own clock for the horizon makes verdicts depend on when they are computed. That breaks §9.3, and with it the auditor's ability to recompute.

16. References

• RFC-ACDP-0001 §5.3, §5.6, §5.7, §5.8, §5.11 — time, lineage, content hash, signature, key resolution
• RFC-ACDP-0004 §2.1, §5.1 — retrieval, lineage listing
• RFC-ACDP-0006 §4.1 — traversal controls, partial-walk reporting
• RFC-ACDP-0010 §5, §8, §9, §10 — receipt construction, verification, key lifecycle, historical keys
• RFC-ACDP-0012 §9 — log verification
• RFC-ACDP-0013 §4–§8 — lifecycle events and retraction
• RFC-ACDP-0014 §7–§9 — revocation semantics, discovery
• RFC-ACDP-0015 §8 — witness cosignature verification
• [RFC 8785] JSON Canonicalization Scheme
• [RFC 2119], [RFC 8174]