AI Initiative logoAI Initiative
Reading room / Manthan

INTERPRETATION — T-001

INTERPRETATION — T-001. Covers 1. Domain-separation tag version: `v1` vs `v2`; 2. Genesis trace fixed-point (`trace == id` is self-referential under hash); 3. Deterministic nonces vs SPEC §3.7 CSPRNG requirement; 4. The `rejected-lineage-cycle` verifier code.

Conformance method / historical test inventory
This is the retained source text, not a new validation of its claims. Numerical results and comparative claims require the accompanying source review before public reuse.

Read the connected case study or article →

Not explicitly stated in source · Date not established

Provenance, authorship and editorial notes

INTERPRETATION — T-001

Id

manthan-herald-protocol-test-vectors-v0-2-interpretation

Project

Manthan

Source path

manthan/herald-protocol/test-vectors/v0.2/INTERPRETATION.md

Source sha256

00b23056ff5a5b40e91180430d47002902731b02ab0d0511b7e888dc0043384b

Local copy sha256

00b23056ff5a5b40e91180430d47002902731b02ab0d0511b7e888dc0043384b

Repo head

3a94084024a3434cef331fecac91c2c3b43f0313

Date
Not recorded
Date basis

Original publication date not established; Git revision date retained separately.

Author

Not explicitly stated in source

Author basis

Unknown; Git committer not substituted for document author.

Last source commit

8b75d1b0157c20a0a463f0e31008ef9f73099beb

Last source commit date

2026-06-08T07:40:14Z

Document status

Conformance method / historical test inventory

Summary

INTERPRETATION — T-001. Covers 1. Domain-separation tag version: `v1` vs `v2`; 2. Genesis trace fixed-point (`trace == id` is self-referential under hash); 3. Deterministic nonces vs SPEC §3.7 CSPRNG requirement; 4. The `rejected-lineage-cycle` verifier code.

Topics
  • Protocol and verification
  • 1. Domain-separation tag version: `v1` vs `v2`
  • 2. Genesis trace fixed-point (`trace == id` is self-referential under hash)
  • 3. Deterministic nonces vs SPEC §3.7 CSPRNG requirement
Theme

Protocol and verification

Priority

reference

Related ids
  • manthan-herald-protocol-spec
  • manthan-herald-protocol-threats
Evidence concerns
  • Recovered source text is preserved verbatim. Assertions, comparisons, commands and results belong to its original context; they were not re-executed or externally re-verified during this corpus review.
  • Historical record: current deployment, task completion and test status must not be inferred from this date-bound document.
Word count

652

Bytes

4656

Source relative

herald-protocol/test-vectors/v0.2/INTERPRETATION.md

Remote mirror

manthan/herald-protocol/test-vectors/v0.2/INTERPRETATION.md

Full text preserved

True

INTERPRETATION — T-001

Three places where the SPEC (or the task brief) was ambiguous and a
choice had to be made. These are flagged here per AGENT_PROTOCOL.md §
"How to handle ambiguity".

1. Domain-separation tag version: v1 vs v2

Tension. The task brief states:

Signatures are over dom_sep || canonical_body, where for the origin
scope dom_sep = "herald.envelope.v1" (per [SPEC §3.6]).

But the current SPEC.md §3.6 lists:

| Role | Domain-separation tag |
|------|------------------------|
| Originating envelope | herald.envelope.v2 |

Resolution. SPEC.md is the source of truth (AGENT_PROTOCOL.md §
"Cite specifically": "read those documents as written today — do not
assume they match your training. Documents evolve.") The task brief
predates a SPEC update from v1 → v2 tags. We use herald.envelope.v2.

If a reviewer wants v1 tags for backward compatibility, regenerate by
changing DOM_SEP_ENVELOPE in generate.py and re-running. The vector
file is mechanically regenerated from a single constant.

2. Genesis trace fixed-point (trace == id is self-referential under hash)

Tension. SPEC §3.2:

Genesis envelopes: MUST set parent: null and trace: id (i.e.
self-trace).

SPEC §3.5:

id is computed as sha256(canonical_body) where canonical_body is
the CBOR-deterministic encoding of the envelope **with the id field
omitted and the signatures array replaced by an empty array**.

Since the canonical body contains trace, and on a genesis envelope
trace == id == sha256(canonical_body), the equation has no
closed-form solution: id cannot be computed without first knowing
id.

Resolution. We treat the canonical body of a genesis envelope as
having trace = null (a sentinel meaning "self-trace, value to be
filled by the recipient"). Concretely:

1. Build canonical body with parent: null and trace: null.
2. Compute id = sha256(canonical_body).
3. The wire envelope sets trace = id (display only); the canonical
bytes used for signing and id-verification keep trace = null.

A verifier receiving a genesis envelope (one whose wire parent is
null and whose wire trace equals the wire id) MUST recompute the
canonical body with trace = null before re-hashing.

This convention is the only consistent reading of §3.2 + §3.5 absent
an explicit fixed-point definition. It's worth a follow-on task to add
a paragraph to SPEC §3.5 explicitly defining the genesis convention.

Alternative considered: treat trace = id literally, computing a
fixed-point via brute force or an iterative substitution. Rejected:
no hash function admits a closed-form fixed point; brute force would
make genesis envelopes computationally expensive and non-deterministic.

3. Deterministic nonces vs SPEC §3.7 CSPRNG requirement

Tension. SPEC §3.7:

Senders MUST use a CSPRNG and MUST NOT derive nonces from ts or id.

But test vectors must regenerate byte-identically.

Resolution. Test-vector nonces are deterministically derived from a
fixed string label:

nonce = sha256(b"herald.testvector.nonce/" + label)[:16]

This is not derived from ts or id (two specifically forbidden
sources), so the prohibition's letter is not violated; the CSPRNG
requirement is. We accept the relaxation explicitly, only for test
vectors, and call it out in:

Production senders MUST use a CSPRNG. Test-vector consumers should
treat the nonces as opaque 16-byte values; their derivation is an
implementation detail of this generator, not part of the protocol.

4. The rejected-lineage-cycle verifier code

Tension. SPEC §2.3 says the verifier MUST reject lineage cycles,
but SPEC §6's enumerated return codes (valid, partial,
signature-invalid, tampered, orphaned, parent-trace-mismatch,
replayed-nonce, expired-envelope, expired-key,
deprecated-sigil, unknown-sigil, unknown-alg, clock-skew,
lineage-unverified) does not include a "lineage cycle" code.

Resolution. We surface the result as rejected-lineage-cycle
explicitly. None of the existing §6 codes fit:

A correct fix is to add a lineage-rejected (or similar) entry to
SPEC §6. Worth a follow-on task: *"Extend SPEC §6 verifier return
codes to enumerate lineage-validation failure modes."*

Continue exploring