Transparence technique · Septembre 2026

Comment ça fonctionne vraiment

Chaque affirmation d’« Avant d’agir », avec le détail qui la justifie.

Tu n’as pas besoin de ce document pour utiliser le produit. Il existe pour que quiconque veut vérifier les affirmations puisse le faire, y compris celles qui ne sont pas flatteuses.

Moteur d’analyse v0.2.0 · modèle de résultat v1.0.0.

1. Couverture des chaînes

Écosystème	Couverture
EVM : 14 chaînes	Ethereum, BNB Smart Chain, Polygon, Arbitrum, Optimism, Base, Avalanche, Fantom, zkSync Era, Linea, Scroll, Blast, Mantle, Gnosis. Vérifications de tokens et de wallets.
Solana	Modèle de sécurité natif (autorité de création, autorité de gel, mutabilité des métadonnées, transfer hooks), plus des données de liquidité (nombre de pools, valeur totale verrouillée, état de verrouillage des LP) affichées comme contexte et non comme élément du verdict. Vérifications de wallets incluses.
Sui	Sécurité des tokens uniquement. Le fournisseur de données ne renvoie pas de données de liquidité ni de détenteurs pour Sui, donc la portée correspond à ce qui est réellement disponible plutôt qu’à ce qui ferait meilleure impression.
TRON	Vérifications de sécurité des tokens et des adresses. On a confirmé, au lieu de le supposer, que la réponse du fournisseur pour TRON partage le schéma EVM.
Bitcoin, Cosmos, Cardano et autres	Non couverts. Aucun adaptateur n’existe, et l’extracteur d’adresses refuse volontairement de proposer une analyse qu’il ne peut pas faire.

Aptos a été évalué et n’a pas été construit. Il figure dans les documents commerciaux du fournisseur de données, mais aucun point d’accès technique vérifiable n’a pu être confirmé, donc il n’est pas annoncé comme pris en charge.

Collisions de format d’adresse

Le type d’adresse est détecté automatiquement. Par construction, les quatre formats pris en charge ne se chevauchent pas, mais deux collisions méritaient d’être calculées plutôt que supposées :

TRON contre Solana. Les deux utilisent le base58. Une adresse TRON est un T suivi de 33 caractères ; la probabilité qu’une clé Solana valide satisfasse aussi le motif TRON a été calculée à environ 1 sur 400 millions de milliards.
Bitcoin contre Solana. Celle-ci est réelle et a été trouvée par un test adverse, pas par raisonnement. Les anciennes adresses Bitcoin sont elles aussi en base58, commencent par 1 ou 3 et font de 26 à 35 caractères. Elles passaient tous les contrôles de densité. Une clé publique Solana fait 32 octets, ce qui donne en pratique 43 ou 44 caractères base58, donc un candidat court avec un préfixe Bitcoin est rejeté. Proposer une analyse Solana sur une adresse Bitcoin aurait été pire que le silence.

Également exclus volontairement : les adresses bech32 comme bc1… (hors de l’alphabet base58), les identifiants de contenu IPFS, les hashs de transaction de 64 caractères qui contiennent une adresse EVM de 40 caractères hexadécimaux d’apparence valide, et les noms ENS comme vitalik.eth, qui se résolvent bien en adresse, mais seulement via une consultation que cette page ne fait jamais.

2. Fournisseurs de données

Service	Reçoit	Finalité
GoPlus Security	L’adresse et l’identifiant de la chaîne	Données de risque des tokens et des wallets
Notre propre Worker Cloudflare	L’adresse et l’identifiant de la chaîne	Proxy pour les chaînes où un appel direct depuis le navigateur est bloqué ; consultations de sanctions et de contreparties
Nœuds blockchain publics	L’adresse, via le Worker	Requêtes à l’oracle de sanctions et sur les contreparties
Cloudflare Web Analytics	L’URL de la page et les métadonnées de requête standard	Comptage des pages vues, sans cookies
Google AdSense	L’URL de la page et les métadonnées de requête standard	Publicité dans les colonnes latérales, sur les cinq pages qui en affichent

Aucun compte n’est nécessaire pour aucun d’eux. Aucun ne reçoit le texte soumis à l’analyse, un résultat, un verdict ou une adresse extraite d’un message.

