Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintain a tokenlist by chainId #64

Open
ashachaf opened this issue Oct 29, 2024 · 3 comments
Open

Maintain a tokenlist by chainId #64

ashachaf opened this issue Oct 29, 2024 · 3 comments

Comments

@ashachaf
Copy link

ashachaf commented Oct 29, 2024

Current implementation of the tokenlist includes tokens from both chainId 42220 and 44787.

Please split the list into two different lists, one for each chainId.
This will maintain tokenlist best practice structure where each list is dedicated for a dedicated chainId.

@ashachaf ashachaf changed the title Remove potential duplicated tokens from the token list Maintain a tokenlist by chainId Oct 29, 2024
@aaronmgdr aaronmgdr added this to the 5 - Celo MVP Mainnet milestone Oct 29, 2024
@sodofi
Copy link
Contributor

sodofi commented Nov 4, 2024

@aaronmgdr if we change celo.tokenlist.json it can affect all the user calling the list as it is.

Do you have a preference here for which option we should do?

  1. Celo.tokenlist.json stays as is and we make two new jsons called 'celo.mainnet.tokenlist.json' and 'celo.testnet.tokenlist.json' with the separate lists. This will create three token lists in total. However, this will mean we have two places where we will need to update.

  2. Edit celo.tokenlist.json to only include mainnet tokens. Create a new celo.testnet.tokenlist.json with the testnet tokens. This will create two token lists in total. This will only affect users who are calling testnet token and hopefully minimal changes to mainnet token callers.

  3. Don't make any changes and keep as is.

@nicolasbrugneaux
Copy link
Contributor

I'm not entirely sure what the benefits of splitting the list is? Filtering values programmatically by chainId is easy enough and the list isn't big at all, so download size doesn't matter here. I'm strongly in favour of option 3

@aaronmgdr
Copy link
Member

aaronmgdr commented Nov 4, 2024

  1. sound good to me. I dont want to be maintaining 3 lists.

If separate lists per chain is the standard we will follow that custom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants