Liste de jetons et étiquettes d'adresse

Ce qu'est la liste

Deux fichiers par réseau. tokenlist.json recense les jetons examinés, au format standard Uniswap Token Lists, pour que n'importe quel portefeuille, interface de DEX ou agrégateur puisse l'importer tel quel. tags.json donne aux contrats connus une étiquette lisible - un nom, une catégorie et un projet - pour qu'un explorateur puisse afficher « Pepper router » là où il afficherait sinon une adresse hexadécimale.

Un jeton listé reçoit la marque de vérification, son logo, son nom et son symbole sur l'explorateur, sur Pepper, dans le Toolkit, sur Names et dans la page Account. Un contrat étiqueté apparaît sous son étiquette dans les listes de transactions, sur les pages d'adresse et dans la recherche.

Rien n'est listé automatiquement. Un jeton lancé avec le lanceur de jetons de Pepper n'est pas ajouté parce qu'il existe ; il l'est quand quelqu'un ouvre une pull request et qu'il remplit les critères.

Où elle se trouve

La liste se trouve dans un dépôt GitHub public, github.com/PickleChain/token-list, avec un dossier par réseau :

Dans un dossier de réseau :

Les URL brutes, toujours sur le dernier commit de main :

https://raw.githubusercontent.com/PickleChain/token-list/main/testnet/tokenlist.json
https://raw.githubusercontent.com/PickleChain/token-list/main/testnet/tags.json

Pour un site web, récupérez les fichiers côté serveur et servez-les depuis votre propre origine au lieu de lier directement raw.githubusercontent.com depuis le navigateur des visiteurs : leurs adresses IP restent à l'écart d'un tiers, vous évitez les limites de débit de GitHub et vous pouvez garder la dernière copie valide quand GitHub est injoignable. Dans un portefeuille ou une interface de DEX, ajoutez l'URL brute de tokenlist.json comme liste de jetons personnalisée.

Comment les applications Pickle s'en servent

L'API de l'explorateur est la seule partie de la pile Pickle qui interroge GitHub pour ces fichiers. Elle récupère les deux environ toutes les dix minutes, valide chaque fichier dans son ensemble - forme, chain ID, sommes de contrôle, doublons - et garde la dernière copie valide en mémoire et sur disque. Un fichier en échec est rejeté en entier et le précédent reste en service, si bien qu'un mauvais commit ne peut jamais effacer une étiquette ou un logo. Chaque site Pickle lit ensuite la copie de l'explorateur depuis sa propre origine :

Les routes sont sur https://explorer.picklechain.xyz, derrière la liste d'autorisation CORS de l'explorateur : elles servent les sites Pickle. Votre propre application lit les fichiers bruts ci-dessus.

Ajouter un jeton

Vérifiez d'abord les critères : une pull request pour un jeton qui ne les remplit pas est fermée. Ensuite, sur votre fork du dépôt :

1. Récupérez l'adresse avec somme de contrôle. Casse mixte EIP-55, pas tout en minuscules. Si la vôtre est fausse, le validateur affiche la forme attendue.
2. Ajoutez le logo dans testnet/logos/tokens/, nommé exactement d'après cette adresse : testnet/logos/tokens/0x0000…dEaD.png (ou .svg). Il doit suivre les règles pour les logos.
3. Ajoutez une entrée à la fin de tokens dans testnet/tokenlist.json, comme dans l'exemple ci-dessous.
4. Montez la version de tokenlist.json - ajouter un jeton est une montée mineure, 1.4.2 devient 1.5.0 - et réglez timestamp sur maintenant, en ISO 8601 UTC.
5. Lancez les vérifications avec npm test. Il faut Node 22 ou plus récent et rien d'autre : le validateur n'a aucune dépendance, il n'y a donc rien à installer.
6. Ouvrez une pull request vers main. Dans sa description, mettez le lien d'une publication du site web ou du compte officiel du projet qui cite l'adresse du contrat.

{
  "chainId": 78270,
  "address": "0x0000…dEaD",
  "name": "Example Token",
  "symbol": "EXM",
  "decimals": 18,
  "logoURI": "https://raw.githubusercontent.com/PickleChain/token-list/main/testnet/logos/tokens/0x0000…dEaD.png",
  "extensions": {
    "website": "https://your-project.example",
    "explorer": "https://explorer.picklechain.xyz/address/0x0000…dEaD"
  }
}

0x0000…dEaD tient lieu de votre adresse complète de 42 caractères avec somme de contrôle ; c'est un exemple de remplacement, pas un jeton.

