R-209 — Time-locked attestations: cryptographic backing for HERALD's temporal envelopes

R-209 — Time-locked attestations: cryptographic backing for HERALD's temporal envelopes

Question. [CHARTER §3.2] (lines 244–303) introduces six temporal attestations — time_locked, dead_mans_switch, vow, oath, prophecy, anniversary — and [CHARTER §2.10] (line 142) and [§5.4] (line 613) point at "the Seal-Keeper" as the conduit that holds them. None of these documents specifies the cryptographic mechanism that makes "I will not say X until date Y" enforceable. This report surveys the candidate primitives — verifiable delay functions (VDFs), time-lock puzzles (TLPs), threshold time-release encryption (drand/tlock), and trusted-committee notaries — maps each to the per-attestation threat model, summarises 2026-current production maturity, and recommends what HERALD should specify, on what timeline, and what honest fallbacks remain available for v0.2-era deployment.

Why this matters. Without a specified cryptographic backing, "the Seal-Keeper" is a magic word. Some HERALD temporal attestations need cryptographic enforcement (time_locked, dead_mans_switch); others need only signed-promise semantics with reputation enforcement (vow, oath, prophecy, anniversary). Conflating the two — pretending all six attestations need the same backing — would either over-specify (locking HERALD to bleeding-edge VDF deployment) or under-specify (leaving sealed bids and dead-man's switches without a substrate). The report makes the per-attestation distinction precise.

Worker: worker-opus-2026-05-05-R209-retry

Note on a CHARTER section reference. The R-209 task brief and the prior BLOCKED.md cited "[CHARTER §3.3]" for temporal attestations. The actual section is §3.2 (lines 244–303); §3.3 (line 305) is Social attestations. This report uses the correct §3.2 reference throughout. Minor typo, flagged so a reviewer cross-checking the task brief is not confused.

0. Executive summary

The six temporal attestations split cleanly across two threat-model categories, each requiring a different cryptographic substrate:

The four promise-only attestations need no cryptographic time mechanism; they are signed envelopes whose meaning is resolved socially and through reputation. The two sealed-payload attestations are where the substrate question is real.

For the sealed-payload attestations, four candidate substrates exist:

1. Threshold time-release encryption (drand / tlock). Mature; production-deployed since March 2023; audited by Kudelski 2023; multi-language libraries. Network-dependent: requires the League of Entropy (19 nodes, Feb 2025) to remain liable. Threat model is honest threshold of committee.
2. Verifiable delay functions (Wesolowski 2018, Pietrzak 2019). Non-interactive, no committee required. 2026 status: still bleeding-edge for production sealing. Used in Chia consensus (since 2021) but not as a sealing primitive — Chia's VDF certifies elapsed time, it does not encrypt-to-the-future. ASIC speedup risk. No widely-deployed VDF-based time-release encryption library.
3. Time-lock puzzles (Rivest-Shamir-Wagner 1996; homomorphic variants Malavolta 2019). Non-interactive. 2026 status: useful for short delays (seconds-to-hours) at puzzle-construction cost; brittle against ASIC adversaries and quantum factoring.
4. Trusted Seal-Keeper(s) — operational notaries. A sigil holds the plaintext, publishes on schedule. Honest, low-tech, defensible. Requires Seal-Keeper non-collusion. Maps directly to [CHARTER §2.10] §5.4 framing.

Recommendation. HERALD should specify a layered backing in [SPEC §4 / EXT extension] in the following order of preference:

1. Default for v0.2: Trusted Seal-Keeper(s) with m-of-n quorum, plus optional drand-tlock for short-horizon (≤ 60 day) seals. This is honest about 2026 production maturity, leverages [CHARTER §2.10] directly, and does not commit HERALD to research-grade primitives.
2. Recommended for v0.3+: drand-tlock as the wire-format standard sealed-payload encoding (analogue of how SPEC chose Ed25519+HPKE rather than inventing crypto), with a pluggable scheme tag in the envelope so other backings can co-exist.
3. Reserved for v0.4+ research: VDF-based and homomorphic-TLP-based backings. Not specified now. Reserved as scheme-tag space.
4. Honest residual: post-quantum sealed-payload encryption is an open problem in 2026. Any drand-tlock-based seal HERALD ships is a quantum-vulnerable seal. The spec must say this in the threats section (analogous to how [SPEC §0] makes other crypto-agility commitments).

Per-attestation mapping recommended:

• vow, oath, prophecy, anniversary: no cryptographic time-mechanism needed. Signed envelope only. The reputation system enforces. Spec the verdict-envelope ritual for prophecy (already implied in [CHARTER §3.2] line 289).
• time_locked: drand-tlock for ≤ 60d horizons; trusted Seal-Keeper(s) with m-of-n quorum for longer. Both schemes encoded in the sealed_payload_hash field's accompanying scheme tag.
• dead_mans_switch: trusted-committee with threshold reveal (the spec's decryption_key_holder: sigil field already implies this — clarify it should be decryption_key_holders: [sigil...] with t of n reveal, and that the published key is itself an envelope). Drand-tlock is not a fit because the trigger is liveness, not absolute time.

1. Per-attestation threat-model decomposition

[CHARTER §3.2] gives six temporal attestations. The cryptographic-backing question pretends they are uniform; they are not. Each carries a different what-must-be-prevented obligation, and therefore a different substrate.

1.1 time_locked — sealed pre-commitment

Shape: { reveal_after: timestamp, sealed_payload_hash: hex }

Semantics: I will say X on date Y; here is the hash now; here is the plaintext later.

— [CHARTER §3.2] lines 248–251

What must be prevented. A third party (or the issuer) revealing the plaintext before reveal_after.

What is already prevented by HERALD's substrate. Nothing relevant — the envelope only commits to a hash. The hash binds the plaintext but the plaintext is held somewhere, and where is the unspecified part.

Substrate options ranked.

The natural HERALD wire-format encoding is:

{ "type": "time_locked",
  "value": {
    "reveal_after": 1746500000,
    "sealed_payload_hash": "0xa1b2c3...",
    "sealing_scheme": "drand-tlock-quicknet" | "seal_keeper-2of3" | ...,
    "scheme_params": { ... }
  } }

A scheme tag plus parameters keeps the wire format stable while letting the substrate evolve. This is the same crypto-agility pattern HERALD already adopted for envelope signatures.

1.2 dead_mans_switch — conditional reveal on absence

Shape: { publish_if_silent_for: duration, ciphertext: bytes, decryption_key_holder: sigil }

Semantics: If the sigil emits no envelope for the duration, a designated party reveals the key.

— [CHARTER §3.2] lines 257–260

What must be prevented.

1. The decryption-key-holder revealing prematurely (while the issuer is still alive).
2. The decryption-key-holder failing to reveal when the issuer falls silent.
3. The issuer regenerating the trigger after silencing has already begun.

What is already prevented by HERALD's substrate. Nothing — the spec gestures at "a designated party reveals" but does not say how the silence is established, how the key custody is structured, or whether the trigger is bilateral or quorate.

Substrate options ranked.

The wire-format clarification needed:

{ "type": "dead_mans_switch",
  "value": {
    "publish_if_silent_for": "P30D",
    "ciphertext": "...",
    "key_custody": {
      "scheme": "shamir-t-of-n",
      "holders": ["sigil:trustedwitness1...", "sigil:trustedwitness2...", "sigil:trustedwitness3..."],
      "threshold": 2
    },
    "liveness_attestation_kind": "envelope_published",
    "liveness_observers": ["sigil:auditor1...", ...]
  } }

The current single-sigil field is a footgun — a single committee member can either betray (reveal early) or fail (refuse to reveal). [CHARTER §3.2] line 266 should be amended to mandate t-of-n.

1.3 vow — temporally-bounded promise

Shape: { will_not: predicate, until: timestamp }

Semantics: I commit not to mention topic X until date Y. Any envelope from me about X before then is invalid.

— [CHARTER §3.2] lines 269–272

What must be prevented. Nothing cryptographically. [CHARTER §3.2] line 272 explicitly says: "The protocol does not prevent the lie; it makes it indelible."

Substrate. The signed envelope itself, plus the audit log [EXT §2]. The vow's enforcement is reputational and indelible: if the issuer breaks the vow, the broken-vow envelope and the original vow are both signed and timestamped, and any reader can detect the violation by linear scan.

No additional cryptographic substrate is needed. The temptation to over-engineer (e.g., "should we VDF-seal the vow text?") should be resisted. A vow that the issuer cannot break is no longer a vow; it is just a constraint. The literary primitive is the moral commitment that could be broken at cost.

The only protocol clarification needed: specify that will_not: predicate should be a structured-enough predicate that automated detectors can flag violations. A free-text predicate is acceptable per the CHARTER aesthetic but the SPEC should encourage machine-checkable predicates where possible.

1.4 oath — standing vow

Shape: { maintains: predicate, while_alive: true }

Semantics: A standing vow. The agent's Hippocratic clause.

— [CHARTER §3.2] lines 278–281

Same as vow, no time-mechanism. The relevant question is molting (does the oath survive a molt? See [EXT §1]). This is out-of-scope for R-209 but flagged as a follow-on note: molt and oath interact.

1.5 prophecy — self-graded prediction

Shape: { claim: string, resolves_at: timestamp }

Semantics: Self-graded prediction. After the date, the agent or a third party emits a verdict envelope linking back.

— [CHARTER §3.2] lines 287–290

What must be prevented. Nothing cryptographically. The integrity comes from: (a) the prophecy is timestamped at issuance; (b) the verdict envelope is timestamped after resolves_at; (c) Brier-score-type reputation systems compute calibration over time. This is exactly the same pattern as vow — moral commitment + reputational settlement + audit-log immutability.

Substrate. The signed envelope, plus the audit log, plus a verdict ritual that already needs spec'ing. R-209 should not invent the verdict envelope class — that is a separate spec task — but should note that the prophecy-substrate question is purely about ritual and ledger, not about time-release crypto.

1.6 anniversary — self-citation across time

Shape: { commemorates: env-id }

Semantics: Self-citation across time. I am restating this.

— [CHARTER §3.2] lines 296–299

This is a citation envelope with a temporal flavour. No time-release substrate is involved. The temporality is purely literary — the act of commemorating an old envelope on its anniversary date. Substrate: signature only.

1.7 Summary table

Two of six attestations need a sealed-payload substrate; only one of six (time_locked) needs absolute-time release. The temptation to specify VDFs as the universal temporal substrate would be over-engineering by a factor of three.

2. Cryptographic primitive survey

2.1 Verifiable Delay Functions (VDFs)

Definition. A VDF (Boneh, Bonneau, Bünz, Fisch 2018; Wesolowski 2018; Pietrzak 2019) is a function f(x) = y whose computation requires T sequential steps (parallelism does not help) but whose output y can be verified in time much less than T. The "verifiable" suffix is what distinguishes VDFs from time-lock puzzles — VDFs publish a short proof, TLPs do not.

Constructions. The two practical RSA-group constructions:

• Wesolowski 2018 ("Efficient Verifiable Delay Functions"): proof verification is constant time (independent of T), proof size is short, but verification requires a hash-to-prime function which is awkward in constrained environments (notably Solidity). Proof artefact is compact.
• Pietrzak 2019 ("Simple Verifiable Delay Functions"): proof verification is O(log T), proof size is ~λ × log T bits (≈ 40 KB at typical parameters), but verification uses only repeated squaring — easier to implement on-chain. Recent work reduces proof size to under 8 KB and verification to under 2M gas on Ethereum (arXiv:2405.06498v3, "Implementation Study of Cost-Effective Verification for Pietrzak's VDF in Ethereum Smart Contracts").

Class group constructions. The RSA-group constructions require trusted setup (RSA modulus generation), which is uncomfortable. Class groups of imaginary quadratic fields allow an analogous construction without trusted setup. This is what Chia uses in production. Chia VDF (chiavdf) is the only large-scale production deployment of class-group VDFs.

MinRoot. Khovratovich, Maller, Tyagi (2022) proposed MinRoot as a candidate Ethereum VDF — an iterative algebraic transformation over Pasta curves. Status as of 2026: not deployed. Per Vitalik Buterin's "Possible Futures of the Ethereum Protocol, part 6: The Splurge" (Oct 2024), there is "no active plan to implement [a VDF] in Ethereum at this time," and "recent results on the difficulty of constructing VDF functions suggesting that the prospect of an in-protocol VDF is receding." Public attacks against MinRoot have been published.

Lattice-based VDFs. Papercraft (eprint 2025/879) — a lattice-based VDF with implementation. Promising for post-quantum but very early in 2026.

Production deployments (2026):

• Chia Network (chiavdf): production since 2021. Proof of Time used in Chia consensus. Class-group VDF, repeated-squaring construction. Note the use is for certifying that time has elapsed, not for encrypting-to-the-future. Chia VDF is not a sealing primitive.
• VDF Alliance / Open VDF ASIC: hardware acceleration project, reaches the public with reference ASICs. Significantly: this means adversaries can also acquire faster hardware. The economic-security work of arXiv:2604.04744 ("Economic Security of VDF-Based Randomness Beacons") shows many proposed VDF delays of "a few seconds" are economically insecure under plausible adversary models.
• Ethereum: no in-protocol VDF.
• No widely-deployed VDF-based time-release encryption library as of 2026. VDFs encode "this took T sequential steps" — composing them with encryption (so that decryption requires the proof) is theoretically straightforward but no production library does it.

HERALD-relevance verdict. VDFs are a research-grade primitive for absolute-time sealing in 2026. They are honest as a future substrate but not honest as a v0.2 substrate. Specify scheme-tag space; do not normatively require.

2.2 Time-lock puzzles (TLPs)

RSW 1996. Rivest, Shamir, Wagner 1996: a puzzle (α, t, N) with solution χ = α^(2^t) mod N. Solving requires t sequential squarings; the puzzle creator (knowing φ(N)) constructs in O(log t). Plaintext is encrypted under a key derived from χ.

Limitations.

1. No verifiability. The solver computes χ but has no proof to give a third party. (TLPs are "non-verifiable" — VDFs added the verifiability suffix.)
2. ASIC-speedup vulnerability. A well-funded adversary with custom squaring hardware can solve the puzzle faster than the intended deadline.
3. Quantum vulnerability. RSA factoring breaks RSW. The puzzle becomes computable in poly-time on a sufficiently capable quantum computer.
4. Solver burden. Every recipient must solve the puzzle independently. For sealed bids in an auction with N bidders, the auctioneer must solve N puzzles.

Homomorphic TLPs (Malavolta-Thyagarajan 2019). eprint 2019/635: allows evaluation of functions f(s_1, ..., s_n) over puzzle solutions without solving each puzzle individually. The result is a single output puzzle. This addresses the auction-batching problem. Subsequent work ([Time-Lock Puzzles with Efficient Batch Solving, Eurocrypt 2024, Dujmovic-Garg-Malavolta]) further reduces batch-decryption cost.

Production deployments (2026). None. TLPs remain a research primitive. There is no equivalent of tlock for TLPs — no widely-adopted library, no production audit, no chain integration. Reference implementations exist (e.g., drummerjolev/time-lock-puzzle) but as toys, not as deployed infrastructure.

HERALD-relevance verdict. TLPs are useful for short-horizon (seconds-to-hours) sealed-payload attestations where the recipient has spare CPU cycles. They are unfit for HERALD's time_locked use cases because (a) the recipient burden is too high, (b) the ASIC adversary problem is acute for short delays, (c) no audited library exists. Do not specify TLPs in v0.2.

2.3 Threshold time-release encryption (drand / tlock)

Construction. Drake-Riad-Mehta-Yakira 2023, "tlock: practical timelock encryption from threshold BLS": the drand randomness beacon publishes a BLS signature on each round number. Identity-Based Encryption (Boneh-Franklin 2001) is used, with the round number as the identity. A ciphertext encrypted to round R can be decrypted only when the network publishes the BLS signature for round R. The decryption key is the publicly-broadcast signature.

Network status (May 2026):

• drand mainnet is the production network.
• quicknet (chainhash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971) is the current production beacon — 3-second round frequency, unchained mode (no inter-round dependency, stateless verification possible), RFC-compliant bls-unchained-g1-rfc9380 scheme. Live since 2023.
• League of Entropy (LoE): the operating consortium. As of February 2025 the consortium has 19+ active members (Cloudflare, Protocol Labs, EPFL, Filecoin Foundation, Ethereum Foundation, Kudelski Security, etc.). Threshold for the active beacon is t-of-n BLS signing — nodes must collude to predict or suppress.
• An evmnet beacon (BN254) was launched 2024 for Ethereum-compatible verification.

Audit status. The tlock scheme was audited by Kudelski Security in 2023 (report on IPFS). Findings were addressed; none of the issues put existing encrypted data at risk. The most notable was a parameter-validation bug where a reveal_after too far in the future would silently encrypt to round 1 (immediate decryption). This is a user-facing parameter validation lesson HERALD should learn from — see §4.

Library availability:

• Go: drand/tlock — reference implementation, also provides the tle CLI.
• TypeScript/JavaScript: drand/tlock-js.
• Rust: thibmeu/tlock-rs (also packages a dee CLI from Cloudflare); timoftime/tlock-rs.
• No first-party Python library. This is a HERALD-specific concern given Python's prevalence in the agent ecosystem.

Production users (2026):

• Filecoin / Randamu: TimeLock and Conditional Encryption deployed on Filecoin Virtual Machine (announced June 2, 2025). On-chain sealed-bid auctions (drand blog 2025-03-04).
• Cloudflare / various MEV-mitigation experiments.
• timevault: drand's own time-locked vulnerability disclosure tool. Production since 2023.

Threat model.

HERALD-relevance verdict. drand-tlock is the most production-mature absolute-time sealing primitive available in 2026. It is the right wire-format default for time_locked. Its limitations (network-dependence, quantum-vulnerability, long-horizon trust) should be made explicit in [SPEC]/[THREATS].

2.4 Trusted Seal-Keeper(s) — operational notaries

Construction. A sigil (the sigil:seal_keeper, [CHARTER §2.10] line 140) holds the plaintext in escrow, watches the clock, and publishes the plaintext on schedule. A t-of-n quorum of Seal-Keepers protects against single-keeper malfeasance — t must collude to reveal early; n - t + 1 must fail to prevent reveal. Plaintext is split via Shamir secret sharing or stored encrypted with a quorum-reconstructable key.

Threat model.

Operational analogues.

• Notary public + sealed envelope: a centuries-old operational primitive. A notary stamps a sealed envelope; the envelope is held until a specified date. The cryptographic equivalent is the same primitive at higher fidelity.
• Escrow agents (legal): same structure, governed by contract law.
• Sarcophagus protocol (Web3 dead-man's switch): exactly this construction with smart-contract enforcement.

HERALD-relevance verdict. Trusted Seal-Keeper(s) are the honest baseline that HERALD already gestures at via [CHARTER §2.10] (sigil:seal_keeper) and [§5.4]. Specifying them properly — with t-of-n quorum — costs nothing in research-grade crypto and gives HERALD a working sealed-payload primitive immediately, with arbitrary-horizon trust. The scheme should be the default for v0.2 and a permitted scheme thereafter.

2.5 Other candidates surveyed but rejected

• Witness encryption. A theoretical primitive (Garg-Gentry-Sahai-Waters 2013) where a ciphertext is decryptable iff a public witness is published. Uses indistinguishability obfuscation; not practical in 2026.
• Chia's class-group VDF as a sealing primitive. Chia VDF certifies elapsed time but does not encrypt-to-the-future. A HERALD operator could use Chia's chain as a witness-of-elapsed-time but the ergonomics are worse than drand-tlock and the trust model is similar.
• Bitcoin OP_CSV / Ethereum smart-contract time-locks. Native to those chains, not a fit for HERALD's signing-and-envelope model. Useful as peer technology, not a HERALD primitive.
• Threshold homomorphic encryption (tHE). A trusted-committee variant where the committee jointly decrypts on a triggered condition. Operationally similar to trusted Seal-Keepers but with more cryptographic machinery. Reasonable choice for dead_mans_switch if one wants stronger committee-malfeasance resistance, at the cost of complexity.

3. Library and network maturity matrix

The matrix shows starkly: the only production-mature time-release crypto primitive in 2026 is drand-tlock, and the only horizon-flexible primitive is operational Seal-Keepers. Everything else is research.

4. Gotchas and lessons-from-deployment

4.1 drand-tlock parameter validation

The Kudelski 2023 audit uncovered a parameter-validation bug: a reveal_after timestamp far enough in the future computed to a drand round number that overflowed/wrapped to round 1 — making the ciphertext immediately decryptable. The lesson for HERALD: the spec must mandate parameter-range validation at envelope construction. A time_locked envelope whose reveal_after exceeds the drand chainhash's representable range MUST fail validation.

4.2 drand chainhash drift

drand has migrated through multiple chainhashes (fastnet → quicknet). A HERALD envelope sealed under fastnet is decryptable only as long as the fastnet chain is still being signed. drand has historically maintained deprecated chains for a transition window but this is operational policy, not a cryptographic guarantee.

Recommendation. [SPEC] should require that time_locked envelopes record the drand chainhash explicitly in scheme_params, and that HERALD implementations check chainhash liveness at decryption time. Long-horizon seals on a chainhash that has been deprecated by the LoE are forfeit.

4.3 Network-liveness dependency

drand is a high-availability service but not a contractual one. A HERALD deployment that depends on tlock for time_locked cannot offer better-than-drand SLAs. Operators should be honest: a HERALD time_locked sealing depends on (HERALD signing) AND (drand signing at the reveal round) — two independent failure modes.

For latency-sensitive use cases, the 3-second round frequency of quicknet is probably fine. For seconds-precision auctions, even quicknet is too slow.

4.4 LoE membership and parameter updates

The LoE consortium can — by majority vote — change parameters (threshold, curve, scheme). Such changes are coordinated with operator-side software updates. A stale client may seal to a deprecated chainhash without warning. The risk is mitigated by drand's strong communication norms but not eliminated. HERALD should pin chainhash versions and publish recommended updates analogous to TLS cipher-suite deprecation.

4.5 Trusted Seal-Keeper composition

If HERALD specifies t-of-n Seal-Keepers, the selection of n Seal-Keepers becomes a governance question. Bad compositions (n Seal-Keepers all hosted by the same provider, all using the same HSM vendor, all in the same jurisdiction) reduce the effective threshold. The same diversity-policy concerns that the threshold-attestation registry [R-204] (already done) treats apply here.

Recommendation. Reuse the [R-204] diversity-policy registry pattern for Seal-Keeper composition declaration. A time_locked envelope using Seal-Keeper sealing should reference a diversity-policy ID, exactly as a quorum attestation does.

4.6 ASIC-speedup adversary (VDF-only concern, but worth flagging)

If HERALD ever specifies a VDF-based scheme, the Economic Security of VDF-Based Randomness Beacons (arXiv:2604.04744) result applies: "many proposed VDF delays of a few seconds are economically insecure under plausible conditions." A 30-second VDF delay sealing a $1M sealed bid is a poor risk trade because an adversary can rent specialised hardware for less than $1M. Delays must be calibrated to the value at stake.

4.7 Quantum vulnerability of drand-tlock

drand-tlock relies on BLS12-381 (or BN254). A capable quantum computer breaks BLS. Any HERALD sealed payload encrypted with drand-tlock is forward-vulnerable to quantum computation. The seal is broken not at reveal_after but at whenever a CRQC arrives.

HERALD must say this in [THREATS]: long-horizon time_locked envelopes are quantum-vulnerable; for true forward-secrecy, a Seal-Keeper scheme with post-quantum key custody is the only currently-available path. Lattice-based VDFs are an aspirational future fix.

4.8 No first-party Python library for tlock

Python is the dominant language in the agent ecosystem (LangChain, autogen, crewAI, etc.). The lack of a first-party Python tlock library is a real friction. A HERALD reference implementation in Python ([T-004]) using time_locked will need to either (a) shell out to the Go tle CLI, (b) ship a Python binding for tlock-rs, or (c) implement the IBE-over-BLS scheme in pure Python (using py_ecc or similar). Each path has costs.

Recommendation. Add a follow-on TODO: Python tlock library survey or implementation (Tier 1 task).

5. Recommendations for HERALD

5.1 Per-attestation backing (normative)

5.2 Wire-format changes proposed

Add to [SPEC §4] (or a new EXT extension EXT §temporal-attestations) the canonical encoding:

{ "type": "time_locked",
  "value": {
    "reveal_after": <unix_timestamp>,
    "sealed_payload_hash": <hex>,
    "sealing": {
      "scheme": "seal-keeper-t-of-n" | "drand-tlock" | "<reserved-for-future>",
      "params": {
        // scheme-specific
      }
    }
  } }

For dead_mans_switch, replace the single decryption_key_holder: sigil with:

{ "type": "dead_mans_switch",
  "value": {
    "publish_if_silent_for": <duration>,
    "ciphertext": <bytes>,
    "key_custody": {
      "scheme": "shamir-t-of-n",
      "holders": [<sigil>, ...],
      "threshold": <int>
    },
    "liveness": {
      "kind": "envelope_published",
      "observers": [<sigil>, ...]
    }
  } }

The single-sigil field in [CHARTER §3.2] line 266 is a bug (single-point-of-failure). Recommend this be revised in the next CHARTER edit.

5.3 Reserved scheme-tag space

Reserve the following scheme tags in a HERALD scheme registry (similar to [registries/diversity-policies.md] from [R-204]):

5.4 Required threats-section additions

Add to [THREATS]:

1. Sealed-payload time-release is not immortal. A time_locked envelope's confidentiality depends on the chosen scheme's continued viability. drand-tlock seals are quantum-vulnerable. Seal-Keeper seals depend on Seal-Keeper survival.
2. Long-horizon seals are operational, not cryptographic. A 50-year time_locked envelope is a Seal-Keeper governance problem, not a crypto problem.
3. VDF seals do not exist in production-mature form (2026). HERALD's reserved scheme tags are placeholders, not implementations.
4. The Seal-Keeper is a real trust assumption. [CHARTER §2.10]'s framing is correct; HERALD should not pretend Seal-Keepers are "just a sigil." They are the trust anchor for the bulk of long-horizon seals.

5.5 Honest fallbacks for v0.2 deployment

A HERALD operator deploying in 2026 with no LoE relationship and no Seal-Keeper infrastructure can still use the temporal attestations:

• vow, oath, prophecy, anniversary — zero infrastructure required. Sign and publish.
• time_locked with horizon ≤ 60 days — zero infrastructure required if a public LoE relay (Cloudflare, Protocol Labs) is acceptable as a trust anchor for tlock.
• time_locked with horizon > 60 days OR dead_mans_switch — Seal-Keeper required. Recommend operators stand up a small 2-of-3 or 3-of-5 Seal-Keeper quorum among trusted peers, using HSM-backed key custody, governed by mutual contract.

The honest fallback for an operator who does not want any time-release crypto at all is: don't use time_locked or dead_mans_switch. The other four temporal attestations are still available.

5.6 Follow-on tasks recommended

(Bullet list for NOTES.md / [TODO.md] consideration.)

• T-NEW-A: Python tlock library survey / minimal port. Tier 1.
• T-NEW-B: Seal-Keeper reference implementation (services/the-seal-keeper/). Tier 2. Mirrors [T-122] (the Crier), [T-123] (the Mortician).
• T-NEW-C: CHARTER §3.2 amendment proposal: dead_mans_switch.decryption_key_holder (singular) → key_custody (plural with threshold). Tier 1 / Discovery.
• R-NEW-D: "Seal-Keeper composition diversity policy" — analogue of [R-204] for Seal-Keeper quorums. Tier 3.
• R-NEW-E: "Post-quantum sealed-payload encryption survey" — refresh of this report c. 2028. Tier 3.
• R-NEW-F: "verdict envelope class specification" — needed for prophecy resolution ritual. Tier 3.

6. Honest residuals

Things this report deliberately does not answer:

1. What is the right t-of-n for HERALD's recommended Seal-Keeper default? Likely 2-of-3 for individual operators, 3-of-5 for institutional. The diversity-policy work ([R-204], [R-NEW-D]) refines this.
2. Should HERALD operate its own LoE-equivalent network? Probably not — the resources required are large and the LoE already exists. But the question is real if HERALD ever needs an independent trust anchor.
3. What happens to a time_locked envelope when the issuer molts ([EXT §1])? The seal is bound to the issuer's signature at issuance. A molt does not change historical signatures. But a Seal-Keeper sealing the plaintext might itself molt. The interaction is unresolved.
4. What happens to a dead_mans_switch envelope when a key-holder molts? Per [EXT §1], the molted sigil is a different sigil. Should the dead-man's-switch envelope auto-mark its key-holder as failed? Or should the molted sigil still hold the key? This is a CHARTER question.
5. Is there a use case for time_locked envelopes with sub-second precision? drand quicknet's 3-second floor and Seal-Keeper-based schemes' minute-level precision are both too coarse for HFT-style use. Probably out of scope for the agent web.
6. Should prophecy resolution allow third-party verdicts? [CHARTER §3.2] line 289 says "the agent or a third party emits a verdict." The CHARTER is intentionally permissive; the SPEC will need to make a choice.

7. Summary

HERALD's six temporal attestations split 2:4 across sealed-payload-needing and signed-promise-only. The two sealed-payload attestations are realistically backed in 2026 by either (a) drand-tlock (mature, quantum-vulnerable, network-dependent) for short horizons, or (b) trusted Seal-Keepers (t-of-n with Shamir custody) for arbitrary horizons. VDFs and time-lock puzzles remain research primitives in 2026; HERALD should reserve scheme-tag space but not normatively require them. The four promise-only attestations need no additional substrate — the signed-envelope plus audit-log already supports them. The current [CHARTER §3.2] dead_mans_switch shape (single key-holder) is a footgun and should be revised to mandate threshold key custody.

The honest path for HERALD v0.2 is: specify Seal-Keeper(s) t-of-n as the default sealed-payload backing; specify drand-tlock as a recommended interoperable alternative for short-horizon seals; reserve scheme-tag space for VDF and TLP futures; and make the residual trust assumptions explicit in [THREATS].

References (last-checked 2026-05-05)

Primary cryptographic literature

• Boneh, Bonneau, Bünz, Fisch (2018). Verifiable Delay Functions. CRYPTO 2018. eprint 2018/601.
• Wesolowski (2018). Efficient Verifiable Delay Functions. EUROCRYPT 2019. eprint 2018/623.
• Pietrzak (2019). Simple Verifiable Delay Functions. ITCS 2019. eprint 2018/627.
• Rivest, Shamir, Wagner (1996). Time-lock Puzzles and Timed-release Crypto. MIT/LCS technical memo. PDF.
• Malavolta, Thyagarajan (2019). Homomorphic Time-Lock Puzzles and Applications. CRYPTO 2019. eprint 2019/635.
• Brakerski, Döttling, Garg, Malavolta (2019). Leveraging Linear Decryption: Rate-1 Fully-Homomorphic Encryption and Time-Lock Puzzles. TCC 2019. eprint 2019/720.
• Dujmovic, Garg, Malavolta (2024). Time-Lock Puzzles with Efficient Batch Solving. EUROCRYPT 2024.
• Drake, Riad, Mehta, Yakira (2023). tlock: Practical Timelock Encryption from Threshold BLS. eprint 2023/189.
• Boneh, Franklin (2001). Identity-Based Encryption from the Weil Pairing. CRYPTO 2001.
• Khovratovich, Maller, Tyagi (2022). MinRoot: Candidate Sequential Function for Ethereum VDF. eprint 2022/1626.
• Papercraft: Lattice-Based Verifiable Delay Function (2025). eprint 2025/879.
• Economic Security of VDF-Based Randomness Beacons: Models, Thresholds, and Design Guidelines (2026). arXiv 2604.04744.
• Implementation Study of Cost-Effective Verification for Pietrzak's VDF in Ethereum Smart Contracts (2024). arXiv 2405.06498v3.
• Boneh, Bünz, Fisch (2018). A Survey of Two Verifiable Delay Functions. Stanford PDF.

Production deployments and operational documentation

• drand documentation. docs.drand.love, last-checked 2026-05-05.
• League of Entropy. drand.love/loe/, last-checked 2026-05-05.
• drand quicknet is live (2023-10-16). docs.drand.love blog.
• drand timelock encryption mainnet announcement (2023-03-28). docs.drand.love blog.
• drand sealed-bid auction blog (2025-03-04). docs.drand.love blog.
• drand verifying quicknet on Ethereum (2025-08-26). docs.drand.love blog.
• drand Kudelski Security Assessment (2023-05-26). docs.drand.love blog, audit report on IPFS.
• drand/tlock Go library. github.com/drand/tlock, last-checked 2026-05-05.
• drand/tlock-js TypeScript library. github.com/drand/tlock-js, last-checked 2026-05-05.
• thibmeu/tlock-rs Rust library. github.com/thibmeu/tlock-rs, last-checked 2026-05-05.
• Chia-Network/chiavdf. github.com/Chia-Network/chiavdf, last-checked 2026-05-05.
• Chia-Network/Audit-Reports. github.com/Chia-Network/Audit-Reports, last-checked 2026-05-05.
• Chia Proof of Time documentation. docs.chia.net/proof-of-time, last-checked 2026-05-05.
• VDF Alliance (Open VDF ASIC). vdfalliance.org, last-checked 2026-05-05.
• Filecoin / Randamu announcement (June 2025). yahoo.com/finance writeup, last-checked 2026-05-05.
• Vitalik Buterin (Oct 2024). Possible Futures of the Ethereum Protocol, part 6: The Splurge. vitalik.eth.limo.
• EIP-7998: Turn randao_reveal into a VRF (Aug 2025). eips.ethereum.org/EIPS/eip-7998.
• Trail of Bits introduction to VDFs (2018-10-12). blog.trailofbits.com.

HERALD-internal references

• [CHARTER §2.10] (line 140–144): sigil:seal_keeper.
• [CHARTER §3.2] (lines 244–303): Temporal attestations.
• [CHARTER §5.4] (line 611–615): The Seal-Keeper conduit.
• [SPEC §3]: Envelope signing.
• [SPEC §4]: Attestation framework.
• [EXT §1]: Molt and inheritance.
• [EXT §2]: Audit log / CT.
• [registries/diversity-policies.md] (output of [R-204], done): Diversity-policy registry pattern reusable for Seal-Keeper composition.
• [research/quorum-agg.md] (output of [R-210], done): BLS / Schnorr-MuSig / Ed25519 quorum tradeoffs.
• [research/hpke-survey.md] (output of [R-202], done): HPKE library availability, relevant for sealed-payload encoding.