MSTR Cat

Droit crypto/Niveau VI · Conduite sur les marchés/6.3 Le lancement honnête/Leçon 3

Transparence on-chain : indiquer aux gens où regarder

Pourquoi les données publiques de la blockchain ne deviennent une divulgation que lorsque le lancement indique aux personnes quelles adresses, quels contrats et quel code vérifier, et ce que ces données peuvent ou non prouver.

Ceci est une ressource éducative et non un conseil juridique, fiscal ou en investissement. Le droit des crypto-actifs varie d'un pays à l'autre et d'un État à l'autre, et évolue souvent. Avant d'agir, vérifiez les règles en vigueur là où vous vivez auprès d'un avocat ou d'un conseiller fiscal qualifié.

La voie la plus légère

La voie la moins chère, la moins imposée, la plus simple et la plus discrète que permet la loi, de la meilleure à la moins bonne. Chaque étape indique la règle sur laquelle elle repose et la condition qui la maintient dans la légalité.

  1. Gratuit et le plus efficace : publier l'adresse du contrat ou du mint du jeton dans un endroit officiel stable unique et la répeter identiquement partout, puisque EIP-20 rend les noms facultatifs et que les copies sont faciles. Piège : expliquer publiquement tout changement d'adresse.
  2. Vérifier le code source gratuitement sur Etherscan, ou avec solana-verify pour les programmes Solana. Piège : la vérification ne prouve que le code publié est le code déployé, pas qu'il est sûr, et un code évolutif peut être remplacé plus tard.
  3. Publier une carte étiquetant le pool, les verrouillages, les contrats d'attribution progressive, la trésorerie et les portefeuilles d'équipe par rôle plutôt que par nom personnel, ce qui est une confidentialité légale vis-à-vis du public. Piège : les portefeuilles publiés sont permanents, les transferts liés sont traçables, et la déclaration fiscale continue.
  4. Prouver chaque affirmation avec un hachage de transaction, pour un verrouillage, une autorité révoquée ou un déploiement d'attribution progressive ; l'interprétation de 2026 de la SEC encourage à divulguer les travaux promis lorsqu'ils sont achevés, et partager un hachage ne coûte rien. Piège : maintenir la carte à jour au fur et à mesure que les adresses changent.

MatérielUn explorateur de blocs pour la chaîne du jeton, ouvert sur le contrat du jeton ou le mintLa liste des adresses officielles du projet, s'il en publie uneLe standard de jeton EIP-20 et la documentation des builds vérifiés de SolanaLeçon 6.3.1, sur ce que requiert une divulgation honnête

Curiosité

  1. Si tout est déjà sur la chaîne, pourquoi un lancement a-t-il besoin de publier quoi que ce soit ?
  2. Comment un acheteur peut-il distinguer le vrai jeton d'une copie portant le même nom ?
  3. Le fait qu'un code source soit vérifié signifie-t-il que le contrat est sûr ?

