Liste de vérification des preuves d’une prévente crypto

Contenu éducatif uniquement. Les actifs crypto peuvent perdre de la valeur, devenir illiquides ou ne pas fonctionner comme prévu. Ce contenu n’est ni un conseil financier, juridique, fiscal ou d’investissement, ni une recommandation.

1. Faire correspondre le réseau et l’adresse exacte

Commencez par le nom de la chaîne, l’environnement réseau et l’adresse complète du contrat. Comparez l’adresse caractère par caractère entre la politique de sécurité anglaise de l’émetteur, l’explorateur de blocs concerné et une source technique indépendante. Un ticker, un logo, un lien raccourci ou un nom de portefeuille ne prouvent pas l’identité. Conservez l’URL de l’explorateur et l’heure de la vérification. Confirmez que le contrat est déployé sur le réseau prévu et ne confondez pas adresse proxy et adresse d’implémentation. Une différence impose l’arrêt de la vérification, ce n’est pas un simple détail visuel.

2. Noter la date, la portée de l’audit et le bytecode déployé

Un audit constitue une preuve limitée à une portée et à une date données. Lisez la date, la référence de commit ou de bytecode, les contrats inclus, les exclusions, les niveaux de gravité et l’état des corrections. Lorsque c’est possible, comparez le bytecode déployé ou le code vérifié avec le rapport. Auditer un code qui n’est pas le code déployé ne répond pas à la même question. Pour un proxy, examinez l’implémentation, l’administrateur du proxy, les droits de mise à niveau, de pause et de création, ainsi que les autres pouvoirs privilégiés. Distinguez une limite temporisée, multisignature, abandonnée, documentée ou simplement annoncée. « Audité » ne signifie ni sûr, ni certifié, ni immuable.

3. Séparer allocation, vesting et liquidité

Traitez l’allocation des tokens, le vesting et la liquidité comme trois pistes de preuve distinctes. Cherchez un tableau d’allocation daté, un mécanisme de distribution et l’acteur capable de modifier le calendrier. Vérifiez si le vesting est imposé on-chain ou seulement décrit dans le texte. La liquidité doit être reliée à un lieu d’échange, une paire ou un pool, des conditions de verrouillage, une date de déverrouillage, une profondeur et un contrôle des actifs. « Liquidité prévue » ne constitue pas une preuve. En cas de dossier incomplet, écrivez « non démontré » plutôt que de combler le vide par une supposition. Les risques de perte, dilution, illiquidité et contrôle du contrat restent possibles.

4. Employer les normes avec précision

FIPS 203 est une norme du NIST qui spécifie ML-KEM, un mécanisme d’encapsulation de clés. Ce n’est ni une certification de produit, ni un audit de contrat, ni une recommandation de token, ni la preuve qu’une implémentation respecte toutes les exigences. Consultez directement la publication primaire du NIST et séparez la description d’une norme de la preuve distincte de conformité d’un produit. Un nom d’algorithme, une phrase de feuille de route ou un logo partenaire ne doit pas devenir une affirmation de certification. Cette page cite la norme comme aide à la lecture et ne certifie ni BMIC Research ni un produit. publication primaire NIST FIPS 203.

5. Protéger le portefeuille et la trace de transaction

Ne communiquez jamais une phrase de récupération, une clé privée ou un code de restauration à un site, un support ou un évaluateur. Avant de signer, contrôlez dans le portefeuille le réseau, le contrat destinataire, l’identifiant de chaîne, l’autorisation du token et les détails de la transaction. Si une transaction est en attente, consultez l’explorateur et le nonce avant toute nouvelle action ; ne répétez pas automatiquement et ne renvoyez pas parce qu’une page affiche un échec. Les messages urgents, adresses copiées, pages de vérification fausses et demandes de connexion sont des risques de phishing. Gardez le hash, la page et la date sans publier d’identité personnelle.

6. Vérifier séparément l’éligibilité locale

La langue, le lieu de résidence, l’accès à une page ou une connexion réussie au portefeuille ne suffisent pas à établir une éligibilité locale. L’autorité japonaise des services financiers explique dans ses documents primaires que les questions de classification et d’enregistrement peuvent dépendre des faits et du cadre applicable. Il faut consulter les sources primaires et un conseil local qualifié pour une situation individuelle. Cette page ne détermine pas si BMIC Research, un token ou une offre est éligible au Japon ou ailleurs. Une traduction éducative ne doit pas devenir une promotion financière et les incertitudes doivent rester visibles. document primaire de la FSA japonaise.

7. Publier un journal de preuves, pas un verdict

Pour chaque contrôle, consignez l’URL, la date, l’affirmation exacte, le résultat observé, la limite et la question suivante. Classez les faits comme actuels, historiques, indisponibles ou non démontrés. Conservez les contradictions plutôt que de choisir la version la plus flatteuse. Une conclusion utile peut être : adresse concordante, portée d’audit limitée, vesting et liquidité non démontrés, éligibilité locale à confirmer par un conseil indépendant. C’est plus utile qu’une note ou qu’une affirmation de sécurité. BMIC Research est mentionné seulement comme association d’émetteur dans ses propres documents ; cette checklist générique n’est pas une recommandation de produit.

Liste de vérification des preuves d’une prévente crypto | Méthode neutre