[eddiemessiah]

The hole, and the fix

The community RPC pages promised a USDm payment that governance set to zero, and gave lock durations that do not match the chain.

1. Payments. CGP-0218 (governance proposal 271, status EXECUTED, executed 2026-01-11) set EpochRewards.targetValidatorEpochPayment to 0 while keeping the set size and election dynamics. The docs still said providers "receive 82.19178082 USDm per day", described "USDm Rewards", and told operators to register "to be eligible for rewards". This PR states that the per-epoch USDm payment is 0, links CGP-0218, and keeps what still applies:
   • registration, lock requirements and elections are unchanged;
   • a group's ScoreManager score still scales the CELO rewards paid to its voters (EpochManager.setToProcessGroups → Election.getGroupEpochRewardsBasedOnScore(group, totalRewardsVoter, groupScore)), so the scoring and slashing sections stay;
   • the claiming commands stay, scoped to a payment allocated before CGP-0218 and not yet sent, since sendValidatorPayment still sends it.
2. Lock periods. registering-as-rpc-node.mdx said group CELO stays locked ~60 days and node CELO ~180 days. On chain the durations are 7 days (group) and 3 days (validator), 10,000 CELO each. The requirements hold for as long as the account is registered. The durations set when a validator can deregister (3 days after leaving its group) and how long a group's per-member requirement outlasts a member leaving (7 days). locked-celo.mdx and validator-groups.mdx now say "while registered", so the figures no longer read as a lock that lapses.
3. Sibling pages that still promised provider rewards or carried wrong figures:
   • operate/index.mdx, operate/operators/faq.mdx, operate/operators/public-rpc-node.mdx: per-epoch USDm payment is 0, with the CGP-0218 link.
   • operate/operators/overview.mdx: the public RPC node guide is described as "operate a public JSON-RPC endpoint (and optionally register it with the Community RPC program)" instead of "optionally earn rewards".
   • contribute-to-celo/community-rpc-nodes/how-it-works.mdx (description) and validator-rpc-faq.mdx: no provider payment.
   • learn/protocol/epoch-rewards/index.mdx: the "Community RPC providers" recipient line says their payment is 0.
   • learn/protocol/staking/validator-groups.mdx: the "180 day" group figure, the deregistrationPeriod that does not exist in the contracts, and the Group Share section (the share of validator payments is empty; the voter reward commission is a separate rate, see Judgement calls).
   • learn/protocol/staking/locked-celo.mdx: the deregistrationPeriod replaced with the Validators requirement.
   • community-rpc-node.mdx: the claim command and commission section now cover only a payment allocated before CGP-0218 and not yet sent; since CGP-0241 a group can also set a separate voter reward commission.

Pages changed (12): contribute-to-celo/community-rpc-nodes/{community-rpc-node,how-it-works,penalties,registering-as-rpc-node,validator-rpc-faq}.mdx, learn/protocol/epoch-rewards/index.mdx, learn/protocol/staking/{locked-celo,validator-groups}.mdx, operate/index.mdx, operate/operators/{faq,overview,public-rpc-node}.mdx. 33 insertions, 31 deletions; no reformatting or line-ending changes.

What this does NOT do / residual risk

