Adding the Foo test token on Sepolia Linea

[vkuts]

Action: Add token (choose one)

Context / Rationale:
I am testing out your process for registering a mainnet token, which needs to be bridge-able via the canonical bridge contract, but have a custom/pre-deployed L2 implementation

---

PR Checklist

• Verified and published the contract source
• Kept the token list in alphabetical order by token symbol
• Updated the updatedAt field (and createdAt if applicable)
• Updated the list version number according to the README instructions

---

Note

Adds FOO canonical-bridge token to json/linea-sepolia-token-shortlist.json and bumps list version to 1.3.0 with updated date.

• Token list (json/linea-sepolia-token-shortlist.json):
  • Addition: Add FOO (0x0869E86479D60D07DF0E31312E7207c6cf470e31) with tokenType canonical-bridge, decimals 18, logo URI, and root chain details.
  • Metadata: Bump version to 1.3.0 and update updatedAt to 2025-10-07.

^{Written by Cursor Bugbot for commit e333b4c. This will update automatically on new commits. Configure here.}

[alainncls]

Hi @vkuts
I'm not sure what you're trying to achieve with this test?

[vkuts]

@alainncls hey, I'm just attempting to go through the Linea custom L2 token registration process in prep for a mainnet token launch. My goal is to get a working e2e setup in Sepolia/Linea Sepolia, including L1<->L2 token bridging experience.

[alainncls]

I see.
I don't think we'll allowlist a token that is not deployed yet though, for security reasons.

[vkuts]

I'm confused, since I did deploy my token contracts to both Sepolia and Sepolia Linea, and the code is verified, etc.
Are you talking about it not being deployed on mainnet? If so, what difference does that make while working with testnets?

[vkuts]

Bumping this up. I would love to understand what security concerns you have.

[alainncls]

Hey @vkuts
First of all, sorry for the delay.
I just realized I misread the PR and was looking for your token on Linea Mainnet instead of Linea Sepolia. My bad.

One small note: the token description is missing a logo (logoURI); we need it for the Bridge UI.
Also, since the token is declared as bridge-reserved, we will need to set it as such at the smart contract level. Looping in @thedarkjester to make sure this is tracked 😉

[thedarkjester]

@vkuts as discussed on Discord - are you wanting to map your token to the canonical token bridge so that when bridging occurs it will target your token for mint/burn?

[vkuts]

@alainncls hey, thanks for the followup. No worries 👍 I didn't realize that logoURI is a required parameter, as it is not listed as a required field in l2-token-list-schema.json. I can certainly provide a value.
@thedarkjester yes, precisely. I'm planning on having a pretty vanilla mainnet token, and to implement most of the 'interesting' token logic on Linea.

[thedarkjester]

@alainncls hey, thanks for the followup. No worries 👍 I didn't realize that logoURI is a required parameter, as it is not listed as a required field in l2-token-list-schema.json. I can certainly provide a value. @thedarkjester yes, precisely. I'm planning on having a pretty vanilla mainnet token, and to implement most of the 'interesting' token logic on Linea.

Before merging this and going to mainnet, please discuss with the BD team if they are in a position to arrange the custom mapping on the token bridge.

Reserved in your PR should be changed to the canonical bridge option if the intent is to use the canonical bridge. Reserved is more for preventing usage on the bridge.

[cursor]

Bug: Token Type Mismatch Affects Bridge Functionality

The new token's tokenType is set to canonical-bridge, but PR discussions indicate it should be bridge-reserved to support canonical bridge mapping and smart contract configuration. This mismatch could affect bridge functionality.

 

[vkuts]

@thedarkjester is the bot confused?