fix: denominate tron currencies as erc20

[bassgeta]

TL;DR

Temporarily changed Tron token types from TRC20 to ERC20 as a workaround for issue #1713

What changed?

• Added a TODO comment in the TokenType enum indicating this is a temporary change
• Changed the token type for two Tron tokens (USDT and USDC) from "TRC20" to "ERC20" in both the main token list and v1.5.0 version file

How to test?

• Verify that Tron tokens now have type "ERC20" instead of "TRC20" in the token lists
• Test that the application properly handles these Tron tokens with the ERC20 type designation
• Confirm that the TODO comment is present in the TokenType enum

Why make this change?

This is a temporary workaround to address issue #1713 in the RequestNetwork repository. The change allows Tron tokens to function properly until the underlying issue with TRC20 token handling is resolved.

[bassgeta]

• fix: denominate tron currencies as erc20 #33 👈 (View in Graphite)
• main

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

[greptile-apps]

Greptile Summary

This PR is a temporary workaround for RequestNetwork/requestNetwork#1713: it re-labels the two Tron tokens (USDT-tron, USDC-tron) from "type": "TRC20" to "type": "ERC20" in the main token list, bumps the patch version from 1.5.0 to 1.5.1, and drops a TODO comment in the TokenType enum. The historical versions/v1.5.0.json snapshot is correctly left untouched; the new versions/v1.5.1.json snapshot will be auto-generated by the deploy workflow on the next release.

Key points from the review:

• Semantic collision risk: Marking Tron tokens as ERC20 while their network remains "tron" means any consumer that filters payment routes by type === "ERC20" alone will receive Tron addresses in an EVM context. Tron addresses are not valid EVM addresses, which can cause downstream failures (invalid ethers address normalisation, broken contract calls, etc.). Consumers should be explicitly informed they must guard with network !== "tron" for the duration of this workaround.
• TODO discoverability: The TODO comment lives on the TRC20 enum member, which is not directly connected to the mis-typed token records. Consider adding a comment closer to the Tron entries in token-list.json to make the workaround easier to find during a future fix.
• The version bump and preservation of v1.5.0.json follow the convention established by the deploy workflow correctly.

Confidence Score: 3/5

• Mergeable as a temporary workaround, but carries a real risk of breaking consumers that rely on the type field alone to route EVM operations.
• The change is intentional and documented, and the version/snapshot handling is correct. However, the semantic mismatch between type=ERC20 and network=tron is a genuine P1 concern: EVM tooling that trusts the type field without also checking network will attempt to use Tron addresses as EVM addresses, which will fail silently or throw. The risk is limited to the duration of the workaround, but downstream integrators need explicit guidance.
• tokens/token-list.json — the two Tron token entries with "type": "ERC20" need the accompanying caveat communicated to consumers.

Important Files Changed

Filename	Overview
src/types/index.ts	Adds a TODO comment above the TRC20 enum value pointing to issue #1713; no functional change to the enum itself.
tokens/token-list.json	Version bumped 1.5.0 → 1.5.1; USDT-tron and USDC-tron type changed from TRC20 to ERC20 as a workaround. The semantic mismatch between network=tron and type=ERC20 may break consumers that use the type field alone to route EVM operations.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Consumer fetches token-list v1.5.1] --> B{Filter by type}
    B -->|type === 'ERC20'| C[EVM token set\nETH, MATIC, BSC… tokens]
    B -->|type === 'ERC20'| D[⚠️ USDT-tron\nnetwork: tron\naddress: TR7NH…]
    B -->|type === 'ERC20'| E[⚠️ USDC-tron\nnetwork: tron\naddress: TEkxi…]
    B -->|type === 'TRC20'| F[Empty — no tokens match\nTRC20 temporarily unused]
    C --> G[EVM operation ✅]
    D --> H{Consumer checks network?}
    E --> H
    H -->|Yes — skips tron entries| I[Safe ✅]
    H -->|No — passes to EVM handler| J[Invalid address error ❌\ne.g. ethers.getAddress throws]

Loading

_{Last reviewed commit: "fix: remove trailing..."}

[bassgeta]

@greptileai review

[greptile-apps]

ERC20 type on Tron network creates semantic collision for consumers

Both Tron tokens now carry "type": "ERC20" while retaining "network": "tron". Any downstream consumer that routes payments or builds transaction data based solely on type === "ERC20" will now encounter these Tron addresses in an EVM context. Tron addresses (e.g. TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t) are not valid EVM addresses, so any EVM-side operation (e.g. ABI encoding, ethers.utils.getAddress normalisation, smart contract calls) attempted against them will either throw or silently produce wrong output.

Consumers who correctly pair type with network will be unaffected, but anyone who trusts type alone—which is the primary filter field exposed by the schema—will be exposed to this mismatch. It is worth explicitly documenting this caveat in the PR/changelog (beyond the TODO comment in the enum) so that integrators are aware they must also check network !== "tron" when processing "type": "ERC20" entries for the duration of this workaround.

[bassgeta]

Closing this, we decided to implement this bandaid on our API 👍