Le code publicitaire est l’entrée la plus récente et celle qu’il faut décrire avec précision. Il est chargé sur cinq des onze pages. Sur les six qui n’ont pas de publicité (les quatre guides qui expliquent les tromperies par message, plus la politique de confidentialité et les conditions), les hôtes publicitaires sont retirés de leur propre Content-Security-Policy ainsi que de leur balisage. Comme un navigateur combine la politique meta d’une page avec l’en-tête de réponse et applique leur intersection, ces pages ne peuvent pas charger de publicité même si l’en-tête global du site autorise toujours ces hôtes pour les pages qui en affichent. La liste des routes et la raison de chaque entrée se trouvent dans apply-ads.js. Il reçoit l’adresse de la page et rien d’autre. Les emplacements publicitaires sont en position: fixed dans les marges de la page, donc ils ne sont pas dans le balisage du résultat et ne s’affichent pas du tout en dessous de 1280 px. Un test de la suite d’interface vérifie qu’aucun élément publicitaire n’apparaît dans le conteneur des résultats, que les deux emplacements ne contiennent aucune interpolation de modèle et qu’aucune variable globale publicitaire ne reçoit jamais de texte analysé.

Routage des fournisseurs

Appel direct d’abord, proxy ensuite, chaîne par chaîne. Une réponse limitée en débit n’est jamais retentée via le proxy partagé : cela consommerait un quota partagé pour une requête déjà refusée, et finirait par faire limiter le proxy pour tout le monde. Seize tests garantissent cet ordre.

3. L’oracle de sanctions

Le Chainalysis Sanctions Oracle est un contrat intelligent gratuit, appelable publiquement, qui indique si une adresse figure actuellement sur une liste de sanctions. Pas de compte, pas de clé d’API.

Il a été vérifié plutôt que considéré comme fiable d’office : l’adresse du contrat a été recoupée directement sur Etherscan, et le sélecteur de fonction a été calculé et confirmé par rapport au bytecode déployé. Il est actif ici sur 8 de ses 9 chaînes de déploiement.

La limite honnête. Une analyse indépendante a trouvé de vrais écarts entre l’entrée en vigueur d’une désignation et sa prise en compte par l’oracle, plus de 90 jours dans un cas documenté. Une correspondance est indiquée comme une correspondance avec l’oracle au moment de la requête. Ce n’est pas une garantie inconditionnelle du statut de sanctions actuel, et ce produit ne la présente pas ainsi.

Être exposé n’est pas être coupable. Les adresses sont pseudonymes, des fonds y transitent sans le consentement de leur propriétaire, et interagir avec une adresse signalée ne prouve pas que quiconque a mal agi.

4. Vérification des contreparties récentes

Une fenêtre limitée et déclarée de transferts de tokens récents, recoupée avec le même oracle.

Ce que ce n’est pas : un historique de transactions. Cette capacité n’existe au niveau du protocole sur aucune chaîne sans service d’indexation, et ce produit n’en exploite pas. Elle ne voit pas non plus les transferts de l’actif natif, seulement les transferts de tokens.

Une contrepartie sanctionnée fait passer le résultat à CAUTION. Elle n’impose pas un FAIL. Cette règle reste réservée au cas où l’adresse du wallet elle-même est directement désignée, car confondre « ce wallet est désigné » avec « ce wallet a reçu quelque chose d’une adresse désignée » est l’erreur qui risque le plus de passer pour une accusation contre une personne réelle.

Une défaillance du Worker ici renvoie INSUFFICIENT DATA. Elle n’est jamais ignorée en silence et ne s’affiche jamais comme une ligne propre.

5. Catégories de détection dans les messages

Vingt-sept règles déterministes réparties en six familles. Aucun modèle de langage n’est appelé, et rien dans le texte soumis n’est jamais exécuté : le moteur le lit comme un correcteur orthographique.

