Untilum
← Back to Untilum Protocol

RFC-0005: Beacon Independence

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.

Abstract

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.

1. Principle

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.

2. What a Beacon must provide

A beacon family qualifies if it offers:

3. Adapter contract

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.

4. Verification is not optional

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).

5. Multi-beacon composition

The unlock.policy composes beacons so that no single network is load-bearing:

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.

6. Reference implementation: drand quicknet

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.

7. Security Considerations

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.

8. References

8.1. Normative

8.2. Informative

Editors’ Addresses

Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues

Revision History

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.