Spike: Can we add Plasma USDT0 under USDT0 related assets

[gomesalexandre]

⚠️ SPIKE - Time-boxed to 2-3 hours max

⚠️ Blocked by Plasma go-live

Overview

Currently, Plasma USDT0 (eip155:9745/erc20:0xb8ce59fc3717ada4c02eadf9682a9e934f625ebb) is explicitly excluded from related asset grouping in our asset generation script. This was implemented in PR #11369 as a workaround to fix asymmetric grouping issues caused by CoinGecko data corruption.

The Problem:

Following Plasma's launch, Plasma USDT0 is now the canonical primary asset for the USDT0 family (per CoinMarketCap - Plasma is Tether's stablecoin L1). However, our current fix excludes the primary from its own group:

• Plasma USDT0 has relatedAssetKey: null (excluded from all grouping)
• Other USDT0 variants are orphaned without their canonical primary
• When Plasma goes live, users will see asymmetric behavior (same bug as USDT0 - wrong related assets for most flavours #11113):
  • Click Plasma USDT0 → no related assets shown
  • Click other USDT0 variants → Plasma not listed as related

The Goal:

Implement proper conflict detection to:

1. Keep USDT and USDT0 as separate groups (they are different tokens per CoinGecko)
2. Allow Plasma USDT0 to be the primary of the USDT0 group
3. Prevent contract address "stealing" between groups (the root cause)
4. Maintain bidirectional grouping consistency (no asymmetry)

References and additional details

Relevant Issues/PRs:

• Issue USDT0 - wrong related assets for most flavours #11113 - Original asymmetric grouping problem
• PR feat: plasma and USDT/0 shenanigans #11369 - Current fix that excludes Plasma USDT0
• Issue Revert Plasma usdt0 exclusion from related asset generation once Plasma feature flag is enabled #11370 - Created to track reverting the exclusion once Plasma is live

Code Location:
scripts/generateAssetData/generateAssetData/generateAssetData.ts

Plasma USDT0 is currently excluded in 5 locations:

• Line 142: Filtered from Zerion results
• Line 173: Filtered from CoinGecko results
• Line 197: Early return in processRelatedAssetIds()
• Line 289: Filtered from merged arrays
• Line 347: Cleared in cleanup phase

Root Cause of Original Bug (#11113):

CoinGecko has corrupt/cross-contaminated data where USDT (tether) and USDT0 (usdt0) claim each other's contracts:

Verified via public APIs (December 2025):

• Arbitrum 0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9:

  • Blockchain truth (Arbiscan): USD₮0 token
  • CoinGecko usdt0: ✅ Correctly claims it
  • CoinGecko tether: ❌ No longer lists (may have been corrected)

• Polygon 0xc2132d05d31c914a87c6611c10748aeb04b58e8f:

  • Likely real USDT contract
  • CoinGecko usdt0: ❌ Incorrectly claims it
  • Cross-contamination between the two coin IDs

Processing order by market cap causes the issue:

1. USDT (rank ~3) processes first → claims contracts
2. USDT0 (rank ~5000) processes later → overwrites relatedAssetKey for shared contracts
3. Result: Index has old references but asset metadata is updated → asymmetry

Proposed Solution (from robot analysis in #11113):

Implement first-come-first-served conflict detection:

// In processRelatedAssetIds(), before assigning relatedAssetKey:
const cleanedRelatedAssetIds = mergedRelatedAssetIds.filter(candidateAssetId => {
  const existingKey = assetData[candidateAssetId]?.relatedAssetKey
  
  if (!existingKey || existingKey === relatedAssetKey) {
    return true  // No conflict or already in this group
  }
  
  // Conflict: already claimed by different group
  console.warn(
    `[Related Asset Conflict] ${candidateAssetId} already belongs to group ${existingKey}, ` +
    `refusing to add to ${relatedAssetKey}. CoinGecko data quality issue.`
  )
  return false  // Reject - first claim wins
})

Expected Result:

• USDT (rank ~3) claims shared contracts first
• USDT0 (rank ~5000) tries to claim them → conflict detected → rejected
• Plasma USDT0 becomes primary of USDT0 group with only unique contracts
• Clean separation, no overlap, bidirectional consistency

Acceptance Criteria

This is a research spike - deliverable is feasibility assessment and implementation plan:

1. Analyze the conflict detection approach:

   • Where exactly should it be implemented?
   • Does it handle all edge cases?
   • What are the performance implications?

2. Identify all Plasma exclusion points and verify they can be safely removed after conflict detection is in place

3. Test strategy:

   • How to verify USDT and USDT0 stay separate?
   • How to verify no contract overlap?
   • How to verify bidirectional consistency?
   • How to test with Plasma flag on/off?

4. Risk assessment:

   • What could break?
   • Are there other tokens with similar conflicts?
   • What happens to existing user data/state?

5. Document findings with:

   • Can it be done safely? (Yes/No/Maybe)
   • Specific implementation steps
   • Estimated effort for full implementation
   • Any gotchas or edge cases discovered

Success Criteria:

• Clear go/no-go decision with technical rationale
• If go: Concrete implementation plan with risk mitigation
• If no-go: Alternative recommendations

Need By Date

Not applicable - research spike

Screenshots/Mockups

Not applicable

Estimated effort

2-3 hours (time-boxed - do not exceed)

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Related PRs

#10419 - fix: migrate on chain suffix generation at runtime [merged]
#11034 - fix: rebuild related assets if its been updated upstream on coingecko [merged]
#11369 - feat: plasma and USDT/0 shenanigans [merged]
#11444 - fix: blacklist incorrect Coingecko XPL placeholder [merged]
#11453 - fix: group assets for sui and tron [merged]

👤 Suggested Assignees

• NeOMakinG
• gomesalexandre

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[gomesalexandre]

This is a meta "first-come-first-serve" issue, not only is there FCFS logic TBD in this spike and/or implementation but that issue is also a FCFS between myself and large @NeOMakinG once Plasma goes live!