Add RKLB, and tags that can say what a token is - #42
Conversation
The list could only express "is this an ST0x wrapped token". USDC was distinguished from the equities purely by having no tag and no category, so "collateral" was a fact readers had to infer from an absence. RKLB forced the question. It is deployed and live on Base and Ethereum, owned by the token-owner Safe and wired to the production authoriser, but it is not offered: st0x.liquidity disables trading, rebalancing and recovery for it, and st0x.issuance references it only from a test fixture. Under the old schema it could only be listed as an ordinary tradeable equity or left out entirely, and it was already being left out while the oracle server resolved orders to it. Identity read from Base rather than transcribed: name, symbol and decimals are what the wrapped vault returns, so the registry-vs-chain check cannot mismatch on arrival. No ISIN: RKLB's does not appear anywhere in the org, and inventing a securities identifier is not a thing to guess at. It is the only ST0x entry without one. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe base token list version and timestamp were updated, new ChangesBase token list
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8)token-lists/base.jsonTraceback (most recent call last): 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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
token-lists/base.json (1)
1113-1120: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winMirror USDC’s
collateraltag intokenMap.The
tokensentry hastags: ["collateral"], but the correspondingtokenMapentry ends afterlogoURI. Map-based consumers will receive different metadata and may fail to classify USDC as collateral.Proposed fix
"symbol": "USDC", - "logoURI": "https://static.optimism.io/data/USDC/logo.png" + "logoURI": "https://static.optimism.io/data/USDC/logo.png", + "tags": [ + "collateral" + ]🤖 Prompt for 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. In `@token-lists/base.json` around lines 1113 - 1120, Update the tokenMap entry for USDC identified by address 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 to include the same collateral tag as its corresponding tokens entry, preserving all existing metadata.
🤖 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 `@token-lists/base.json`:
- Around line 574-578: Remove the wtRKLB entry from the live base token list in
base.json until tag-based filtering is enforced by the consumers synced through
settings.yaml. Keep it only in a separate test-only list if needed, and do not
add it to both live representations while the test tag remains unenforced.
---
Outside diff comments:
In `@token-lists/base.json`:
- Around line 1113-1120: Update the tokenMap entry for USDC identified by
address 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 to include the same
collateral tag as its corresponding tokens entry, preserving all existing
metadata.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 82a4d3a7-091d-4051-a610-7a84d3e058c2
📒 Files selected for processing (1)
token-lists/base.json
| "tags": [ | ||
| "st0x", | ||
| "test" | ||
| ], | ||
| "extensions": { |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Do not publish wtRKLB in the live base list until test is enforced.
settings.yaml:40-41 syncs consumers from this raw list, while the PR notes that consumers do not currently filter tags. Adding RKLB to both representations can therefore expose a token explicitly marked as unavailable for trading, hedging, rebalancing, and recovery. Gate those consumers first or keep RKLB in a separate test-only list.
🤖 Prompt for 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.
In `@token-lists/base.json` around lines 574 - 578, Remove the wtRKLB entry from
the live base token list in base.json until tag-based filtering is enforced by
the consumers synced through settings.yaml. Keep it only in a separate test-only
list if needed, and do not add it to both live representations while the test
tag remains unenforced.
The list could only express one thing: is this an ST0x wrapped token. Every entry carried
tags: ["st0x"]andcategory: "ST0x"except USDC, which carried neither — so "collateral" was a fact readers inferred from an absence.RKLB forced the question, because it fits neither slot.
What RKLB actually is
Verified on Base and Ethereum: deployed, owned by the token-owner Safe, wired to the production authoriser. Also:
st0x.liquidityconfig/prod/st0x-hedge.toml—trading = "disabled",rebalancing = "disabled",wrapped_equity_recovery = "disabled"st0x.issuance— referenced only fromfn test_metadata()st0x.pricing— "wtRKLB — not in the st0x.registry snapshot yet (RKLB onboarding, RAI-1411), but the oracle-server already resolves orders to it, so pricing must serve it"So it is live, integrators already resolve it, and it is deliberately not offered. Under the old schema the only options were to list it as an ordinary tradeable equity or leave it out — and it was being left out while services resolved against it anyway.
Two tags
USDC is now
["collateral"]rather than untagged, and RKLB is["st0x", "test"].tagsis the Uniswap token-list standard's own mechanism, so this needs no schema change — but consumers currently treat every entry as tradeable, and nothing filters on tags today. Anything that should exclude test tokens has to opt in; that is the follow-up this PR does not do.The entry
Identity is read from the chain, not transcribed:
name,symbolanddecimalsare what the wrapped vault returns, so the registry-vs-chain identity check cannot mismatch on arrival. (wtASMLcurrently shows exactly that kind of mismatch on the health dashboard.)0xF4f8c66085910d583c01f3b4e44Bf731D4e2c565Wrapped Rocket Lab USA Inc ST0x/wtRKLB/ 180xf6744fd9…0x34bf3d8d…https://st0x.io/images/RKLB.pngimage/pngtokenMapupdated in step withtokens(keys asserted identical), and the version bumped1.3.0 → 1.4.0per the token-list spec.No ISIN. RKLB's does not appear anywhere in the org, and a securities identifier is not something to guess. It is the only ST0x entry without one — worth filling before RKLB is ever tagged tradeable.
Why this matters beyond RKLB
productionReceiptVaults()in st0x.deploy is about to carry 29 entries (#259) against this list's 28. The org-health dashboard reconciles those two directions, so without this RKLB would render as a permanent "governed vault not in the registry" discrepancy on every scan.Summary by CodeRabbit