DC-LEDGER-13
DC derived enforcedMAINNET Shelley constants (SHELLEY_START_SLOT / SHELLEY_START_EPOCH / SHELLEY_EPOCH_LENGTH) may enter a
computation ONLY through the explicitly-named mainnet_shelley_schedule(), plus a justified allowlist.
slot_to_epoch, which applied those constants to whatever slot it was handed and so yielded a
fictitious epoch off-mainnet, is DELETED and must not return. Epoch derivation on any authoritative path
goes through the caller's EraSchedule. Exactly one allowlisted site remains --
rules::apply_epoch_boundary_full's monetary-expansion denominator (SHELLEY_EPOCH_LENGTH / 20) -- which
must carry a justification naming it mainnet-only, so the allowlist cannot grow silently.
- Source
docs/clusters/PREPROD-ENTRY-AUTHORITY/SLICE-P5-epoch-agreement-and-venue-constant-containment.md
- Introduced in
- PREPROD-ENTRY-AUTHORITY-P5
Enforcement trace
Tests 4
- mainnet_epoch_at_shelley_start
- mainnet_epoch_mid_epoch
- mainnet_epoch_allegra
- mainnet_epoch_pre_shelley
Cross-references
Evidence notes
P3 established this containment in PROSE ('the constants can only enter a computation through an explicit, named mainnet schedule'); P5 makes it mechanical after P4 proved prose was insufficient. The gate immediately surfaced a SECOND live instance of the same bug class that P3 did not remove: apply_epoch_boundary_full still passes the mainnet 432_000/20 = 21_600 expected-blocks denominator, while the accumulator path already sources the real per-era epoch length from the era schedule. That site is deliberately NOT changed by P5 -- it is the full-ledger (track_utxo=true) path producing the mainnet reward results CE-71 / CE-3d are measured against, so altering it is a reward-semantics change rather than containment cleanup -- and is allowlisted with justification and tracked as follow-up. Negative-tested two ways: reintroducing slot_to_epoch, and using a mainnet constant in a non-allowlisted file, were each caught.