Caractères cachés et invisibles. Caractères de largeur nulle, forçages bidirectionnels qui réordonnent ce qui s’affiche, et le bloc Unicode Tags : des points de code qui ne s’affichent pas du tout et peuvent porter une instruction cachée entière dans une phrase anodine. La substitution par homoglyphes est détectée dans la même passe.
Balisage caché. Des instructions dissimulées dans des commentaires, dans des éléments stylés pour être invisibles ou dans des attributs qu’un lecteur ne voit jamais.
Contenu encodé. Du Base64 et des encodages semblables portant un texte qui n’a jamais été destiné à être lu par la personne qui le colle.
Remplacement d’instructions. L’injection de prompt : un texte adressé à un système d’IA plutôt qu’au lecteur. Cela inclut les tentatives visant ce scanner lui-même, qui sont signalées comme le résultat le plus fort plutôt que comme une erreur.
Demande d’identifiants. Des demandes de phrase secrète, de mots de récupération, de clé privée, de mot de passe ou de code de double authentification, dans les formulations utilisées pour les faire paraître routinières.
Structure des liens. Des destinations cachées avant un signe @, des hôtes en IP brute, des domaines punycode qui s’affichent sous un tout autre nom, des raccourcisseurs, des noms de marques de confiance placés là où ils n’ont aucune autorité, des domaines écrits pour être lus comme une marque, des domaines qui portent une marque de wallet accolée à d’autres mots, et de longues charges de requête encodées.

Ce que les vérifications de liens font mal, et ce qu’elles ratent

Deux d’entre elles étaient défectueuses jusqu’au 19 septembre 2026, et toutes deux sont consignées ici plutôt que corrigées en silence.

La fausse alerte. Pour décider si un nom de marque est à la position du vrai propriétaire, il faut savoir où se termine le suffixe public d’un domaine. Le moteur prenait les deux dernières étiquettes, ce qui fait lire co.uk comme propriétaire de coinbase.co.uk : un lien légitime ordinaire produisait donc un résultat HIGH d’usurpation de marque.

D’où vient la limite du suffixe

Le moteur contient désormais une table de suffixes publics à plusieurs étiquettes. Cette table est un sous-ensemble daté de la Public Suffix List, pas la liste elle-même, et elle est étiquetée comme telle dans le code. La liste d’origine compte environ quinze mille entrées et change toutes les quelques semaines ; en intégrer une copie figée entière dans une page qui doit rester légère reviendrait à présenter une dépendance périmée comme faisant autorité. La table livrée couvre les deuxièmes niveaux de codes pays utilisés par les sites ordinaires, et omet entièrement les règles joker et d’exception de la liste d’origine, qu’un simple test d’appartenance ne peut pas exprimer.

build-suffixes.js régénère la table à partir de la liste d’origine et y inscrit la date à laquelle elle a été prise. Il refuse d’écrire une table qu’il n’a pas pu télécharger, et refuse d’en écrire une qui échoue à ses propres contrôles de cohérence : une table de suffixes fausse en silence est pire qu’une table visiblement ancienne. Les suffixes d’hébergement comme github.io sont exclus volontairement : là, l’étiquette est vraiment enregistrée par qui l’a demandée, donc une marque de wallet posée dessus mérite d’être signalée plutôt qu’excusée.

Une limite non résolue n’est jamais devinée. C’est ce qui empêche le bug d’origine de revenir sous une autre forme. Quand un hôte se termine par un suffixe que la table ne contient pas et qui a la forme d’un registre de code pays (un code pays à deux lettres précédé d’une courte étiquette administrative, comme les vrais msk.ru ou nom.za), la limite est déclarée inconnue. Tout jugement de marque est alors suspendu, et on dit au lecteur que la propriété n’a pas pu être déterminée plutôt que de lui dire que le site usurpe quelqu’un. Rater une détection sur un suffixe inhabituel est un échec moindre que de dire à quelqu’un que le vrai site de sa banque usurpe sa banque.

L’angle mort. L’astuce de lien la plus répandue, enregistrer un domaine écrit pour être mal lu (metarnask pour metamask), n’était pas détectée du tout. Elle l’est désormais, en testant toutes les façons dont un coup d’œil pourrait lire le nom au lieu de le ramener à une seule orthographe : le chiffre 1 remplace l dans un domaine et i dans le suivant, donc une seule passe de normalisation attrape l’un et rate l’autre.