Explorer

  1. Chaque transfert sur une blockchain publique est visible, mais la visibilité brute n'est pas une divulgation. Un acheteur confronté à des milliers d'adresses ne peut pas savoir lesquelles appartiennent à l'équipe, laquelle est le pool, laquelle est un contrat de verrouillage et laquelle est une plateforme d'échange. La transparence commence lorsque le créateur publie la carte : l'adresse du contrat ou du mint du jeton, les adresses des pools, les contrats de verrouillage, les portefeuilles de trésorerie et d'équipe, les contrats d'attribution progressive et toutes les adresses de programmes ou de proxys. La proposition de Regulation Crypto Assets de la SEC exigerait que les émetteurs utilisant ses exemptions décrivent les « méthodes pour vérifier » l'historique des transactions du jeton (projet de règle 103(b)(7)), une proposition qui traite exactement cette carte comme faisant partie de la divulgation.
  2. C'est l'adresse, pas le nom, qui constitue l'identité du jeton. Le standard ERC-20 (EIP-20, créé en novembre 2015) rend name(), symbol() et decimals() facultatifs, et rien n'empêche quiconque de déployer un second jeton portant le même nom et le même ticker. Les jetons imitateurs et les faux comptes « officiels » exploitent cela (leçon 4.2.4). Publier l'adresse du contrat dans un endroit officiel stable unique, et la répéter de la même manière partout, est la protection la plus simple qu'un lancement puisse offrir. Un acheteur qui vérifie l'adresse plutôt que le ticker évite le piège le plus courant ; un créateur qui change d'adresses sans explication apprend aux acheteurs à cesser de vérifier.
  3. Le code peut aussi être rendu vérifiable. La documentation d'Etherscan explique qu'une vérification de contrat publie son code source sur l'explorateur, où n'importe qui peut confirmer qu'il correspond au bytecode déployé on-chain. Les builds vérifiés de Solana font la même chose en comparant les hachages du programme déployé avec un build reproductible du dépôt public, à l'aide de l'outil solana-verify. La vérification ne prouve que le code publié est le code déployé. Elle ne dit rien sur le fait que le code soit sûr ou équitable, et un programme ou un proxy évolutif peut être remplacé plus tard (leçon 6.3.2). Le projet de règle 103(b)(6) exigerait des émetteurs qu'ils fournissent l'adresse où le code source est disponible, s'ils l'ont publié.
  4. L'offre et les participations sont les prochaines choses que les gens lisent. L'EIP-20 exige que chaque jeton rapporte totalSupply(), et les outils de jetons de Solana rapportent l'offre totale d'un mint. Les listes de détenteurs sont faciles à mal interpréter : les plus grands « détenteurs » sont souvent le pool, un contrat de verrouillage, un contrat d'attribution progressive ou une plateforme d'échange. Étiqueter publiquement ces adresses et expliquer quels soldes appartiennent aux initiés (leçon 6.3.4) transforme un graphique effrayant en un graphique précis. Les jetons qui atteignent une adresse mais ne sont pas brûlés au sens technique continuent de compter dans l'offre totale, ce qui est l'une des raisons pour lesquelles les affirmations de destruction (burn) exigent de la prudence (leçon 6.3.5).
  5. Aux États-Unis, publier des données ne remplace pas des déclarations exactes ; les affirmations qu'un émetteur fait sont ce que le droit des valeurs mobilières, des matières premières et de la protection du consommateur testent (leçons 5.1.7 et 6.3.1). Mais les preuves on-chain sont la manière dont un créateur montre que ses déclarations sont vraies. L'interprétation de 2026 de la SEC (Release No. 33-11412) encourage les émetteurs qui promettent des travaux à divulguer publiquement lorsqu'ils sont achevés, et un hachage de transaction pour un verrouillage, une autorité révoquée ou un déploiement d'attribution progressive est la preuve la plus directe. Dans l'UE, l'article 6(1)(h) du MiCA exige qu'un white paper contienne des informations sur la technologie sous-jacente.
  6. La transparence a des coûts qui méritent d'être nommés. Un portefeuille publié lie une personne ou une entreprise à toutes les transactions passées et futures en provenance de celui-ci, et les grands portefeuilles peuvent attirer le copy-trading et une attention indésirable. Un lancement peut étiqueter les adresses par rôle plutôt que par nom personnel, mais tout ce qu'il publie est permanent, et les transferts entre portefeuilles étiquetés et non étiquetés peuvent généralement être tracés. Une vérification pratique : ouvrez l'explorateur, partez de l'adresse du contrat publiée, et essayez d'identifier le pool, chaque verrouillage, chaque portefeuille d'initié et toute autorité de mise à jour en utilisant uniquement la carte du lancement ; tout ce qui ne peut pas être trouvé à partir de la carte est une lacune dans sa divulgation.

Faits clés

  • Le standard de jeton EIP-20, créé le 19 novembre 2015, rend name(), symbol() et decimals() facultatifs mais exige totalSupply().
  • La vérification de contrat d'Etherscan publie le code source et permet à quiconque de confirmer qu'il correspond au bytecode déployé on-chain.
  • Les builds vérifiés de Solana comparent les hachages du programme déployé avec un build reproductible du dépôt public de sources.
  • Le projet de règle 103(b)(7) de la Regulation Crypto Assets exigerait des émetteurs qu'ils décrivent les méthodes pour vérifier l'historique des transactions du jeton.
  • Le projet de règle 103(b)(6) exigerait des émetteurs qu'ils fournissent l'adresse web du code source, dans la mesure où ils l'ont rendu publiquement disponible.
  • L'article 6(1)(h) du MiCA exige qu'un white paper de crypto-actif contienne des informations sur la technologie sous-jacente.

Exercice neuf, six, trois, un

9RassemblerListez jusqu'à 9 adresses ou éléments de code qu'un acheteur devrait vérifier pour un jeton que vous connaissez ou prévoyez (certaines listes sont plus courtes), tels que le contrat du jeton, le pool, un verrouillage, un contrat d'attribution progressive (vesting) ou une autorité de mise à jour.
6RegrouperClassez-les en 6 catégories : identité du jeton, liquidité, participations des initiés, verrouillages et attributions progressives, contrôle du code et des mises à jour, et éléments n'ayant pas encore d'adresse publique.
3DistillerRéduisez les 6 catégories en 3 groupes : éléments déjà publiés et étiquetés, éléments visibles on-chain mais non expliqués, et éléments qu'un acheteur ne peut tout simplement pas trouver.
1CristalliserRédigez une phrase décrivant l'adresse unique ou la preuve dont la publication améliorerait le plus ce que l’acheteur peut vérifier au sujet de ce jeton.

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

Ouvrir dans l'académie interactive →

EN PT ES ZH JA KO RU DE MS