Status: Last Call · Date: 2026-07-17 · Editors: Untilum project — hello@untilum.com
Part of the TSP RFC series; see the series index for the Last Call window and how to comment. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals.
This document defines the Beacon abstraction that supplies the Untilum Protocol’s time factor: the four properties a qualifying randomness network must provide (B1–B4), the adapter contract, mandatory verification of every beacon value against pinned public constants regardless of source, and multi-beacon composition (anyOf/allOf) so that no single network is load-bearing. drand quicknet is specified as the reference Beacon — a replaceable implementation of the abstraction, not the abstraction itself.
The protocol’s time factor is defined against an abstraction — the Beacon — not against any network. A Beacon is any public source of unpredictable, cryptographically verifiable values released on a deterministic schedule, usable for timelock encryption. drand quicknet is the reference implementation of this abstraction (§6); it is not the abstraction.
This ordering matters: capsules outlive networks. A protocol written “against drand” dies with drand; a protocol written against Beacons treats every network — including drand — as replaceable infrastructure under one contract.
A beacon family qualifies if it offers:
R = ⌊(T − genesis) / period⌋ + 1), re-derivable by any verifier.id — unique per capsule (one lock per network)
type — beacon family
chainHash() — pinned identity of the network
roundForDate(date) -> round (B4 arithmetic; UTC epoch math)
seal(round, secret32) -> blob (B2: offline)
unseal(entry) -> secret32 (MUST verify per §4 before returning)
Validators MUST reject beacon types they do not recognize — an unknown lock that cannot be verified must fail closed, not open.
unseal MUST cryptographically verify the beacon value against the pinned public parameters before use — wherever the value came from: official API, relay, third-party mirror, permanent-storage archive, or a string a user typed in. The source is irrelevant; only the signature matters. A lying source can cause only failure, never a forged unlock (RFC-0002 §T6; critical test 4, tsp-v1.md §8.5). Implementations MUST NOT expose a way to skip this, and registry/config mechanisms MUST NOT allow substituting the pinned verification parameters (a descriptor that swaps the group key while keeping the chain hash is a key-substitution attack, not a configuration).
The unlock.policy composes beacons so that no single network is load-bearing:
anyOf — the full 32-byte secret is sealed to an equivalent instant on each beacon; any one surviving network opens. Optimizes liveness; early-opening resistance equals the weakest member.allOf — the secret is split into n-of-n XOR shares (information-theoretic), one per beacon; every network is needed. Optimizes early-opening resistance; SHOULD be paired with custodial fallbacks since one death strands the capsule. Shamir k-of-n is the planned generalization.Round-equivalence across networks with different genesis/period MUST be computed from the same target UTC instant. Beacon ids MUST be unique within a capsule.
The League of Entropy’s drand network, quicknet chain — threshold BLS on BLS12-381, unchained mode, 3-second period — is the reference Beacon and currently the only specified family. Pinned constants:
chainHash : 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971
scheme : bls-unchained-g1-rfc9380 genesis : 1692803367 period : 3
group key : 83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c
8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb
5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a
(The group public key — a 96-byte G2 point, shown here wrapped — is the Tier-0 verification anchor of RFC-0003 §2; the full normative constant table is tsp-v1.md §5.)
Sealing uses the tlock construction (IBE to the round). Only the quicknet chain above is permitted; the deprecated fastnet chain (dbd506d6…) MUST be rejected everywhere. Candidate second family: an Ethereum-based beacon — its RFC must demonstrate B1–B4 before validators may accept it.
The entire time factor rests on §4: beacon values are verified against Tier-0 pinned constants before use, wherever they came from, with no skip path. The most dangerous shortcut this document forbids is configuration-driven key substitution — a beacon descriptor that swaps the group key while keeping the chain hash is a key-substitution attack, not a configuration option. Policy choice is a security parameter (RFC-0002 §T3): anyOf bounds liveness risk but inherits the weakest member’s early-opening resistance; allOf is the reverse. The deprecated fastnet chain MUST be rejected everywhere.
../spec/tsp-v1.md — §5 normative constants, §8.5 critical tests.bls-unchained-g1-rfc9380 scheme identifier).Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues
| Date | Status | Change |
|---|---|---|
| 2026-07-07 | Draft | Initial version. |
| 2026-07-17 | Last Call | Publication pass: BCP 14 boilerplate, Abstract, Security Considerations, References, Revision History added; no normative changes. Entered Last Call per RFC-0008 §4. |