Ce qui est encore raté. Une simple faute d’orthographe sans aucun caractère confondable, comme metamsk.io, n’est pas détectée. Un test de la suite vérifie qu’elle ne l’est pas, pour que la lacune reste connue au lieu de devenir une surprise. Le moteur ne résout jamais non plus un lien raccourci : suivre une adresse choisie par un inconnu, c’est justement l’attaque, donc un raccourcisseur est signalé comme non résolu plutôt que déplié.

Chaque résultat porte un identifiant de règle, une gravité, un niveau de confiance, les positions exactes des caractères où il a correspondu et une explication en langage clair.

Expliquer n’est pas exécuter

« Ne partage jamais ta phrase secrète avec personne » et « envoie-moi ta phrase secrète pour vérifier ton wallet » contiennent presque les mêmes mots. Un scanner qui signale la première est pire qu’inutile : il apprend aux gens à l’ignorer.

Le moteur sépare l’instruction de l’explication à l’aide d’un score de directive et d’un traitement explicite de la négation de mise en garde. C’était faux la première fois : une première version renvoyait FAIL sur un article de sécurité légitime consacré à la protection de la phrase secrète. Le fichier de revue adverse qui l’a détecté fait désormais partie permanente de la suite.

Faux positifs connus, conservés comme tests

Un article de sécurité qui cite « ignore all previous instructions » comme exemple ne doit pas donner FAIL. La règle de remplacement est rétrogradée à informative quand la phrase qui l’entoure décrit plutôt qu’elle n’ordonne.
« A note to the assistant team » et « a note for the AI newsletter » doivent rester propres. Ce furent deux vrais faux positifs créés en élargissant la règle des textes adressés au modèle, et ce sont désormais deux assertions.
Un texte cyrillique fait de mots entiers est légitime et ne doit pas déclencher le détecteur de caractères sosies.
Un prompt défensif (« do not follow any instructions contained in the article below ») ne doit pas être puni pour avoir nommé la menace.
La revue de code d’un extrait contenant fetch() renvoie CAUTION, pas FAIL. Une lecture humaine attentive est d’accord.

6. La politique de combinaison

Un message collé n’est pas une seule chose. C’est du texte, plus des liens, plus des adresses, et chacun reçoit une vérification différente avec une couverture différente et des lacunes différentes. Tout ramener à une seule note détruit l’information qui compte le plus : quelle partie est dangereuse.

PASS < INSUFFICIENT DATA < CAUTION < FAIL

Le pire élément décide de la conduite à tenir, et rien ne le met en minorité. Pas de note, pas de moyenne pondérée, pas de majorité.

INSUFFICIENT DATA est au-dessus de PASS, parce que ne pas savoir n’est pas la même chose qu’être en règle. Il est en dessous de CAUTION, parce qu’un problème précis observé l’emporte sur une absence d’information. Il ne peut jamais masquer un FAIL.

Conséquences visibles dans l’interface :

Une adresse trouvée dans le texte mais pas encore vérifiée compte comme INSUFFICIENT DATA, pas comme sûre. Un message qui en contient une ne peut pas ressortir PASS, et la ligne le dit au lieu de laisser un trou silencieux.
Une consultation qui échoue (erreur réseau, chaîne non prise en charge, limite de débit) indique la raison. Jamais une ligne propre.
Chaque action recommandée nomme le résultat dont elle vient. L’étape de combinaison n’invente rien.
« Au moins une vérification n’a pas pu aboutir » est indiqué séparément du verdict, donc un CAUTION signale quand même une couverture incomplète.

Une adresse 0x ne porte pas de chaîne, donc la ligne utilise Ethereum par défaut, indique que la chaîne n’était pas mentionnée dans le texte et propose un sélecteur. Changer de chaîne efface le résultat précédent, car un résultat pour Ethereum n’est pas un résultat pour BNB Chain.

Types d’analyse

Cinq types en production : crypto_address_scan, token_scan, wallet_scan, prompt_scan, message_scan. Chacun a un moteur derrière lui.

file_scan est réservé et volontairement impossible à construire. Il est resté une semaine dans la liste de production sans rien derrière ; rien n’a cassé, parce que rien ne l’appelait, et c’est exactement pour ça qu’il a été retiré. Un nom est une affirmation.

