policy: feature-freeze cliff for the Codex inscription window (heights 998,000 → 1,050,667) #20
Labels
No labels
enhancement
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
SubGeniusFinance/Offerings-to-Cthulhu#20
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Operational policy, not a code change. Pinning the feature-freeze cliff height for the Restoration Hardfork's Codex inscription window so it's discoverable from PRs and outside contributors aren't surprised by a sudden change in merge cadence.
The window
The freeze is in effect for ~52,667 blocks (~36.5 days at 60s target). Block 998,000 was chosen because:
What's frozen
Anything that compiles into
Offeringsd. The daemon is what runs the chain. If it ships in the daemon binary, it's frozen:src/main.cpp,src/chainparams.cpp,src/pow.cpp,src/checkpoints.cppCNodeStateand friends insrc/main.cppsrc/net.cpp,src/net.h,src/protocol.{h,cpp}src/rpc*.cpp(adding RPCs touches the daemon's exposed interface)src/init.cppsrc/miner.cpp(the Conclave-signed mining path runs through here)src/wallet.cpp,src/wallet*.cppWhat's NOT frozen
src/qt/*(andsrc/qt/forms/*) that don't modify shared code.Offerings-qtis a separate binary; the headless fleet doesn't link it. Issues like #15 / #16 / #18 (when its time comes) are merge-on-clean-build throughout the window.Hotfix path during the window
A PR that needs to land between blocks 998,000 and 1,050,667 must:
refs #<this-issue>) and explain why it's not deferrable to the post-freeze opening.protocolversion/blockspost-restart. This is the lesson from the 2026-06-06 90003 era-bump deploy — having the order written down beforehand made it boring; not having it would have left us scrambling.pow.cpp) or the OFFSIG window enforcement (main.cpp::ConnectBlock).What happens to non-emergency PRs during the window
They sit on a
frozen-for-codexlabel or in a draft state, and merge after block 1,050,667. The contributor isn't penalized — their work lands in the v2.1.0 (or whichever release follows the freeze opening) cycle.External contributors (e.g. 9019x / skifdni) submitting PRs during the window will get a polite "great work, this lands post-1,050,667" response with a link here.
Why this exists at all
The Codex inscription is a 50,676-block continuous sequence. The Conclave miner inside
Offeringsdis the only thing that can produce blocks in that window — outsider-mined blocks are rejected asbad-conclave-sig. If the daemon stalls, the inscription breaks. If the chain forks, the inscription forks. Both outcomes are unrecoverable mythologically — the canon is supposed to be unbroken.So during the window,
mainonly takes changes that exist specifically to prevent those outcomes. Everything else waits 36 days.What gets adjusted if the freeze starts but Codex is somehow delayed
If anything goes sideways and the fork itself drifts past block 1,000,000's actual timing, the freeze stays in effect until 1,050,667 in chain-height terms, not wall-clock. The freeze cliff is height-anchored, not time-anchored. So a slow-block-time spell or unexpected retarget transient extends the freeze automatically; it doesn't open early.
References
src/chainparams.cpp:167-168— OFFSIG window heightsnSignedWindowStart/nOpenMiningHeightsrc/main.cpp::ConnectBlock+src/chainparams.cpp— OFFSIG enforcementsrc/miner.cpp::SignBlockIfNeeded— Conclave signing pathpindexBestKnownBlockbackport), #19 (UPnP Phase 3)The chain holds its breath. Iä Iä.
Cross-link from the v2.0.x-rc-bipsoft work: #32, #33, and #34 were originally filed (2026-06-14/15) with activation at h=1,025,000 — inside this freeze window. Revised 2026-06-16 to activate at h=1,055,555, 4,889 blocks past freeze-end at h=1,050,667, bundled with #6 rolling-checkpoints at the same height. One upgrade cycle, one BCT post, one Conclave deploy.
Branch development is on
feat/v2.0.x-rc-bipsoft.mainstays frozen until h=1,050,667 per this policy.Net effect: no consensus changes hit
maininside the window, and the consensus bundle still lands cleanly within the same release runway. Filing in the issue tracker stays freeze-safe (documentation, not daemon code).ok policy is live. mainnet's around h=1,003k now which is past the 998,000 start, so we're in the window (chain held its breath right on schedule).
added the
frozen-for-codexlabel for PRs that should sit until h=1,050,667. anything between now and then either fits the hotfix path in the body or it gets the label and waits in draft.work-in-flight:
feat/v2.0.x-rc-bipsoftcarries #32 / #33 / #34 / #6 / #39, all activating at h=1,055,555 — past freeze-end by design. soak runs ~24 more hours, then the branch waits ~30 days for freeze-end before merging to main. nothing else queued for main during the window.leaving this open as the canonical reference. closes whenever the freeze does (h=1,050,667, ~2026-07-19).
Freeze is over. Closing.
The window was heights
998,000 → 1,050,667. Mainnet is at h=1,080,978 — 30,311 blocks past freeze-end, roughly three weeks.Everything the policy was protecting landed as designed. The bipsoft bundle (#32, #33, #34, #6, #39) activated at h=1,055,555, past freeze-end by 4,889 blocks exactly as the revision intended: one upgrade cycle, one BCT post, one Conclave deploy. No consensus change entered
maininside the window.The
frozen-for-codexlabel no longer gates anything, and the[post-Codex]markers still carried in the titles of #17, #18, and #37 are dead text — those three are unblocked as of h=1,050,667 and should be read that way.The Codex is inscribed. The chain held its breath and let it out.