L'aller-retour complet en ligne de commande :

# Fork and clone (or fork on the website and clone your fork):
gh repo fork PickleChain/token-list --clone
cd token-list
git checkout -b add-exm

# Logo, entry, version and timestamp, then:
npm test

git add testnet/tokenlist.json testnet/logos/tokens/
git commit -m "Add Example Token (EXM)"
git push origin add-exm
# ...and open the pull request on GitHub.

Règles pour les logos

Chaque fichier sous logos/ doit être référencé par la liste ou par les étiquettes. Un logo vers lequel rien ne pointe fait échouer les vérifications : retirez-le donc dans la même pull request que son entrée.

Ajouter une étiquette d'adresse

Les étiquettes sont pour les contrats que l'on croise dans les transactions : contrats de protocole, routers, factories, pools, coffres, jeux, bridges. Les portefeuilles personnels ne sont jamais étiquetés. Le projet doit être en service sur Pickle Chain, et l'adresse doit pouvoir être vérifiée dans la documentation ou les fichiers de déploiement du projet lui-même.

1. Ajoutez une entrée à tags dans testnet/tags.json, indexée par l'adresse avec somme de contrôle.
2. Ajoutez éventuellement un logo dans testnet/logos/tags/ - mêmes règles de format que pour un logo de jeton, nom de fichier libre - et faites pointer logo vers son URL brute. Plusieurs étiquettes d'un même projet peuvent partager un fichier.
3. Montez la version de tags.json et son timestamp, lancez npm test et ouvrez la pull request.

"0x0000…dEaD": {
  "name": "Example vault",
  "category": "protocol",
  "project": "Example",
  "url": "https://your-project.example",
  "logo": "https://raw.githubusercontent.com/PickleChain/token-list/main/testnet/logos/tags/example.png",
  "note": "Holds deposits and pays out the weekly yield."
}

Les catégories définies aujourd'hui :

Si aucune ne convient, proposez une nouvelle catégorie dans la même pull request : une clé en minuscules de 20 caractères au plus, avec un name et une description.

Modifier ou retirer une entrée

• Modifiez une entrée - un nom, une note, un site web, les décimales - en l'éditant sur place et en montant la version de patch. Ouvrez la pull request depuis l'équipe du jeton, comme pour un ajout.
• Changez un logo en remplaçant le fichier. Passer de PNG à SVG ou l'inverse le renomme : mettez donc à jour logoURI et supprimez l'ancien fichier.
• Remplacez un contrat en ajoutant la nouvelle adresse. Pour une étiquette, gardez l'ancienne entrée et ajoutez (previous) à la fin de son nom, pour que les anciennes transactions restent claires.
• Retirez une entrée en la supprimant avec son fichier de logo, et en montant la version majeure.

Les mainteneurs peuvent retirer un jeton à tout moment - après un exploit, un rug pull, le passage à un nouveau contrat ou un changement trompeur de métadonnées.

Versions

Chaque fichier porte sa propre version, et la montée suit les règles de Token Lists. La CI l'impose par rapport à la branche de base de la pull request, et une version modifiée exige un timestamp plus récent.

npm test                                      # every list and logo, then the validator's own tests
node scripts/validate.mjs --base origin/main  # also the version bumps, as CI checks them

Ce que vérifie la revue

Chaque pull request lance npm test et la vérification de version dans GitHub Actions, puis un mainteneur l'examine. Un jeton est ajouté quand toutes ces conditions sont remplies :

• Il est déployé sur le réseau de ce dossier, et son code source est vérifié ou publié.
• La pull request est ouverte ou confirmée par l'équipe du jeton, avec le lien d'une publication du site web ou du compte officiel du projet qui cite l'adresse du contrat.
• Son nom et son symbole n'imitent pas un autre jeton ou projet. Un nouveau PKL ou WETH est refusé.
• Il a un usage réel : de la liquidité sur Pepper, des détenteurs ou un produit en service - pas un jeton lancé il y a quelques minutes.
• Le contrat n'a pas de mint caché, de liste noire ou d'interrupteur de frais que l'équipe n'a pas déclaré.

Une étiquette est ajoutée quand l'adresse est un contrat, que le projet est en service sur Pickle Chain et que l'adresse peut être vérifiée dans la documentation ou les fichiers de déploiement du projet lui-même.

Erreurs de validation courantes

npm test affiche chaque problème, pas seulement le premier. Ceux que l'on rencontre le plus, et la correction :