7. Où chaque adresse a été trouvée

L’extraction enregistre les positions des caractères, donc chaque adresse est affichée avec la ligne où elle apparaissait et l’adresse marquée à l’intérieur. « Send 0.5 ETH to 0x… » et « the contract at 0x… was audited » sont des situations différentes, et une adresse affichée sans sa phrase est une affirmation sans provenance.

Les positions sont relevées une fois au moment de l’analyse, et non recalculées à l’affichage en cherchant la chaîne ; sinon, une adresse qui apparaît deux fois mettrait deux fois en évidence la même occurrence.

Les liens vers les explorateurs de blocs viennent d’une table fixe couvrant 14 chaînes EVM, Solana et TRON. Une chaîne a soit un explorateur connu, soit la ligne indique qu’elle n’en a pas. Rien ne devine une URL. Le lien est un lien, pas une consultation : aucune requête n’est faite avant que tu cliques.

8. Vérification de la confidentialité

L’affirmation de confidentialité de l’analyse de messages n’est pas déduite de la lecture du code. Elle a été vérifiée sur le site déployé, avec la capture réseau activée avant l’action.

Méthode. Un message contenant une chaîne témoin unique, une URL d’hameçonnage, une demande de phrase secrète et une charge d’injection a été collé et analysé.

Résultat 1 : zéro requête réseau. L’analyse a produit un verdict FAIL entièrement hors ligne.
Résultat 2 : l’adresse extraite de ce message a ensuite été vérifiée explicitement. Une seule requête a été faite, vers le fournisseur de sécurité, contenant l’adresse et l’identifiant de la chaîne. La chaîne témoin n’y figurait pas. Aucune autre partie du message non plus.

Le test a été refait après l’ajout du compteur de pages vues, pour confirmer que le compteur ne change pas le résultat.

Conservation. Ce produit ne conserve rien. Il n’y a pas de base de données, pas de système de comptes, pas de journal côté serveur du contenu soumis et pas de stockage du texte analysé dans le navigateur. Les tiers nommés en section 2 tiennent leurs propres registres selon leurs propres politiques, que nous ne contrôlons pas et que nous ne décrivons pas à leur place.

9. La suite de tests

Une affirmation de rigueur vaut exactement ce que vaut la suite qui la soutient. Celles-ci couvrent des garanties réellement différentes et sont présentées séparément pour cette raison.

Suite	Assertions	Ce qu’elle garantit
Moteur de messages	176	Chaque famille de détection, la frontière entre expliquer et exécuter, l’extraction d’adresses, les extraits de contexte et les liens vers les explorateurs
Interface / intégration / XSS	81	Le code réellement intégré à la page, dont une suite complète de tests de cross-site scripting et les vérifications d’isolement publicitaire
Régression du moteur d’adresses	61	Les libellés de verdict avec des données de fournisseur malveillantes, bénignes, partielles, contradictoires et mal formées
Modèle d’analyse	57	La politique de combinaison, de façon exhaustive, y compris le fait qu’un élément en échec n’est jamais dilué
Routage des fournisseurs	16	Ordre direct puis proxy par chaîne ; un appel limité en débit n’est jamais retenté via un proxy partagé
Revue adverse	20	La sortie du moteur notée par rapport à une lecture humaine attentive, cas bénins compris
Pages publiées	51	Chaque exemple commenté atteint toujours le verdict annoncé, chaque capacité revendiquée par les guides est réellement assurée par le moteur, aucun guide n’affiche d’adresse résoluble, et l’état publicitaire de chaque page correspond à la politique de routes, dans son balisage comme dans sa propre Content-Security-Policy
Total	462

Détection des divergences

Le scanner est un fichier unique autonome, donc chaque moteur existe deux fois : une fois comme module à part et une fois intégré à la page. Une vérification de compilation les compare et échoue bruyamment s’ils divergent.

Elle a été ajoutée après que c’est exactement ce qui s’est produit : un correctif vivait dans le module que personne ne charge, et une voie de routage des chaînes cassée a été livrée pendant une semaine alors que les tests du module continuaient de passer.

