add: ALIGN (2026-08-17)

[claude]

Requested by Josh Salinas · Slack thread

Summary

Add 2 token entries to the default list — Aligned (ALIGN) on Ethereum and Base.

Symbol	Chain	Address	Decimals
ALIGN	Ethereum	0x50614CC8e44F7814549c223aA31db9296e58057c	18
ALIGN	Base	0x53f39e5C53EE40bbc3Da97C3B47BD2968d110a8D	18

Both entries use the metadata from CONS-3105 verbatim (name, symbol, decimals, logoURI), per the repo convention in CLAUDE.md to use the ticket's metadata. Appended to the end of src/tokens/mainnet.json and src/tokens/base.json. Version is now 22.19.0. (Originally 22.11.0 → 22.12.0; main has since published 22.12.0 in #2556, 22.13.0 in #2557, 22.14.0 in #2558, 22.15.0 in #2564, 22.16.0 in #2568 and 22.18.0 in #2571, so this has been re-bumped five times to stay on the next free minor — see "Merged with main" below.)

Verification

• EIP-55 checksums verified — node scripts/checksum.js 0x50614CC8e44F7814549c223aA31db9296e58057c 0x53f39e5C53EE40bbc3Da97C3B47BD2968d110a8D reports OK for both, exit 0. The address strings are committed byte-for-byte as verified.
• No duplicate entries introduced — neither address existed anywhere in src/tokens/ before this change, and no entry used the symbol ALGIN/ALIGN or the name Aligned on any chain.

yarn test was not run, because it cannot run in this environment. buildList() calls bridgeUtils.chainify(), which fetches https://api-polygon-tokens.polygon.technology — a host this environment's egress blocks. That fails the mocha before all hook, so all tests error out before any assertion executes. It fails identically on a clean checkout of main with zero changes, so it is a sandbox limitation and says nothing about this diff. I did not check a "yarn test passes" box rather than claim a green run I could not observe.

Substitute checks run locally instead:

