fix(chain): schedule Rex6 on the canonical mainnet and testnet hardfork schedules - #371
Conversation
…rk schedules Both networks have executed Rex6 since the published timestamps (testnet 1786330800, mainnet 1787626800; the on-chain SequencerRegistry reports v2.0.0 with minRotationDelay 21600), but block/chain.rs still pinned Rex6 as Never, so mega-evme replay applied Rex5 rules to every post-activation block. Add the Rex6 entries with the governance-seeded SequencerRegistryRex6Config, pin them in the schedule tests, and drop the stale "Rex6 is unscheduled" prose from AGENTS.md. Also correct the block/limit.rs module doc that claimed deposit DA sizes are accumulated into the block DA counter (they are skipped).
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Claude review status
🛠️ Review did not finish Attempted This round did not publish: PRIOR_FINDING_INVALID in phase compile. Anything listed below is from the last round that did. Re-run the workflow or push a new commit to try again. |
🧬 Mutation testing — ✅ PASSNothing to test — no mutants were generated on the changed lines. |
RealiCZ
added
comp:core
Codecov Report✅ All modified and coverable lines are covered by tests. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🧬 Mutation testing — ✅ PASSDiff mutation score: 100.0% (2/2 viable mutants killed)
No new test gaps introduced by this change. 🎉 |
Merging this PR will improve performance by 15.43%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ⚡ | validate_schedule |
16.8 µs | 14.6 µs | +15.43% |
Tip
Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.
Comparing cz/fix/schedule-rex6-canonical-hardforks (c70e838) with main (a39bd1e)
Footnotes
-
44 benchmarks were run, but are now archived. If they were deleted in another branch, consider rebasing to remove them from the report. Instead if they were added back, click here to restore them. ↩
…canonical-hardforks # Conflicts: # AGENTS.md # crates/mega-evm/src/block/chain.rs
flyq
left a comment
flyq
left a comment
There was a problem hiding this comment.
Code review — Rex6 canonical schedule entries
Reviewed at 2b0e97544671 · xhigh effort · 3 findings
Reviewed at 2b0e9754 (the merge of main at #362; the PR's own diff against the new base is unchanged at 3 files, +50/−16). Line numbers below are from the post-change files at that commit.
The schedule change is correct and should merge. Verified: the two timestamps and the 21600 delay match docs/spec/upgrades/overview.md:135,138 and the canonical fork registry; the new tests exercise the boundary rather than restating the entry (chain.rs:147-148, :162-163, :193-195); the committed replay fixture (replay_offline.cache.json, chain 4326 at 1780969472) sits between mainnet Rex5 and Rex6 and still resolves REX5, so no re-capture is needed; and the replay-only claim holds — hardfork_schedule has no callers in mega-reth. cargo test -p mega-evm --lib passes at the merge commit (288 passed, including all 6 block::chain tests).
One finding is worth fixing before merge; the other two are cleanup.
Inline findings
| # | Where | Finding |
|---|---|---|
| 1 | crates/mega-evm/src/block/limit.rs:112 |
New L1-posting-cost clause is unsupported and backwards |
| 2 | crates/mega-evm/src/block/chain.rs:38 |
Rex6 literals unpinned; 21600 duplicated verbatim |
| 3 | AGENTS.md:67 |
Bullet hard-codes timestamps, overstates chain.rs |
…chedules to the published timestamps, trim doc prose - one REX6_MIN_ROTATION_DELAY constant shared by both schedules - new block_executor::canonical_schedule test reads docs/spec/upgrades/overview.md and asserts every fork's testnet/mainnet activation equals the chain.rs entry (Never for N/A / unscheduled) - AGENTS.md: point at block/chain.rs instead of repeating the timestamps; scheduling is decided in the node chainspecs and mirrored here for replay tooling - limit.rs: drop the unsupported L1-posting-cost clause
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 55681e5c61
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
docs/spec/upgrades/overview.md is not part of the published crate, so the test compares only when the crate sits in the repository layout and skips (with a message) from a tarball or vendored copy.
|
Documentation Impact: This PR corrects a stale internal doc-comment in crates/mega-evm/src/block/limit.rs describing deposit-transaction DA size tracking, and the published spec page docs/spec/evm/resource-limits.md (lines 80-81) appears to say the opposite and should be checked/updated to match. resource-limits.md currently reads: Deposit transactions MUST be exempt from DA size limit checks. Their DA size MAY still be tracked for monitoring purposes. This PR's corrected comment in block/limit.rs states the opposite for the block-level counter: Deposit DA sizes are not accumulated into the block DA usage counter (post_execution_update skips them), so block_da_size_used reflects non-deposit transactions only. Verified against BlockLimiter::post_execution_update_raw, which only adds da_size when the tx is not a deposit. Since this is existing (not new) behavior, the spec's MAY still be tracked line looks like it has been inaccurate independent of this PR - worth updating for clarity, or confirming that tracked refers to something other than block_da_size_used (e.g. a separate monitoring counter) so the two descriptions are not read as contradictory. This can be addressed in this PR or a follow-up. |
3 participants
Summary
Schedule Rex6 on the canonical mainnet / testnet hardfork schedules in
block/chain.rs, somega-evme replay(which resolves the spec throughhardfork_schedule) stops applying Rex5 rules to blocks after the activation timestamps; drop the stale "Rex6 is unscheduled" prose; and fix a wrong module-doc sentence inblock/limit.rsabout deposit DA accounting.Why
Both networks have been executing Rex6 since the published timestamps — testnet
1786330800(2026-08-10), mainnet1787626800(2026-08-25); the on-chainSequencerRegistry(0x6342…0006) reportsversion() == "2.0.0"andminRotationDelay() == 21600on both. #364 published the timestamps indocs/, butchain.rsstill pinned Rex6 asNeverand a test asserted it, so every replay of a post-activation block ran the wrong spec. Consensus is unaffected (mega-reth derives forks from genesis); this is replay/tooling correctness.Found by the Fenz.AI 2026-09-02 audit (F-016 /
ME-FE-20260902-016, F-023 /ME-FE-20260902-023).Changes
block/chain.rs:Rex6entries for mainnet and testnet, each withSequencerRegistryRex6Config { rex6_min_rotation_delay: 21600 }(the governance value the operator genesis attaches; readable live viaminRotationDelay()). Module doc mentions the Rex6 params.test_mainnet_/test_testnet_schedule_resolves_specs_by_timestampandtest_schedule_dispatch_by_chain_idpin the Rex5→Rex6 boundary;test_canonical_schedules_do_not_activate_rex6_or_rex7becomestest_canonical_schedules_activate_rex6_and_pin_rex7_never(Rex6 at the published timestamps with delay 21600, Rex7 stillNever, Rex6 terminal).AGENTS.md: Rex6 is frozen and activated; the "frozen ≠ scheduled" rule stays, without naming Rex6 as the unscheduled example.block/limit.rs: module doc said deposit DA sizes are "still tracked and accumulated in block DA usage counters";post_execution_updateskips deposits, so the doc now says so.No behaviour change for any spec; no
docs/change (already published in #364).Verification
cargo test -p mega-evm --lib— 262 passedcargo test -p mega-evm --test mutation -- hardfork_schedule— 2 passedcargo clippy --workspace --lib --examples --tests --benches --all-features --locked,cargo fmt --all --check— clean