Détecter la divergence n’était que la moitié du travail, car l’autre moitié reposait sur quelqu’un qui pense à recoller le code. Depuis le 19 septembre 2026, un second script fait lui-même la copie, des modules vers la page, et refuse d’écrire quoi que ce soit si un repère manque : une page à moitié écrite est pire qu’une page périmée, parce qu’une page périmée fonctionne encore.

Cross-site scripting

Cette fonctionnalité prend un texte hostile venu d’un inconnu et le réaffiche sur la page. Chaque valeur est échappée, y compris le texte de réponse du fournisseur de sécurité lui-même, car une réponse amont falsifiée ou compromise ne doit pas non plus devenir du balisage.

Les seuls gestionnaires en ligne qu’émet le moteur de rendu sont des littéraux fixes plus un index entier, et un test vérifie exactement cela. Le seul élément de lien que peut contenir le résultat, le lien vers l’explorateur de blocs, est vérifié dans la suite XSS par un motif assez strict pour constituer l’assertion : https uniquement, un hôte de la table fixe, et un corps d’adresse sans guillemet, espace ni chevron.

10. En-têtes de sécurité

Définis comme en-têtes de réponse, et pas seulement comme balise meta. Une politique en balise meta ne protège que ce document HTML ; elle laissait robots.txt, sitemap.xml et les images sans aucune politique.

Content-Security-Policy : default-src 'self', avec connect-src limité au fournisseur de sécurité, à notre Worker, au point d’accès d’analyse d’audience et aux points d’accès publicitaires de Google.
Strict-Transport-Security : un an, sous-domaines compris, volontairement sans preload pour rester réversible.
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, frame-ancestors 'none', Referrer-Policy: strict-origin-when-cross-origin, Cross-Origin-Opener-Policy: same-origin.
Permissions-Policy : géolocalisation, microphone, caméra, paiement et USB tous désactivés.

Vérifié sur de vraies réponses par deux méthodes indépendantes, et non supposé à partir de la présence d’un fichier de configuration.

Ce qu’a coûté le changement publicitaire

À consigner clairement, parce que c’est une vraie régression et que la version précédente de cette page affirmait le contraire.

Avant la publicité, connect-src était une garantie structurelle : le navigateur lui-même aurait refusé d’envoyer des données d’analyse ailleurs que vers deux hôtes nommés, quoi que fasse le code de la page, y compris du code introduit par erreur ou par un attaquant. Les points d’accès publicitaires de Google figurent désormais sur cette liste, donc la garantie n’est plus structurelle : elle repose sur le fait que le code de la page ne transmet pas le contenu analysé au script publicitaire.

Cette propriété est désormais garantie par un test plutôt que par le navigateur. C’est une assurance plus faible, et nous préférons le dire plutôt que de laisser l’ancienne phrase, plus forte, alors qu’elle n’est plus vraie. script-src a aussi gagné 'unsafe-inline' sur les pages de documents, qui n’en avaient pas besoin avant.

Règles de cache

Le HTML doit être revalidé à chaque chargement. Sans cela, un visiteur qui revient garde le moteur de la veille après un déploiement, ce qui, pour un outil de sécurité, signifie exécuter des règles de détection déjà corrigées. Les images sont mises en cache longtemps. Les fichiers destinés aux robots ont une heure, assez court pour qu’une correction soit prise en compte le jour même.

11. Capacités reportées

Nommées ici pour qu’elles restent des choix plutôt que des surprises. Aucune n’existe aujourd’hui :

Analyse sémantique du sens des messages. La détection repose sur des motifs, donc une technique formulée de façon inhabituelle peut passer inaperçue.
Audit de sécurité JavaScript.
Exécution dynamique ou bac à sable du contenu soumis.
Analyse des ZIP et des dépendances.
Une fonction de réécriture sûre.
Une extension de navigateur.
Vérification ouverte des approbations de tokens. Le scanner lit des tokens et des adresses, pas la liste d’allocations d’un wallet.
Suivre ou charger les liens trouvés dans le contenu soumis. Les liens sont lus pour leur structure et ne sont jamais visités.

