feat(tokens): add MU/AMD/AVGO/AMAT/LRCX/TTWO to the Base production token list

[hardyjosh]

Adds the six Base production tokens from st0x.registry base.json (Micron,
AMD, Broadcom, Applied Materials, Lam Research, Take-Two) to
LibTokenInvariants.productionTokensBase — the receipt / receipt-vault /
wrapped-vault pins — taking the Base table from 22 to 28. The Ethereum
mirror + the derived productionReceiptVaults() pick them up automatically.

Verified live on Base: all six receipt vaults owned by the token-owner Safe
and on the shared V3 authoriser; LibTokenInvariantsTest uniform owner +
authoriser pass with 28 vaults.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01VPs1hCTxusmaSeFKvoc4Kr

Summary by CodeRabbit

• New Features
  • Expanded the Base production-token inventory with six additional token instances: MU, AMD, AVGO, AMAT, LRCX, and TTWO.
  • Updated production receipt-vault discovery to include all 28 supported token entries.

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 1 minute

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: f575a0c0-f330-429f-92f4-e597792432f2

📥 Commits

Reviewing files that changed from the base of the PR and between e393e6b and 669223e.

📒 Files selected for processing (1)

• src/lib/LibTokenInvariants.sol

📝 Walkthrough

Walkthrough

LibTokenInvariants expands the Base production-token inventory from 22 to 28 entries by adding MU, AMD, AVGO, AMAT, LRCX, and TTWO token-instance triples. Derived receipt-vault documentation now reflects the 28-entry inventory.

Changes

Base production token inventory

Layer / File(s)	Summary
Expand production token inventory src/lib/LibTokenInvariants.sol	Adds six token-instance address triples, allocates 28 production tokens, populates entries 22–27, and updates receipt-vault documentation.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• S01-Issuer/st0x.deploy#120: Adds tests for decimals on production receipt and wrapped vault tokens.
• S01-Issuer/st0x.deploy#228: Refactors the same production token table and derived receipt-vault iteration.
• S01-Issuer/st0x.deploy#263: Extends the Base production token and receipt-vault inventory.

Suggested reviewers: thedavidmeister

Poem

I’m a rabbit counting tokens in a row,
Six new friends join the vault flow.
Twenty-eight now hop in line,
MU and AMD sparkle fine.
The invariant garden grows—
And every receipt vault knows!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately summarizes the main change: adding six Base production tokens to the token list.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/base-tokens-batch2

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[hardyjosh]

• feat(script): deploy the Ethereum production tokens via the deploy key, matched to Base #231 : 2 dependent PRs (#257 , #259 )
• test(parity): cross-chain deployment parity pin + scheduled CI #230
• pin(ethereum): hydrate the V4 authoriser clone address #258
• feat(deploy): Ethereum V4 authoriser clone — chain-parametric deploy script + per-chain pin selector #229
• feat(tokens): add MU/AMD/AVGO/AMAT/LRCX/TTWO to the Base production token list #265 👈 (View in Graphite)
• fix(test): assert ownership of the IN-USE production beacons per chain #266
• feat(lib): chain-aware token-owner Safe assertion #267
• fix(test): retire executed-migration simulations, repoint authoriser truth #268
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/lib/LibTokenInvariants.sol`:
- Around line 288-295: Update the assertAll documentation to describe
ownership/authoriser validation as O(number of production token instances)
external vault calls, replacing the stale O(13) count. Keep the documentation
aligned with productionTokensBase and its current 28-entry table without
hard-coding a count that can become outdated.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: baafa583-56d0-4385-8e30-e337a49917a0

📥 Commits

Reviewing files that changed from the base of the PR and between 1ce0ab8 and e393e6b.

📒 Files selected for processing (1)

• src/lib/LibTokenInvariants.sol

[thedavidmeister]

Reviewed 669223e: approve

Fresh run 29953700364 (20:05 UTC, on this head) leaves exactly one test failure: testDeployTag (0_1_8 != 0_1_16), the moving tag target no open PR owns, plus git-clean — both inherited main-red. The ReceiptVaultAuthoriserMismatch pair that failed the 13:36 run is gone.

Worth recording why, because I got this wrong first time round: that earlier failure named MU's receipt vault 0x7d89a2DF… sitting on 0x35f9fA9d… while the invariant expected 0x315b16…. I initially read it as this PR adding a token that wasn't ready. It was a stale result — MU had since been migrated onto the V4 clone. These are live-fork tests, so their verdicts expire; a six-hour-old run is not evidence about current chain state.

Verified independently before merging, rather than inferring from CI:

• All 18 addresses match ST0x-Technology/st0x.registry token-lists/base.json exactly — receipt, receipt vault and wrapped vault for all six.
• The registry holds 28 tokens, matching the new table size; these six are precisely the registry∖migration gap.
• On-chain, all six receipt vaults return owner() = STOX_TOKEN_OWNER_SAFE and authorizer() = 0x315b16faa6eE413faBCa877d3851B3818369f0cD, the uniform V4-clone target — so the uniform-owner and uniform-authoriser invariants hold for the expanded set.

The doc-comment rewrap in 669223e is mine: the last hunk left a line past the file width, and forge fmt does not reflow comments. It also served to trigger this run, since retargeting the base does not.