fix: route-label token address rules never match integrator config addresses - #862
Open
gomesalexandre wants to merge 2 commits into
Open
fix: route-label token address rules never match integrator config addresses#862gomesalexandre wants to merge 2 commits into
gomesalexandre wants to merge 2 commits into
Conversation
…dresses routeLabels' fromTokenAddress/toTokenAddress rules were compared to route.fromToken.address / route.toToken.address via case-sensitive Array.includes(). The LI.FI API always returns EIP-55 checksummed (mixed-case) EVM addresses, so any config address that isn't written in the exact checksummed form silently never matches - including this repo's own default example config, which writes at least one address lowercase. Every other config-address vs API-address comparison in this package lowercases both sides before comparing; this was the one exception, and the only one with no test coverage. Fix compares EVM addresses (0x-prefixed, 40 hex chars) case-insensitively, and falls back to exact comparison for everything else - non-EVM chains (Solana base58, Sui coin types, etc.) use case-sensitive identifiers and must not be case-folded. Scope: routeLabels is an opt-in integrator config feature; labels are purely display/cosmetic with no effect on route selection or amounts. Not reachable through the default widget configuration.
🦋 Changeset detectedLatest commit: 2f70e59 The changes in this PR will be included in the next version bump. This PR includes changesets to release 20 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
gomesalexandre
marked this pull request as ready for review
September 2, 2026 03:56
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What it says on the box
routeLabels'fromTokenAddress/toTokenAddressrules never match unless the integrator writes their config address in the exact EIP-55 checksummed case the LI.FI API returns.The bug
getMatchingLabels.tscompared config addresses againstroute.fromToken.address/route.toToken.addressvia case-sensitiveArray.includes:The LI.FI API always returns mixed-case (checksummed) EVM addresses. A live quote confirms this —
fromToken.address/toToken.addresscome back checksummed on every response I checked. Config addresses are commonly written lowercase, and this repo's own default example config does exactly that:So a rule using that config's own address would silently never match.
Why it went unnoticed
Every other config-address-vs-API-address comparison in this package lowercases both sides first (
utils/token.ts,useTokenSearch.ts,useToken.ts,useTokenBalances.ts,utils/tokenList.ts,pinnedTokens). This file was the one exception - and the only one with no test coverage. The siblingfromChainId/toChainIdcriteria in the same rule are numeric, so they're case-free and kept passing while the address criterion silently failed next to them.Related prior art with the same root-cause class (address-casing mismatch), different location: #165.
Fix
Compare EVM addresses (0x-prefixed, 40 hex chars) case-insensitively; fall back to exact string comparison for everything else. This widget supports Solana, Bitcoin, Sui, Tron and Stellar alongside EVM chains, and several of those use genuinely case-sensitive identifiers (Solana base58 addresses, Sui coin types) - blanket-lowercasing every token identifier would introduce a new false-positive-match bug on those chains. Codex's adversarial review caught exactly this on the first pass; the fix and the added non-EVM regression test both reflect it.
Scope
routeLabelsis opt-in integrator config. Labels are purely display/cosmetic - no effect on route ordering, selection, or amounts. No fund impact. Not reachable through the default widget configuration shipped to end users with no custom config.receipts
Red-before/green-after verified genuinely: the new non-EVM regression test fails against a naive blanket-
.toLowerCase()fix (the exact gap Codex flagged) and passes only against the correctly EVM-scoped fix in this diff.Codex (
gpt-5.6-sol) ran adversarially against the diff and found one real P2 (the EVM-scoping gap above, applied) plus a test-wording nit (also applied). No other issues.