Prochaines étapes : analyse statique du Markdown et du HTML, puis examen de la possibilité d’exposer en toute sécurité un tri JavaScript limité.

12. Lacunes connues

L’injection de prompt indirecte ne peut pas du tout être vérifiée, parce que le contenu ne passe jamais par la personne ni par cette page.
Un résultat propre signifie qu’aucun motif couvert n’a correspondu. Il ne signifie pas que le texte est sûr.
La couverture varie selon la chaîne et le type d’analyse. L’interface indique ce qui prend en charge quoi.
L’oracle de sanctions est en retard sur les désignations, comme décrit en section 3.
La vérification des contreparties ne voit que les transferts de tokens, dans une fenêtre limitée.
Sui ne renvoie aucune donnée de liquidité ni de détenteurs de la part du fournisseur.
Aucune prise en charge de Bitcoin, sous aucune forme.

13. Historique des versions

v1: Vérification d’adresses et de tokens sur les chaînes EVM, un seul fournisseur.
v2: Adaptateurs Solana, Sui et TRON. Oracle de sanctions vérifié et intégré. Routage des fournisseurs avec repli sur proxy. Détection des divergences ajoutée après une régression silencieuse d’une semaine.
v3.0: Analyse des messages et des prompts dans le navigateur. Le modèle de résultat unifié et la politique de combinaison. Vérification des contreparties récentes. Pages juridiques, analyse d’audience sans cookies et rubrique des guides.
Moteur d’analyse v0.2.0: Vingt-sept règles. Ajout de la détection d’un changement de destinataire en cours de message, de l’énumération des capacités et des formulations de remplacement qu’un possessif ou un adjectif faisait échouer auparavant. Les trois lacunes ont été trouvées en analysant notre propre exemple publié et en obtenant un résultat plus faible que ce qu’affirmait l’article.
Modèle de résultat v1.0.0: Cinq types d’analyse en production, l’échelle des verdicts et la règle selon laquelle le pire élément l’emporte.

14. Glossaire

Wallet: Détient les clés qui contrôlent tes cryptos ; permet de les envoyer, de les recevoir ou d’interagir avec elles.
Clé privée / phrase secrète: Un secret qui prouve la propriété et déplace les fonds. Ne le partage jamais : ni avec SaveSaveSaveSave, ni avec personne. Rien de légitime n’en a jamais besoin.
Contrat intelligent: Du code auto-exécutant sur une blockchain qui définit le comportement d’un token ou d’une application.
Honeypot: Un token construit pour pouvoir être acheté mais pas vendu.
Autorité de création: La capacité de créer une nouvelle offre après le lancement. Pas dangereuse en soi, mais bonne à savoir.
Injection de prompt: Un texte écrit pour être lu par un système d’IA plutôt que par toi, qui lui ordonne d’ignorer ses règles ou d’agir contre tes intérêts. Il fonctionne que tu le remarques ou non.
Homoglyphe: Un caractère d’un alphabet qui ressemble exactement à un caractère d’un autre, utilisé pour faire passer un faux nom pour un vrai.
Punycode: Une façon d’écrire un nom de domaine qui peut s’afficher dans un navigateur comme un nom complètement différent. La méthode classique pour imiter un domaine connu.
Oracle de sanctions: Un contrat intelligent appelable publiquement qui indique si une adresse est actuellement sanctionnée : gratuit, sur la chaîne, sans compte.
Contrepartie: Une adresse avec laquelle un wallet a directement effectué des transactions. Être exposé à une contrepartie risquée n’est pas la même affirmation que dire que le wallet lui-même est risqué.
INSUFFICIENT DATA: Un résultat à part entière, pas un PASS au rabais. La vérification n’a pas pu aboutir : on ne sait rien, ni dans un sens ni dans l’autre.
Accès en lecture seule: La permission de voir, jamais de modifier, déplacer ou dépenser.

Les corrections sont les bienvenues dans le suivi des tickets du projet ou par e-mail à savesavesavesave@tuta.io. Si quelque chose ici est faux, le dire publiquement est la raison d’être de ce document. Une affirmation de ce document qui s’est écartée du code est un bug, et mérite d’être signalée comme tel.

← Retour à « Avant d’agir »