QA: PresaleCharmBeneficiaryRegistry + split boost/vesting deploy (tests & docs) #202
Labels
No labels
agent:fix_bugfix
agent:fix_conflicts
agent:fix_security
agent:gap_analysis
agent:implement
agent:open_issues
agents
agent:security_audit
agent:verify
area
timecurve
arena
arena-v2
audit
block:feature_review
block:security
bug
contracts
design
devops
docs
documentation
enhancement
epic
feature
frontend
indexer
low priority
megaeth
operations
ops
performance
QA
qa checklist
referrals
removal
security
smart-contracts
tech-debt
testing
time-arena
timecurve
visual-qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
code/yieldomega#202
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?
Summary
Follow-up QA for presale CHARM +15% split from
DoubPresaleVesting: newPresaleCharmBeneficiaryRegistry,DeployProduction/deploy-megaeth-contracts.shwiring (registry preferred onTimeCurvewhen both deploy), frontend env for the header badge, and related docs.Scope (what changed)
New onchain
contracts/src/vesting/PresaleCharmBeneficiaryRegistry.sol— immutableIDoubPresaleBeneficiaryset forTimeCurve.isBeneficiarypath.contracts/test/PresaleCharmBeneficiaryRegistry.t.sol— unit tests.Changed onchain / scripts
contracts/script/DeployProduction.s.sol— may deploy registry + vesting in one run;setDoubPresaleVesting→ registry if non-zero, else vesting.contracts/script/export_abi_hashes.sh— includesPresaleCharmBeneficiaryRegistryABI hash.scripts/deploy-megaeth-contracts.sh— MegaETH 4326 defaults forPRESALE_CHARM_BOOST_ADDRESSESandPRESALE_BENEFICIARIES(first vesting slot0x0965…, boost list unchanged with0xA5F4…first).Frontend
frontend/src/layout/TimecurvePresaleCharmHeaderBadge.tsx—charmRegistry ?? vestingforisBeneficiaryreads.frontend/src/lib/addresses.ts,frontend/src/vite-env.d.ts,frontend/.env.example—VITE_PRESALE_CHARM_BENEFICIARY_REGISTRY.Docs (non-exhaustive)
docs/operations/deployment-guide.mdcontracts/PARAMETERS.md,docs/frontend/presale-vesting.md,docs/frontend/timecurve-views.md,docs/product/primitives.md,docs/testing/invariants-and-business-logic.mdcontracts/src/TimeCurve.sol,contracts/src/interfaces/IDoubPresaleBeneficiary.sol(NatSpec / comments)Checklist — tests
cd contracts && forge test --match-contract PresaleCharmBeneficiaryRegistrycd contracts && forge test --match-test presale(TimeCurve.t.sol+DoubPresaleVestingcanonical total test )cd contracts && forge build(full compile after any follow-up edits)DeployProductiondry-run with bothPRESALE_CHARM_BOOST_ADDRESSESandPRESALE_BENEFICIARIESset; assertTimeCurve.doubPresaleVesting()equals registry address when registry deployed.bash contracts/script/export_abi_hashes.shcompletes exit 0 (avoid| headwithout SIGPIPE handling in CI snippets).Checklist — docs & runbooks
deployment-guide: export blocks, “registry vs vesting” wiring,VITE_*lines matchscripts/deploy-megaeth-contracts.shecho output.PARAMETERS.md/invariants-and-business-logic.md(INV-TC-PRESALE-CHARM-BOOST) stay aligned withTimeCurve+ registry behavior.presale-vesting.md/timecurve-views.md: header badge precedence (registry first when both env vars set) matches implementation.Checklist — frontend / manual
VITE_PRESALE_CHARM_BENEFICIARY_REGISTRY+VITE_DOUB_PRESALE_VESTING_ADDRESSfrom a test registry; confirm/timecurvebadge for a boost wallet; confirm/vestingonly for vesting proxy.docs/testing/manual-qa-checklists.mdif any new steps belong under presale / deploy verification.Notes
TimeCurve.doubPresaleVestingname is historical; value may be the registry address when boost list is split from vesting allocations.mentioned in commit d5c16b192e919ec962fdf9b042ac7486bc498cb8
Agent delivery (merged to
main)Implemented the GitLab #202 QA scope:
PresaleCharmBeneficiaryRegistry(immutable `isBeneficiary` set for +15% CHARM weight), `DeployProduction` / `deploy-megaeth-contracts.sh` wiring (TimeCurve `setDoubPresaleVesting` → registry when deployed), frontend `VITE_PRESALE_CHARM_BENEFICIARY_REGISTRY` + header badge registry-first when both env vars are set, and docs (deployment guide, PARAMETERS, primitives, presale-vesting, timecurve-views, `INV-TC-PRESALE-CHARM-BOOST` + Forge map).Contributor / QA checklist (please tick)
Merge: `d5c16b1` on `main` (pushed to `origin/main`).
@brouie — could you verify the checklist above on your side when you have a moment? Leaving this issue open until you sign off. Thanks!
mentioned in commit
dc6d5202bbmentioned in issue #207
marked the checklist item cd contracts && forge test --match-contract PresaleCharmBeneficiaryRegistry as completed
marked the checklist item cd contracts && forge test --match-test presale ( TimeCurve.t.sol + DoubPresaleVesting canonical total test ) as completed
marked the checklist item cd contracts && forge build (full compile after any follow-up edits) as completed
marked the checklist item bash contracts/script/export_abi_hashes.sh completes exit 0 (avoid | head without SIGPIPE handling in CI snippets). as completed
marked the checklist item deployment-guide: export blocks, “registry vs vesting” wiring, VITE_* lines match scripts/deploy-megaeth-contracts.sh echo output. as completed
marked the checklist item PARAMETERS.md / invariants-and-business-logic.md
INV\-TC\-PRESALE\-CHARM\-BOOSTstay aligned with TimeCurve + registry behavior. as completedmarked the checklist item presale-vesting.md / timecurve-views.md: header badge precedence
registry first when both env vars setmatches implementation. as completedmarked the checklist item Update docs/testing/manual-qa-checklists.md if any new steps belong under presale / deploy verification. as completed
marked the checklist item Build with VITE_PRESALE_CHARM_BENEFICIARY_REGISTRY + VITE_DOUB_PRESALE_VESTING_ADDRESS from a test registry; confirm /timecurve badge for a boost wallet; confirm /vesting only for vesting proxy. as completed
marked the checklist item Optional: fork or scripted DeployProduction dry-run with both PRESALE_CHARM_BOOST_ADDRESSES and PRESALE_BENEFICIARIES set; assert TimeCurve.doubPresaleVesting() equals registry address when registry deployed. as completed
Walked the checklist on
cd1be21. Everything signs off — opening the verification details inline for the record.Forge tests
forge test --match-contract PresaleCharmBeneficiaryRegistry— 4/4 PASS (test_membership + 3 revert paths: empty, zero_account, duplicate).forge test --match-test presale— 5/5 PASS across two suites:forge build— EXIT=0 (pre-existing lint notes only — ERC20 unchecked-transfer in test files, unsafe-typecast in libraries — no #202 regressions).bash contracts/script/export_abi_hashes.sh— EXIT=0.PresaleCharmBeneficiaryRegistryABI hash present in output:3033fa3e58fb46a22ba83ac38e4987d1c99bc753afda1ba4247591062dd24f0e.Onchain registry vs vesting wiring (MegaETH prod)
Read
TimeCurve.doubPresaleVesting()on prod TimeCurve (0x1b68bb6789baeba4bd28f53c10b52dbe1ef2bf71):0x6bfe055e767bF777a963157a6AEdE2F1e3eE2107— matchesPresaleCharmBeneficiaryRegistryfromindexer/address-registry.megaeth-mainnet.jsonexactlyDoubPresaleVestingis live at0xb4128c9f52dc345ad13680973146b23f5383dda0— split deploy, as the spec intendsSpot-check the canonical boost wallet on the registry:
cast call 0x6bfe055e... "isBeneficiary(address)(bool)" 0xA5F424182E8E94c328EC6441ebf508e1cb48f8bAreturnstrue. The boost list is populated on prod.Docs cross-refs
docs/operations/deployment-guide.md— export blocks forPRESALE_CHARM_BOOST_ADDRESSES+PRESALE_BENEFICIARIES(L83, L86), registry/vesting wiring (L107, L111, L161), VITE_* lines (L271-272) align withscripts/deploy-megaeth-contracts.shecho output (L617, L620).docs/testing/invariants-and-business-logic.md—INV-TC-PRESALE-CHARM-BOOSTsection explicitly covers "the pointer may be DoubPresaleVesting (vesting + membership) or PresaleCharmBeneficiaryRegistry (membership only)" with the +15% math.contracts/PARAMETERS.md— row 72 documents the 5 canonical boost wallets, the split (0x0965...for vesting allocation,0xA5F4...for registry membership), and thesetDoubPresaleVesting → registry when deployedrule.docs/frontend/presale-vesting.md+docs/frontend/timecurve-views.md:535— both state "registry first when both env vars set". Implementation infrontend/src/layout/TimecurvePresaleCharmHeaderBadge.tsx:18-19ischarmRegistry ?? vesting— exact match.docs/testing/manual-qa-checklists.md—manual-qa-issue-202-presale-charm-registryanchor present (L657), 3 checklist items covering forge + frontend badge + deploy wrapper alignment.Frontend manual walk
Built laptop frontend with
VITE_CHAIN_ID=4326,VITE_RPC_URL=https://mainnet.megaeth.com/rpc,VITE_PRESALE_CHARM_BENEFICIARY_REGISTRY=0x6bfe055e767bf777a963157a6aede2f1e3ee2107,VITE_DOUB_PRESALE_VESTING_ADDRESS=0xb4128c9f52dc345ad13680973146b23f5383dda0. Walked the badge gate in browser:0xc46b15f4...0650(not on boost list) —/timecurve,/timecurve/arena,/timecurve/protocolall render correctly with no "Presale +15% CHARM" badge. Header showsNETWORK MEGAETH+MegaETHchain pill, no Wrong Network warning.isBeneficiaryread arg to0xA5F424182E8E94c328EC6441ebf508e1cb48f8bA(canonical boost wallet) via a local component edit. BadgePRESALE +15% CHARMrenders in the header next to the logo on/timecurve. Reverted edit, file back to main clean./vestingreads fromDoubPresaleVestingat0xb4128c9f...(correct), shows "This wallet is not in the vesting beneficiary set for this deployment" for my wallet (expected — not a vesting beneficiary). Total allocated 21,500,000 DOUB, linear duration 180 days, claims enabled = false (pre-launch state correct).All checklist items pass. Ready to close on your read.
@PlasticDigits