• Does not touch the mechanism descriptions in operate/specification/smart-contract-updates-from-l1.mdx (mint CELO, swap to cUSD, sendValidatorPayment) or step 3 of the epoch process in learn/protocol/epoch-rewards/index.mdx ("Mints CELO and exchanges it for USDm", "Validators later claim rewards"). The mechanism still exists and runs with a target of 0.
• Does not rewrite the migration-era answers in validator-rpc-faq.mdx (:32 and :62, "rewards will eventually drop to zero for the voters and the validators") or how-it-works.mdx:28 ("Participants receive rewards for their involvement"). Both can be read as voter rewards, which still exist.
• Does not change the Score Management Committee description in penalties.mdx (members' "$2k USDm monthly", multisig powers). I could not verify its current status on chain.
• Does not name a CLI command for the voter reward commission; I have not verified one.
• Does not say anything about reinstating payments.

Judgement calls

• Scores and slashing kept. CGP-0218 changes only targetValidatorEpochPayment. Group scores still scale voter rewards in the deployed EpochManager flow.
• Two commission rates, kept apart. validatorgroup:commission sets commission, which EpochManager.sendValidatorPayment applies to validator payments only. CGP-0241 (Core Contracts Release 17, executed 2026-06-27) added a separate voterRewardCommission, applied in EpochManager._deductVoterRewardCommission and capped by maxVoterRewardCommission (100% on mainnet). The commission section and the Group Share paragraph describe the two separately rather than saying the group commission applies to voter rewards.
• Group requirement: 10,000 CELO registers a group; the group must then hold 10,000 CELO per member, at least 10,000 (getAccountLockedGoldRequirement: value × max(1, members, size within the last duration)).
• Headings edited: ## Earning rewards → ## Join the Community RPC program (public-rpc-node), ### USDm Rewards → ### USDm payments (registering), sentence case for ## How it works (penalties) and ## Running the RPC service (community-rpc-node). No inbound links to the old anchors. ### Claiming Rewards kept so #claiming-rewards still resolves.
• Relative link fixed on a line I was already editing: ./community-rpc-node#claiming-rewards → /contribute-to-celo/community-rpc-nodes/community-rpc-node#claiming-rewards (AGENTS.md section 6).
• Linked CGPs on GitHub, not the forum.

Issues

Refs: none (no issue filed).

Stacking / conflicts

Based on main at 7b8f97c, after the home/ → learn/ move, so every path is under learn/. main has since moved to c29403c; git merge-tree against it is clean. #2376 edits other operate/operators/ pages (archive-node, configuration, maintenance, monitoring, network-config, run-node), not overview.mdx, faq.mdx or public-rpc-node.mdx.

Verification evidence

All calls against Celo mainnet (42220), https://forno.celo.org.

Resolve contracts through the Registry (0x000000000000000000000000000000000000ce10, getAddressForString(string) = 0x853db323):

# EpochRewards
curl -s -X POST https://forno.celo.org -H 'content-type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x000000000000000000000000000000000000ce10","data":"0x853db3230000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000c45706f6368526577617264730000000000000000000000000000000000000000"},"latest"]}'
{"jsonrpc":"2.0","result":"0x00000000000000000000000007f007d389883622ef8d4d347b3f78007f28d8b7","id":1}

# Validators
curl -s -X POST https://forno.celo.org -H 'content-type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x000000000000000000000000000000000000ce10","data":"0x853db3230000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000a56616c696461746f727300000000000000000000000000000000000000000000"},"latest"]}'
{"jsonrpc":"2.0","result":"0x000000000000000000000000aeb865bca93ddc8f47b8e29f40c5399ce34d0c58","id":1}

Per-epoch validator payment is 0. targetValidatorEpochPayment() = 0xe185aaa8 on EpochRewards:

curl -s -X POST https://forno.celo.org -H 'content-type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x07f007d389883622ef8d4d347b3f78007f28d8b7","data":"0xe185aaa8"},"latest"]}'
{"jsonrpc":"2.0","result":"0x0000000000000000000000000000000000000000000000000000000000000000","id":1}

Voter rewards are still on. getTargetVotingYieldParameters() = 0x171af90f returns a non-zero target:

curl -s -X POST https://forno.celo.org -H 'content-type: application/json' --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x07f007d389883622ef8d4d347b3f78007f28d8b7","data":"0x171af90f"},"latest"]}'
{"jsonrpc":"2.0","result":"0x000000000000000000000000000000000000000000000002c04c381d6f13000000000000000000000000000000000000000000000000000d8d726b7177a800000000000000000000000000000000000000000000000000000000000000000000","id":1}

Lock requirements and the voter reward commission cap on Validators 0xaeb865bca93ddc8f47b8e29f40c5399ce34d0c58, read on 2026-10-08 at block 79552222:

getValidatorLockedGoldRequirements() -> (10000000000000000000000, 259200)   # 10,000 CELO, 3 days
getGroupLockedGoldRequirements()     -> (10000000000000000000000, 604800)   # 10,000 CELO, 7 days
maxVoterRewardCommission()           -> 1000000000000000000000000           # 1e24 fixed point = 100%

Contract source: celo-org/celo-monorepo master at 551bc1b6, packages/protocol/contracts-0.8/:

• governance/Validators.sol getAccountLockedGoldRequirement: returns the full validator requirement for as long as isValidator(account); for a group, value × max(1, members, size within the last duration). No time limit while registered.
• deregisterValidator: requires the validator to be out of its group and lastRemovedFromGroupTimestamp + validatorLockedGoldRequirements.duration < block.timestamp.
• deregisterValidatorGroup: requires no members and sizeHistory[1] + groupLockedGoldRequirements.duration < block.timestamp.
• common/EpochManager.sol sendValidatorPayment: splits a pending payment by the group's commission. _deductVoterRewardCommission: applies the separate voterRewardCommission, capped by maxVoterRewardCommission.

CGP-0218: https://github.com/celo-org/governance/blob/main/CGPs/cgp-0218.md (status: EXECUTED, proposal 271, executed 2026-01-11; its only transaction is EpochRewards.setTargetValidatorEpochPayment(0)).
CGP-0241: https://github.com/celo-org/governance/blob/main/CGPs/cgp-0241.md (status: EXECUTED, proposal 296, executed 2026-06-27; Core Contracts Release 17, which adds the voter reward commission and calls setMaxVoterRewardCommission(1e24)).

Greps after the change:

grep -rn --include='*.mdx' "82\.19" .                                    # only an unrelated enode IP in operate/operators/network-config.mdx:78
grep -rn --include='*.mdx' -i "180 day" .                                 # no matches
grep -rn --include='*.mdx' -i "60 day" .                                  # no matches
grep -rn --include='*.mdx' "optionally earn rewards\|must be claimed" .   # no matches
git diff --check                                                          # clean

Local preview (mint dev at 88ccd32): the four pages changed in the latest commit (/operate/operators/overview, /contribute-to-celo/community-rpc-nodes/community-rpc-node, /learn/protocol/staking/locked-celo, /learn/protocol/staking/validator-groups) return 200, show the new text, and no longer contain the old text. In the browser at 1280px and 412px: no horizontal overflow on any page (scrollWidth ≤ viewport width), 0 console errors. Checked through the DOM; no screenshots.

mint broken-links: on Windows the CLI flags every root-relative link, so the absolute count is noise. PR head: 583; base 7b8f97c: 575. All 8 extra entries are in files this PR does not touch (operate/specification/{deployments,native-bridge,transaction-fees}.mdx, learn/protocol/transactions/overview.mdx, learn/protocol/epoch-rewards/carbon-offsetting-fund.mdx), and no entry differs for any changed file. scripts/check-orphans.sh was not run because it needs jq, which is not installed here; no pages were added, moved or removed. CI's mint broken-links is the check of record.

Remaining ops steps

• none

Checklist

• Title is the commit message I want on main
• Ships the test that fails on pre-fix code — n/a, docs only
• Covers the seam — n/a, docs only
• Error responses audited — n/a
• Judgement calls / bundled product changes flagged above
• Previewed locally at 1280px and 412px, 0 console errors
• Re-read acceptance criteria of every Closes issue — no issue
• Development sidebar links match Closes/Refs above — none
• README / runbook / examples updated for the world this creates
• Lockfile touched — no
• Wallet/provider tree touched — no
• UI touched — no
• Money/security path — no
• No secrets in the diff

🤖 Generated with Claude Code

[GigaHierz]

head 1b031a9 · PR head re-fetched and equal to headRefOid; PR is 1 commit behind main (a12466b, home/ to learn/ move) and git merge-tree CONFLICTS in registering-as-rpc-node.mdx; on a trial merge (conflict resolved by hand) mint broken-links --check-redirects and check-orphans.sh pass, mint dev on port 3461 clean at 1280 and 412 on all six changed pages; CGP-0218 and the lock durations re-derived on chain

Verdict: REQUEST-CHANGES

Hi, and thank you for this PR. The core of it is right: I re-derived the CGP-0218 claim and the 7-day and 3-day durations from the chain myself, and your swapped-trigger fix is a good catch. The findings below are one round of targeted fixes, not a rethink. One of them is a merge conflict, which is not your fault: the home/ to learn/ move landed after you branched.

Findings (severity order)

1. Medium · contribute-to-celo/community-rpc-nodes/registering-as-rpc-node.mdx:81 (and :26, which the PR did not touch)

   • Defect: "You need 10,000 CELO per member node to register a group" is not what Validators.getAccountLockedGoldRequirement computes. It returns groupLockedGoldRequirements.value * max(1, members), so an empty group registers with 10,000 CELO and each extra member raises the requirement by 10,000 (1 member 10,000, 5 members 50,000).
   • Failure scenario: a reader preparing to register a group reads "per member node to register" and either locks 50,000 CELO up front or believes they cannot register until member nodes exist. The command a few lines below locks 10000e18 for the group, which contradicts the sentence. The PR body says this matches the Staking Requirements list at :26, but that list carries the same imprecision, so the PR copies it rather than fixing it.
   • Fix shape: "You need 10,000 CELO to register a group. The group must then hold 10,000 CELO for each member, so a group with five members needs 50,000 CELO." Fix the bullet at :26 the same way.

2. Medium · home/protocol/staking/validator-groups.mdx:38 (learn/ after rebase) vs the new line 66, and home/protocol/staking/locked-celo.mdx:58

   • Defect: the page you edited still says an account's Locked CELO is held "for up to a deregistrationPeriod after it is deregistered". deregistrationPeriod does not exist in the deployed Validators implementation (0x13b0b89f3242f815c1fc6c9cf56e1ab5aea4dc58, verified source on Blockscout) or in Validators.sol on master. The requirement runs before deregistration, not after, which is what your new line 66 and the registering page now say.
   • Failure scenario: one page gives two incompatible rules for when a group operator can free their CELO, and locked-celo.mdx:58 repeats the phantom period. A reader or AI assistant that retrieves either chunk gets a different answer from your new sentence.
   • Fix shape: rewrite :38 as "While an account has a registered validator group, unlock fails if it would leave less than the group requirement (10,000 CELO per member, held for 7 days after a member leaves)." Drop the deregistrationPeriod clause in locked-celo.mdx:58 and describe the Validators requirement instead.

3. Medium · registering-as-rpc-node.mdx:81 and :99; validator-groups.mdx:66

   • Defect: each corrected sentence answers "when do I get my CELO back" with the deregistration condition only. LockedGold.unlockingPeriod() is 259200 s (3 days) on mainnet, and unlock then withdraw is still required after deregistering (locked-celo.mdx:30 documents it).
   • Failure scenario: an operator reads "the node can deregister 3 days after it leaves its group" and plans to have the CELO liquid on day 3. The real path is 3 days to deregister plus a 3-day unlocking period, 6 days minimum for a validator. For a group, 7 days after the last member leaves, then the 3-day unlocking period. The old "~180 days" text at least implied a long wait.
   • Fix shape: add one clause to each: "After deregistering, unlock the CELO and wait the 3-day unlocking period before you can withdraw." Check the anchor by hand; mint broken-links does not validate anchors.

4. Medium (merge blocker) · registering-as-rpc-node.mdx:326-332 conflicts with main

   • Defect: #2367 changed the link in the old "USDm Rewards" paragraph to /learn/protocol/epoch-rewards/index; the PR rewrote the same paragraph with /home/protocol/epoch-rewards/index. Auto-merge conflicts and GitHub reports mergeStateStatus DIRTY.
   • Failure scenario: the PR cannot merge as-is, and a careless resolution that takes the PR side reintroduces a /home/ link that now only resolves through a redirect.
   • Fix shape: rebase on main, keep your new paragraph, and use /learn/protocol/epoch-rewards/index. The validator-groups.mdx one-liner follows the rename automatically and merges cleanly into learn/protocol/staking/validator-groups.mdx.

5. Medium · deferred siblings with no issue filed (contribute-to-celo/community-rpc-nodes/validator-rpc-faq.mdx:47, operate/index.mdx:87, community-rpc-nodes/how-it-works.mdx:3, validator-groups.mdx "Group share" section, home/protocol/epoch-rewards/index.mdx:19)

   • Defect: after this PR these still contradict the new "payment is 0" statement. validator-rpc-faq.mdx:47 says "Rewards are limited to validators who register as a community RPC provider"; operate/index.mdx:87 says the node "earns rewards"; how-it-works.mdx's description says providers are "rewarded"; epoch-rewards/index.mdx:19 lists community RPC providers as recipients. The PR body defers some of these and says "Refs # (none filed)".
   • Failure scenario: an operator lands on operate/index.mdx or the FAQ, reads "earns rewards", registers, and never reaches the pages that say the payment is 0. On a page set about whether operators get paid, an unresolved contradiction is the core defect class. Under the repo review rules a deferred item needs a filed, linked issue, otherwise it stays open.
   • Fix shape: either fix the one-clause statements in this PR (operate/index.mdx:87 and the FAQ answer) or file one follow-up issue listing the locations and link it in the PR body. Also, the validator-groups "Group share" section says groups are paid from validator rewards. With payment 0 that is empty, but the group still earns commission on voter rewards (EpochManager emits VoterRewardCommissionDistributed and releases CELO to the group), so one clause there would keep it accurate.

6. Low · contribute-to-celo/community-rpc-nodes/penalties.mdx:15

   • Defect: the PR rewrites the paragraph under ## How It Works but leaves it in Title Case; AGENTS.md section 3 asks for sentence case on pages you are already editing. Same for ## Running the RPC Service in community-rpc-node.mdx. (### Claiming Rewards is rightly kept for its anchor.)
   • Failure scenario: style drift only, no functional break.
   • Fix shape: ## How it works, ## Running the RPC service.

7. Low · contribute-to-celo/community-rpc-nodes/community-rpc-node.mdx:3

   • Defect: the new description ends "...and claim validator payments", which advertises the payment as the page's outcome in the llms.txt hook while the body says the payment is 0.
   • Failure scenario: an agent choosing pages by description concludes there are live validator payments to claim.
   • Fix shape: "How to operate a community RPC node on Celo and meet the uptime requirement for elected providers". The claim commands stay in the body.

Verified good (reproduced from primary sources)

• CGP-0218 (celo-org/governance/CGPs/cgp-0218.md): status: EXECUTED, governance-proposal-id: 271, date-executed: 2026-01-11, title "Validator Spending Reduction - Option #3 Keep the current set, with rewards reduced to zero". Body: "This proposal aims to reduce the RPC set (formerly Validator set) rewards to 0 cUSD, while keeping the current set size and election dynamics." JSON script: EpochRewards.setTargetValidatorEpochPayment(0). The prose says Election.setTargetValidatorEpochPayment and "0 cUSD"; those are typos in the CGP, and the JSON, the on-chain event and the token (now USDm) agree with the PR. The CGP is one of three alternative options; only this one executed (proposals 269 and 270 have no execution event).
• On chain: Governance ProposalExecuted(271) in tx 0x9f8b883d0563923c536bf8f8e8ecd4e8d05e7b418d3b8cea1efa47836ac009e0, block 56217802, timestamp 1768118560 = 2026-01-11 08:02:40 UTC. The same tx emitted EpochRewards.TargetValidatorEpochPaymentSet(0). targetValidatorEpochPayment() was 82191780820000000000 at block 56217801 and is 0 now. The old 82.19178082 USDm figure was the per-epoch (daily) amount.
• Registry lookups match the PR: EpochRewards 0x07F007d389883622Ef8D4d347b3f78007f28d8b7, Validators proxy 0xaeb865bca93ddc8f47b8e29f40c5399ce34d0c58, Governance 0xD533Ca259b330c7A88f74E000a3FaEa2d63B7972, LockedGold 0x6cC083Aed9e3ebe302A6336dBC7c921C9f03349E.
• getGroupLockedGoldRequirements() = (10000e18, 604800 s = 7 days); getValidatorLockedGoldRequirements() = (10000e18, 259200 s = 3 days). Matches the PR.
• Deployed Validators source: deregisterValidatorGroup requires sizeHistory[1] + group.duration < now; _removeMember stamps sizeHistory[numMembers+1] = now, so sizeHistory[1] is stamped when the last member leaves; deregisterValidator requires lastRemovedFromGroupTimestamp + validator.duration < now. The PR's corrected triggers (group: from a member leaving; validator: from leaving its group) are right and the old text had them swapped. "Can deregister once it has had no members for 7 days" is accurate.
• "Scores still count": EpochManager.setToProcessGroups calls election.getGroupEpochRewardsBasedOnScore(group, totalRewardsVoter, groupScore). getTargetVotingYieldParameters() target is non-zero (5.075e19 on a 1e24 scale), so voter rewards still run.
• "The claim commands stay": EpochManager.sendValidatorPayment pays out validatorPendingPayments. I read 6,821.91780806 USDm still pending for the first elected account (0xd818F03476eF422BedDF720adDf5B3D3fd8353FE), so the "payment already allocated and not yet sent" sentence is not vacuous.
• Mechanical: mint broken-links --check-redirects and bash scripts/check-orphans.sh pass on the PR head and on a trial merge with main (conflict resolved by hand with the learn/ link). No emoji, promotional wording or "recently/previously/coming soon"; frontmatter keeps description, no og:description; the relative link fix is correct and #claiming-rewards still resolves.
• Rendered with mint dev --port 3461 on the trial merge: penalties, registering-as-rpc-node, community-rpc-node, learn validator-groups, operate faq and public-rpc-node all return 200, show the CGP link where expected, no horizontal scroll, zero console errors at 1280x900 and 412x915. One transient 500 on the first compile of the FAQ page did not reproduce (three clean reloads).
• CI on the PR head: GitGuardian and StepSecurity pass. The repo's "Documentation Validation" workflow is action_required (outside-contributor approval pending), so the mint broken-links check of record has not run on GitHub. I did not approve it.

What the PR got right

• It states the one fact that matters (per-epoch USDm payment is 0, with the proposal link) on every page that used to promise it, and keeps what still applies (elections, scores scaling voter rewards, slashing, claim commands) instead of deleting wholesale.
• It catches that the old lock sentences had the group and validator triggers swapped, and that the "180 day" and "60 day" figures were wrong, and fixes the sibling validator-groups line.
• The description is honest about what it did not do and includes reproducible eth_call evidence. Heading renames were grep-checked for inbound anchors.
• Small, one-clause edits; no reformatting.

Merge-order hazards

• Behind main by one commit (#2367, home/ to learn/); conflicts in registering-as-rpc-node.mdx only. The validator-groups.mdx one-liner follows the rename and merges cleanly. Rebase before merge.
• #2368 (build-on-celo/ and tooling/ to build/): the PR touches neither directory and adds no link into them, so no conflict is expected. If finding 5 is fixed in this PR, operate/index.mdx may link into build-on-celo/; use whichever path is on main at rebase time.
• contribute-to-celo/ did not move, and #claiming-rewards is stable across both moves.

[eddiemessiah]

Rebased onto main after #2367. The change that touched home/ now applies to learn/protocol/staking/validator-groups.mdx; the rest of the diff is unchanged.

[eddiemessiah]

Previewed in a local live deployment (mint dev, this branch merged with the other open docs fixes, no overlapping files) at desktop 1280px and phone 412px:

• /contribute-to-celo/community-rpc-nodes/penalties
• /contribute-to-celo/community-rpc-nodes/community-rpc-node
• /contribute-to-celo/community-rpc-nodes/registering-as-rpc-node
• /learn/protocol/staking/validator-groups
• /operate/operators/faq (the edited answer sits inside its collapsed FAQ item)
• /operate/operators/public-rpc-node

Each page returns 200 and renders the new text, with no horizontal overflow on phone, no broken images and 0 console errors.

[eddiemessiah]

Thanks Lena. All seven findings are addressed in one commit on top of the branch, head ba2b8d93. The branch is rebased onto main at 7b8f97c2 (#2368), so this was a force-with-lease push; git merge-tree --write-tree origin/main HEAD is clean.

#	Finding	Status	Where	New wording
1	"10,000 CELO per member node to register a group"	FIXED	registering-as-rpc-node.mdx:26 and :81	:81 "You need 10,000 CELO to register a group. The group must then hold 10,000 CELO for each member, so a group with five members needs 50,000 CELO." :26 "10,000 CELO to register an RPC Group; the group must then hold 10,000 CELO for each member, so a group with five members needs 50,000 CELO"
2	Phantom deregistrationPeriod	FIXED	learn/protocol/staking/validator-groups.mdx:38, learn/protocol/staking/locked-celo.mdx:58	:38 "While an account has a registered validator group, unlock fails if it would leave less than the group requirement (10,000 CELO per member, held for 7 days after a member leaves)." locked-celo :58 now reads "not needed to meet the Validators contract's stake requirement (10,000 CELO for a validator, held for 3 days after it leaves its group; 10,000 CELO per member for a validator group, held for 7 days after a member leaves)" in place of the deregistrationPeriod clause
3	Unlocking period after deregistration	FIXED	registering-as-rpc-node.mdx:81, :99; validator-groups.mdx:66	Each sentence now ends "After deregistering, unlock the CELO and wait the 3-day unlocking period before you can withdraw." The anchor is the ## Unlocking period heading at locked-celo.mdx:28; checked by hand
4	Merge conflict in registering-as-rpc-node.mdx	FIXED	registering-as-rpc-node.mdx:328	Resolved by the 14:30 rebase; the paragraph links /learn/protocol/epoch-rewards/index. #2368 then landed and touched the line next to my operate/index.mdx edit, so I rebased again and kept both (/build/tools/nodes/overview on :86, my clause on :87)
5	Sibling pages still promising rewards	FIXED (in this PR, no issue filed)	validator-rpc-faq.mdx:47, operate/index.mdx:87, how-it-works.mdx:3, learn/protocol/epoch-rewards/index.mdx:19, validator-groups.mdx:42	FAQ: "Voters for elected groups earn CELO rewards. The per-epoch USDm payment to community RPC providers is 0, set by governance in CGP-0218." operate/index: "serves a public endpoint; the per-epoch USDm payment to providers is 0, set by governance in CGP-0218." how-it-works description: "How community RPC providers are elected each epoch and which contracts run the elections". epoch-rewards: "Node operators serving the network; their per-epoch USDm payment is 0, set by governance in CGP-0218". Group share: "With the per-epoch validator payment at 0 since CGP-0218, that share of validator payments is empty, but the group still earns its commission on the CELO rewards paid to its voters."
6	Title Case headings	FIXED	penalties.mdx:15, community-rpc-node.mdx:18	## How it works, ## Running the RPC service. Slugs are unchanged. ### Claiming Rewards kept for its anchor
7	Description advertises claiming payments	FIXED	community-rpc-node.mdx:3	"How to operate a community RPC node on Celo and meet the uptime requirement for elected providers"

One clause per location; no page was rewritten. The diff is 9 files, 14 insertions, 14 deletions.

Checks on ba2b8d93:

• git merge-tree --write-tree origin/main HEAD (main = 7b8f97c2): clean.
• mint broken-links --check-redirects: on this Windows machine mint flags every root-relative link, including ones whose target exists (plain main reports found 575 broken links in 122 files, with /operate/operators/run-node among them). I ran it on main and on the PR head and diffed the output: the only differences are the five root-relative links this PR adds (the three #unlocking-period links, the /contribute-to-celo/community-rpc-nodes/penalties link and the fixed #claiming-rewards link, which replaces the old ./community-rpc-node#claiming-rewards), all with existing targets. CI's run is the check of record.
• scripts/check-orphans.sh needs jq, which is not installed here, so I ran the same logic in Node: no orphan pages (224 page files, all in docs.json navigation).
• Links and anchors in the nine touched files checked by hand (52 internal links): every target exists or is covered by a docs.json redirect; every anchor matches a heading, including #unlocking-period, #claiming-rewards, #group-share, #group-voting-caps.
• Grep across the touched pages for "per member node to register", "deregistrationPeriod", "earns rewards", "are rewarded", "How It Works", "Running the RPC Service": no hits. The one remaining "earns rewards" is locked-celo.mdx:50 about voters, which is correct.
• mint dev --port 3471, curl of each changed page: /contribute-to-celo/community-rpc-nodes/registering-as-rpc-node, /learn/protocol/staking/validator-groups, /learn/protocol/staking/locked-celo, /contribute-to-celo/community-rpc-nodes/validator-rpc-faq, /operate/index, /contribute-to-celo/community-rpc-nodes/how-it-works, /learn/protocol/epoch-rewards/index, /contribute-to-celo/community-rpc-nodes/penalties, /contribute-to-celo/community-rpc-nodes/community-rpc-node. All nine return 200 and the served HTML contains each new sentence above; deregistrationPeriod and "per member node" do not appear in the served pages.
• Playwright screenshots of the same nine pages at 1280x900 and 412x915 are saved locally; I will attach them if useful. I did not do a separate visual pass beyond confirming the pages render.

[GigaHierz]

head ba2b8d9 · local ref and API headRefOid match; PR is based on current main 7b8f97c and git merge-tree --write-tree origin/main refs/remotes/pr/2378 is clean (tree 0a14adb6); mint broken-links --check-redirects success and check-orphans.sh clean on the head; changed pages render on :3631 (all 200, new text served, 412px smoke test 0 console errors, no overflow); CGP-0218 and lock durations re-read from chain

Verdict: REQUEST-CHANGES

Hi, and thanks for the quick turnaround. Findings 1 to 4, 6 and 7 from the last round are fixed, and the unlock-path wording in particular is now accurate. Two small things are left: a stale claim on the page you were already editing, and one sibling line. I also have one precision note on the new locked-celo.mdx sentence. These are short edits.

Status of earlier findings

1. "10,000 CELO per member node to register a group": FIXED. registering-as-rpc-node.mdx:26 and :81 now say 10,000 CELO to register a group, then 10,000 CELO for each member (five members need 50,000). This matches Validators.getAccountLockedGoldRequirement (groupLockedGoldRequirements.value * max(1, members), with a sizeHistory multiplier for the last 7 days). On chain getGroupLockedGoldRequirements() = (1e22, 604800).
2. deregistrationPeriod in validator-groups.mdx and locked-celo.mdx: FIXED. grep -rn deregistrationPeriod over the PR head returns nothing in the content tree; validator-groups.mdx:38 and locked-celo.mdx:58 now describe the Validators requirement. (See new finding 2 for a precision note on the locked-celo.mdx wording.)
3. Missing 3-day unlocking period: FIXED. registering-as-rpc-node.mdx:81, :99 and validator-groups.mdx:66 each end with "After deregistering, unlock the CELO and wait the 3-day unlocking period before you can withdraw". LockedGold.unlockingPeriod() = 259200 on chain. The anchor /learn/protocol/staking/locked-celo#unlocking-period exists (## Unlocking period, locked-celo.mdx:28), checked by hand, and the rendered page carries the link.
4. Merge conflict: FIXED. The PR is now based on current main (merge-base = origin/main 7b8f97c); git merge-tree is clean. /learn/protocol/epoch-rewards/index is used.
5. Stale sibling pages: PARTLY FIXED. Fixed in this PR: validator-rpc-faq.mdx:47, operate/index.mdx:87, how-it-works.mdx:3, learn/protocol/epoch-rewards/index.mdx:19, the "Group share" section at validator-groups.mdx:42, and operate/operators/faq.mdx and public-rpc-node.mdx. I withdraw my earlier mention of how-it-works.mdx:28 ("Earn rewards"): it is about voters, who still earn CELO. Still open: operate/operators/overview.mdx:40 (see new finding 1). No follow-up issue is needed once that line is fixed.
6. Title Case headings: FIXED. penalties.mdx:15 is ## How it works; community-rpc-node.mdx:18 is ## Running the RPC service. ### Claiming Rewards kept, so #claiming-rewards resolves.
7. Description advertises payments: FIXED. community-rpc-node.mdx:3 now reads "...meet the uptime requirement for elected providers".

New findings

1. Medium · operate/operators/overview.mdx:40 (not touched by the PR) and contribute-to-celo/community-rpc-nodes/community-rpc-node.mdx:28, :54

   • Defect: three lines still describe a payment the PR says is 0. overview.mdx:40 lists the public RPC node page as a way to "optionally earn rewards", next to the public-rpc-node.mdx section you retitled. community-rpc-node.mdx:28 reads "Validator rewards for RPC nodes must be claimed, which is possible anytime after allocation", directly under your new "payment is 0" paragraph, and :54 says "Validator rewards distribution is affected by the validator group's commission rate ... the entire reward goes to the validator group".
   • Failure scenario: an operator or an assistant that retrieves only the operate overview, or only the "Claiming Rewards" / "Group Commission Settings" chunk, concludes there are rewards to earn, claim and tune a commission for. This is the contradiction the PR exists to remove.
   • Fix shape: overview.mdx:40: "operate a public JSON-RPC endpoint (and optionally register it with the Community RPC program)". community-rpc-node.mdx:28: "If a payment was allocated before CGP-0218 and not yet sent, claim it with this CLI command:". :54: "Group commission applies to the CELO rewards paid to voters, and to any payment allocated before CGP-0218 and not yet sent."

2. Low · learn/protocol/staking/locked-celo.mdx:58 (and registering-as-rpc-node.mdx:99, validator-groups.mdx:38)

   • Defect: "10,000 CELO for a validator, held for 3 days after it leaves its group" reads as if the requirement lapses at day 3. In Validators.getAccountLockedGoldRequirement a registered validator needs 10,000 CELO for as long as it is registered; the 3 days only gate when deregisterValidator succeeds (lastRemovedFromGroupTimestamp + duration < now). The same applies to the base 10,000 CELO for a group, which stays until deregisterValidatorGroup; and an empty group needs 10,000, not "per member" zero.
   • Failure scenario: a validator leaves its group, waits 3 days, calls unlock and it reverts with the requirement still in force because the node has not deregistered.
   • Fix shape: in locked-celo.mdx:58: "10,000 CELO for a validator while it is registered, which it can end 3 days after it leaves its group; for a validator group, 10,000 CELO per member (at least 10,000) while registered and for 7 days after a member leaves". Apply the same "while registered" framing at validator-groups.mdx:38. registering-as-rpc-node.mdx:99 is already right ("stays locked while the node is registered").

Verified good

• CGP-0218 is governance proposal 271. ProposalExecuted(271) (topic 0x...10f) from the Governance contract in tx 0x9f8b883d0563923c536bf8f8e8ecd4e8d05e7b418d3b8cea1efa47836ac009e0, block 56217802, timestamp 1768118560 = 2026-01-11 08:02:40 UTC. EpochRewards.targetValidatorEpochPayment() on 0x07F007d389883622Ef8D4d347b3f78007f28d8b7 returns 0 now.
• Validators proxy 0xaEb865bCa93DdC8F47b8e29F40C5399cE34d0C58: group requirement (1e22, 7 days), validator requirement (1e22, 3 days); LockedGold 0x6cC083Aed9e3ebe302A6336dBC7c921C9f03349E unlockingPeriod() = 259200 (3 days). getAccountLockedGoldRequirement of a registered validator account returns 1e22. Source (Validators.sol on master): the validator duration runs from leaving the group, the group duration from a member leaving.
• The new "Group share" sentence is accurate: the group still earns commission on voter rewards.
• Mechanics: mint broken-links --check-redirects reports "success no broken links found"; bash scripts/check-orphans.sh reports "No orphan pages found." git merge-tree clean.
• AGENTS.md: frontmatter keeps description, no og:description; the edited headings are sentence case; links are root-relative (the old ./community-rpc-node#claiming-rewards is fixed); callouts untouched; no emoji, promotional wording, "recently" or "previously".
• Rendered with mint dev --port 3631 (smoke test): all 11 changed pages return 200 with the new text and no deregistrationPeriod; registering page at 412px has no horizontal overflow, 0 console errors, and the unlocking-period link is present.
• gh pr checks 2378: GitGuardian and StepSecurity pass. The repo's mint broken-links workflow is waiting for maintainer approval of the first-time-contributor run; I did not approve it.

What the PR got right

• It states the one fact that matters (per-epoch USDm payment is 0, with the CGP link) on every page that promised it, and keeps what still applies: elections, scores scaling voter rewards, slashing, and the claim commands for payments already allocated.
• It caught that the group and validator lock triggers were swapped, and the fix to the unlock path is accurate and linked with a working anchor.
• Addressing all seven points in one commit with a point-by-point table, plus a clean rebase, makes this a short final round.

Merge-order hazards

• None known. The PR is based on current main (7b8f97c, after #2367 and #2368) and merges cleanly. The PR touches contribute-to-celo/, operate/ and learn/protocol/, none of which moved in the last restructure steps.
• Other open PRs by this author: #2376 touches operate/operators/{archive-node,configuration,maintenance,monitoring,network-config,run-node}.mdx; the fix for finding 1 touches operate/operators/overview.mdx, which is not in that list (re-check at merge time). Use build/... paths if any link into build/ is added.
• The PR description still says the branch is based on home/ and "Refs # (none filed)"; update it to reflect the rebase and the sibling fixes so the squash message is accurate.

[eddiemessiah]

Thanks, all three are addressed in 88ccd32.

• F1: FIXED. operate/operators/overview.mdx now says "operate a public JSON-RPC endpoint (and optionally register it with the Community RPC program)". In community-rpc-node.mdx, the claim step only covers a payment allocated before CGP-0218 and not yet sent. The commission section says the group commission rate applies to that payment, and that since CGP-0241 a group can set a separate voter reward commission. On chain these are two different rates: commission covers validator payments and voterRewardCommission covers voter rewards. That is why I didn't write "group commission applies to voter rewards". In EpochManager.sol on master, sendValidatorPayment applies the group's commission from getValidatorGroup, while _deductVoterRewardCommission reads getVoterRewardCommission capped by maxVoterRewardCommission. I made the same correction to my round-one sentence in validator-groups.mdx. Happy to change the wording if you read it differently.
• F2: FIXED. locked-celo.mdx and validator-groups.mdx (lines 38 and 66) now say the requirement holds while the validator or group is registered. A validator can deregister 3 days after it leaves its group. A group needs 10,000 CELO per member (at least 10,000) while registered and for 7 days after a member leaves. I checked this against Validators.sol on master (getAccountLockedGoldRequirement, deregisterValidator, deregisterValidatorGroup) and against the mainnet parameters (259200 s and 604800 s).
• Description: FIXED. It now matches the head: based on main at 7b8f97c with learn/ paths, lists the sibling pages including overview.mdx, has the Refs line, and includes the preview results (1280px and 412px, 0 console errors).

[GigaHierz]

Re-reviewed the current head: the findings from the earlier review are resolved, the diff merges cleanly into current main, and the changed claims still check out.