1. EIP-55 checksum via scripts/checksum.js on both new addresses (above).
2. JSON parse of every file in src/tokens/ — all parse cleanly.
3. Offline duplicate scan over the union of src/tokens/*.json (1043 entries, post-merge; reads the chain files directly, skips chainify) for case-insensitive chainId+address, chainId+symbol, and chainId+name collisions — the same three invariants the test suite asserts.
4. Entry-count and set-equality check against origin/main — see "Merged with main".

GitHub Actions Tests is the authoritative signal on this PR — it runs the real yarn test with working network egress. Please treat its result, not my local run, as the gate.

Reviewer notes

1. Symbol is ALIGN — ticket and chain agree, nothing to settle. CONS-3105 specifies ALIGN, and both contracts report symbol() = ALIGN on-chain, on Ethereum and Base alike. The ticket and the on-chain metadata match, so there is no symbol divergence here. This PR originally carried ALGIN; the requester confirmed ALIGN in the originating Slack thread, and both entries have been corrected to ALIGN in src/tokens/mainnet.json and src/tokens/base.json before merge. Because the correction lands inside this still-unmerged PR rather than editing an entry already published in the list, it is not an "update" for versioning purposes — the version stays a single minor bump and no major bump is required.

2. Field-by-field divergence between ticket and chain:

Field	Ticket (CONS-3105)	On-chain (both chains)	Committed	Divergence
symbol	ALIGN	ALIGN	ALIGN (ticket)	No — see note 1
name	Aligned	Aligned Token	Aligned (ticket)	Yes, cosmetic — the ticket drops the Token suffix, which is normal for display names in this list
decimals	18	18	18	No

On-chain values came from eth_call for symbol() / name() / decimals() through the entry-gateway RPC passthrough for chainIds 1 and 8453 (all HTTP 200, no BigQuery fallback needed), and were independently corroborated against BigQuery uniswap-allium.{ethereum,base}.erc20_tokens.

3. This is a Coinbase roadmap addition, not a live listing. It is being added ahead of / independent of a live Coinbase listing, so please weigh it on that basis rather than assuming listed status.

4. Cross-chain identity is well established. The Base contract is a canonical OP-Stack OptimismMintableERC20 whose remoteToken()/l1Token() both point at the Ethereum address in this PR, and whose bridge() is Base's L2StandardBridge predeploy 0x4200000000000000000000000000000000000010. The L1 bridge escrow balance on mainnet (326,555,038 ALIGN held by 0x3154Cf16ccdb4C6d922629664174b904d80F2C35) equals Base's totalSupply() exactly, to the wei. The mainnet contract is an EIP-1967 proxy with a single Upgraded event at its deploy block — never upgraded since.

Merged with main

main has moved seven times while this PR sat unreviewed, and it has now gone un-mergeable five times. Each time origin/main was merged into this branch (a merge commit, per this repo's convention): #2556 (e63761b), #2557 (742ad30), #2558 (a6fd393), #2564 (2f7d74d) and now 5e32e2c — day 24 of this PR being open, still with zero reviews.

Two commits have landed on main since the last resolution (2f7d74d, 22.15.0), both authored by claude[bot]:

Commit	PR	Title	Version after
af570f1	#2568	add: ONE (2026-09-08)	22.16.0
5e32e2c	#2571	add: SOFID (2026-09-10)	22.18.0

The token has not been shipped by hand, and no other open PR carries it. Two checks, both against the current origin/main rev (5e32e2c), fetched explicitly rather than read from a stale local ref:

• Not on main. Neither ALIGN address, nor the symbol ALIGN, nor the name Aligned, appears anywhere under src/tokens/ — verified case-insensitively, with a control pattern (USDC, which matches in 5 files) confirming the greps do match known-present entries, so the negative is trustworthy.
• Not folded into a consolidation PR. All 178 open PRs on the repo were enumerated and each one's full diff was fetched and scanned for both addresses, the symbol ALIGN and the name Aligned. add: ALIGN (2026-08-17) #2554 is the only open PR that carries them. No diff came back empty, so the negative covers the whole set rather than silently skipping PRs.

So this remains a genuine addition, not a supersede.

This round the conflict was in package.json / package-lock.json, not in the token files. Because main had moved to 22.18.0 while this branch still claimed 22.16.0, the two sides wrote different version strings and git raised a real conflict for once — the opposite of the silent auto-merge that bit the previous four rounds. Both conflict hunks were version-only; they were resolved to main's 22.18.0 and the branch was then re-bumped with npm version --no-git-tag-version, so package-lock.json was regenerated rather than hand-edited.

The token files auto-merged cleanly this round. #2568 touched only bnb.json and #2571 touched mainnet.json and solana.json; of those, only mainnet.json is also touched by this PR, and the ALIGN entry there sits mid-array rather than at the tail where #2571 appended, so the two edits never met. bnb.json and solana.json took main's changes verbatim. That auto-merge was not taken on trust — a clean merge can still fuse or drop an entry — so the result was checked structurally by chainId + lowercased address rather than by diff position:

Side	Entry	chainId	Address
main (#2568)	ONEchain (ONE), bnb.json	56	0x6bf62ca91e397B5A7d1D6bCe97D9092065d7A510
main (#2571)	SoFiUSD (SOFID), mainnet.json	1	0x0CB6d03B0aC88A463F67B7Ad99f9f3ec4678092E
main (#2571)	SoFiUSD (SOFID), solana.json	501000101	APhcqtzE73es3KAGiVksZFMLGwJDiAey5qZKUrQHEHfS
this PR	Aligned (ALIGN)	1	0x50614CC8e44F7814549c223aA31db9296e58057c
this PR	Aligned (ALIGN)	8453	0x53f39e5C53EE40bbc3Da97C3B47BD2968d110a8D

No overlap on chainId+address, chainId+symbol or chainId+name, so keeping both sides is correct.

Three details worth a reviewer's eye:

• The version collided silently four times before this one, and was re-bumped each time. When main and this branch write an identical version string, git auto-merges package.json with no conflict, and twice that left this branch carrying no effective bump at all. The guard is to re-read version from package.json on the default branch explicitly after every merge rather than inferring anything from the absence of a conflict. Measured this round: main is at 22.18.0 (not the 22.16.0 this branch claimed, and not the 22.16.0 that add: ONE (2026-09-08) #2568 left behind — add: SOFID (2026-09-10) #2571 moved it again). Re-bumped to 22.19.0, the next free minor above the measured value, and confirmed no existing git tag holds it.
• CI green would not by itself prove the resolution correct. mergeTokenLists groups entries by ${chainId}-${address.toLowerCase()} and collapses each group with lodash.merge before the duplicate assertions run, so a duplicated entry passes the suite silently. Verified offline instead:
  • Every file under src/tokens/ parses.
  • The collision set over the union of all chain files is identical before and after the merge — 1 chainId+address collision (the pre-existing, known-harmless byte-identical B3 duplicate at 0xB3B32F9f8827D4634fE7d973Fa1034Ec9fdDB3B3, untouched), 4 chainId+symbol (LIT on chain 1, AVA and WBTC on chain 501000101, B3 on 8453), 1 chainId+name — all pre-existing on main. The resolution introduces none.
  • Entry count went 1041 → 1043, exactly the two ALIGN entries on top of main's count. A collision scan cannot detect a fused or vanished entry, but the count can, which is why it is checked separately.
  • A multiset comparison of every (file, chainId, address, symbol, name) tuple against origin/main shows the merged tree holds exactly main's 1041 entries plus the 2 ALIGN entries. The "present on main but missing in the merge" set is empty — in particular add: ONE (2026-09-08) #2568's and add: SOFID (2026-09-10) #2571's entries survived intact.
  • Each ALIGN address appears exactly once across all chain files, and both still pass EIP-55 via scripts/checksum.js.
  • Net diff against origin/main is the two ALIGN entries plus the version bump, nothing else (4 files).
• The marker-deletion trap from the previous rounds did not fire this round, and that is worth stating explicitly rather than leaving as an absence. In earlier rounds git had auto-merged the shared { and "chainId": lines above the <<<<<<< marker, so stripping markers would have fused two token objects into one; deleting only the marker lines produced a parse error at the seam, and "fixing" that by adding the missing comma produced valid JSON that silently dropped an entry (last-key-wins, no duplicate, no failing assertion). No token-file conflict arose this round, so there were no markers to mis-resolve — the entry-count and multiset checks above are what confirm nothing was fused or lost regardless.

Linear tickets

• CONS-3105

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01TgCpMmmtJZDzGuRawLF4Sp

[linear-code]

CONS-3105