Anatomie d’un « rug pull »

Source de référence EN · P07-L08 · durée estimée : 45 minutes · needs_review

Objectifs pédagogiques :

• Reconstituer une séquence d’événements historiques rapportés par une source sans biais rétrospectif.
• Séparer les symptômes, le mécanisme et l’attribution de l’acteur.
• Calculer la conséquence sur la profondeur d’un retrait proportionnel fictif.

Un effondrement de prix peut révéler un changement économique sérieux sans en révéler la cause. Un créateur retirant la liquidité, la compromission d’un compte privilégié, des ventes ordinaires dans un pool peu profond et un échec d’acheminement peuvent produire des écrans superficiellement similaires. Cette leçon vous apprend à reconstituer les changements et à classer les éléments de preuve avant d’attribuer un récit.

« Rug pull » est une conclusion sur un comportement, pas une unité de mesure. Apprenez à décrire ce qui a changé, qui pouvait effectuer l’action concernée, ce que les enregistrements établissent réellement et ce qui reste inconnu. Un constat précis et limité est plus utile qu’une accusation construite à partir d’un graphique.

Séparer le symptôme, le mécanisme et l’acteur

Commencez par un symptôme : les réserves ont diminué, un échange a échoué, une autorité a changé ou un détenteur a transféré des jetons. Examinez ensuite un mécanisme. La liquidité a-t-elle été retirée via une position, des jetons ont-ils été vendus, une permission a-t-elle été exercée ou une interface a-t-elle cessé de renvoyer des données ? Demandez-vous enfin à qui attribuer l’action. Un signataire de transaction identifie la participation d’un compte ; il n’établit ni la personne qui l’utilise ni une éventuelle compromission des identifiants d’accès.

Gardez trois colonnes dans vos notes. « Diminution des réserves » appartient à la colonne des observations si un instantané correspondant l’étaye. « Retrait de liquidité » nécessite des éléments de preuve au niveau de l’opération. « Le créateur a intentionnellement volé les fonds » nécessite des éléments d’attribution et d’intention au-delà d’un graphique de prix. Si la source fournie rapporte seulement une exploitation de faille, conservez cette qualification sans la transformer en faute du créateur.

L’autorité sur le jeton et le contrôle du pool sont des périmètres distincts. Une autorité d’émission (mint) révoquée ne dit pas si une position du pool peut être retirée. Une affirmation de verrouillage de liquidité nécessite son propre périmètre : position exacte, fraction concernée, mécanisme, expiration et exceptions éventuelles. Même une restriction vérifiée sur une action ne peut établir que toutes les autres sont inoffensives. Ne remplacez pas ces questions distinctes par un score général de sûreté.

Reconstituer l’état autour d’un événement délimité

Précisez le réseau et l’actif ou protocole exact, la fenêtre temporelle, la source et la couverture de mesure. Choisissez une observation avant et une observation après qui mesurent les mêmes objets. Réserves de jetons, réserves de cotation, positions de liquidité et permissions sont des variables différentes. Si un instantané agrège plusieurs pools tandis qu’un autre décrit un seul pool, leur différence n’est pas une variation valide d’un pool unique.

Un tableau d’événements rigoureux contient l’heure de l’événement, le repère des éléments de preuve, l’action rapportée, la conséquence et la limite de confiance. Les instantanés manquants restent manquants. Ne complétez pas un solde antérieur à partir d’un article ultérieur ou d’un tableau de bord actuel. Si aucun enregistrement figé des réserves n’est fourni, vous pouvez reconstituer la chronologie d’incident rapportée par l’éditeur, mais pas calculer indépendamment les pertes historiques du pool ou l’exécution des traders.

Un graphique de prix seul ne distingue pas un retrait de liquidité d’une vente. Retirer proportionnellement des réserves peut laisser leur rapport inchangé tout en réduisant la profondeur. Vendre dans un pool à produit constant change ce rapport par une autre opération. Pour les distinguer, recherchez la transaction et les changements au niveau des positions, pas seulement une bougie descendante.

Séparer le moment de la connaissance de celui de l’événement

Un rapport historique comporte au moins deux horloges. Le moment de l’événement est celui auquel l’action aurait eu lieu selon la source. Le moment de la connaissance est celui où l’analyste a eu accès aux éléments de preuve la concernant. Un article publié demain peut décrire un événement d’aujourd’hui ; cela ne rend pas son contenu accessible à un analyste aujourd’hui.

Cette distinction compte dans l’évaluation d’affirmations d’alerte précoce. Si un bilan ultérieur attribue un événement à la compromission d’un compte privilégié, vous ne pouvez pas supposer qu’un observateur connaissait cette attribution avant la publication du rapport. Une reconstitution équitable indique « le rapport ultérieur décrit cet événement à cette heure » et précise séparément ce qu’un observateur antérieur pouvait inspecter. Lorsque la publication n’est connue qu’à la date près, n’inventez pas d’heure précise de mise en ligne.

Votre investigation peut être utile sans revendiquer de pouvoir prédictif. Une chronologie d’atténuation montre quels contrôles auraient changé après l’incident selon la source. Elle ne prouve pas qu’une alerte précise aurait empêché l’incident ni que les futurs protocoles ayant des contrôles similaires sont sûrs.

Utiliser prudemment le cas historique comparatif

L’exemple historique ci-dessous est l’exploitation du protocole Raydium de décembre 2022, utilisée pour comparer une compromission de compte privilégié à un récit de retrait par le créateur. Il n’est pas présenté comme un rug pull d’un créateur de memecoin. Le bilan officiel est le récit de l’éditeur primaire ; cette leçon n’a pas rejoué indépendamment le registre.

Un rapport de première partie peut établir ce que son éditeur a déclaré. La confirmation indépendante de chaque déclaration nécessite les transactions correspondantes, un état archivé et un décodage reproductible. Conservez cette distinction dans le panneau d’éléments de preuve. On peut citer un rapport officiel tout en indiquant que son explication proposée de l’intrusion initiale n’était pas établie.

Les comparaisons historiques doivent transmettre une méthode, pas un verdict. Demandez quelle permission privilégiée était impliquée, quelle remédiation l’aurait supprimée ou déplacée selon la source, et quels éléments seraient nécessaires pour établir indépendamment les pertes et le contrôle. Appliquez ensuite les mêmes questions à un cas de memecoin seulement après avoir obtenu ses propres enregistrements.

Modéliser la profondeur sans prétendre mesurer l’incident

Pour le modèle fictif distinct, utilisez un pool à deux réserves et à produit constant sans frais, avec une réserve de base X et une réserve de cotation Y. Une entrée de cotation q renvoie Xq/(Y+q) unités de base. Le prix marginal de cotation est Y/X. C’est le même modèle restreint introduit dans P07-L03 [S-PRICING] ; ce n’est pas une reconstitution des pools Raydium exploités.

Un retrait proportionnel modifie X et Y par le même facteur. Le rapport peut rester inchangé tandis qu’un ordre fixe devient important par rapport aux réserves restantes. Cela illustre pourquoi un prix affiché stable ne suffit pas à prouver une profondeur exécutable stable. Les frais, la liquidité concentrée, les autres circuits, les restrictions de transfert et les transactions intermédiaires nécessitent d’autres calculs.

Ne confondez pas les conclusions du modèle avec les faits observés. Le modèle montre une conséquence mécanique possible sous des hypothèses déclarées. Le rapport historique fournit une chronologie. Aucun ne fournit un rendement mesuré, une recommandation d’investissement ou l’identification d’un auteur de rug pull de memecoin.

• Symptôme : changement visible pouvant avoir plusieurs causes.
• Mécanisme : opération reliant un changement d’état à son résultat.
• Attribution : lien étayé entre une action et un acteur.
• Moment de l’événement : heure rapportée d’une action.
• Moment de la connaissance : instant où les éléments de preuve sont devenus accessibles à un observateur.
• Bilan d’incident : récit rétrospectif avec ses propres limites de preuve.
• Profondeur : réserves disponibles pertinentes pour un ordre et un circuit spécifiés.

ENREGISTREMENT DE SOURCE HISTORICAL — HIST-P07-08. Résumé éditorial figé du bilan officiel Raydium [S-INCIDENT], publié le 17 décembre 2022 et inspecté le 30 septembre 2026. Toutes les heures ci-dessous sont des heures d’événement UTC rapportées par l’éditeur. Aucun rejeu de transaction, instantané de réserve ou attribution humaine indépendante n’est fourni.

L’article rapporte une exploitation impliquant des fonctions privilégiées et la comptabilisation des frais. Il évoque une explication possible de l’intrusion sans établir le vecteur initial exact. Il s’agit d’une comparaison d’exploitation de protocole, pas d’une classification documentée de rug pull par un créateur.

MODÈLE ILLUSTRATIVE — FIX-P07-08. Unités fictives de base et de cotation ; aucune réserve historique Raydium.

Supposez des frais nuls, des transferts sans restriction, aucun autre circuit et aucune transaction intermédiaire. Appliquez séparément une entrée hypothétique de cotation de 1 unité à chaque état initial.

DÉCLARATION DE SOURCE OBSERVED (OBSERVÉ) : H1–H4 sont des déclarations inspectables dans le rapport cité de l’éditeur. Leurs heures d’événement sont rapportées par la source, pas vérifiées indépendamment ici.

INFERRED (INFÉRÉ) : dans FIX-P07-08, le retrait proportionnel préserve le rapport marginal mais augmente la prime moyenne d’exécution pour l’entrée spécifiée. Cela découle du modèle fourni, pas de l’incident.

UNKNOWN (INCONNU) : instantanés effectifs des réserves historiques des pools, effets de chaque transaction décodés indépendamment, vecteur initial exact d’intrusion et connaissance d’un observateur précis avant la publication.

INSUFFICIENT EVIDENCE (ÉLÉMENTS DE PREUVE INSUFFISANTS) : les enregistrements historiques n’établissent ni rug pull d’un créateur de memecoin, ni alerte prédictive antérieure, ni sûreté après remédiation. Un calcul fictif de réserves ne peut établir les pertes réelles de l’incident.

Attribuer l’étiquette « rug pull » à partir d’un graphique en baisse ; traiter des identifiants d’accès compromis comme preuve de l’intention du créateur ; confondre date de publication et heure d’événement ; calculer les réserves historiques à partir de données fictives ; et interpréter un rapport de réserves inchangé comme une profondeur inchangée.

Les données sont H1–H4 et FIX-P07-08. Travaillez hors ligne sans connecter de portefeuille.

1. Écrivez les quatre événements rapportés dans l’ordre chronologique et conservez la précision approximative.
2. Évaluez l’affirmation « À 11:00 UTC le 16 décembre, l’analyste connaissait déjà l’attribution du bilan officiel. » Utilisez uniquement les enregistrements fournis.
3. Calculez la sortie de base et le prix moyen de cotation pour q=1 dans les deux états fictifs. Comparez chaque prix moyen à son prix marginal initial.
4. Rédigez un constat d’incident délimité en trois phrases et listez les enregistrements supplémentaires nécessaires pour tester indépendamment une affirmation de retrait de liquidité.

• Identifier séparément l’objet, le mécanisme et l’affirmation d’attribution.
• Consigner la source, l’heure de l’événement et les limites du moment de la connaissance.
• Comparer des états avant/après correspondants.
• Conserver les causes inconnues et les explications alternatives.
• Séparer les calculs illustratifs des mesures historiques.
• Rapporter la conclusion limitée étayée sans appel financier.

Reconstituer un incident consiste à préserver la chaîne reliant la source à l’événement puis au changement d’état. Un bilan peut enseigner cette méthode sans prouver un rug pull par un créateur. Les résultats historiques ne peuvent fournir rétroactivement des éléments de preuve à un observateur antérieur.

Une étiquette ne remplace pas un mécanisme. Un prix marginal stable peut coexister avec une profondeur réduite. Attribution par l’éditeur, vérification indépendante et intention humaine restent des affirmations distinctes.

Construire une chronologie H1–H4 UTC à partir du rapport de l’éditeur ; séparer la piste des heures d’événement de celle des dates de publication, étiqueter H4 comme approximatif et l’attribution comme rapportée par la source. Ajouter un encart distinct explicitement illustratif pour FIX-P07-08, avec rapports marginaux égaux et sorties q=1. Ne jamais tracer les réserves fictives comme des mesures historiques de l’incident.

Règles de livraison visuelle : bleu marine/noir, accents cyan/bleu électrique/violet, unités et incertitude explicitement étiquetées. Utiliser des graphiques déterministes ou SVG, pas des captures fabriquées. À 390 px, empiler les annotations et fournir le tableau de données comme alternative textuelle ; vérifier 768 px et ordinateur ultérieurement. En arabe, localiser les étiquettes et la mise en page avec un RTL natif, en isolant les adresses/hashes LTR et en conservant le sens réel des transferts et de la chronologie. Utiliser uniquement le logo officiel BlockAssay fourni si une identité de marque est ajoutée. Aucun visuel ni rendu mobile/RTL n’est revendiqué prêt.

Utilisez RADAR uniquement si le réseau, l’actif exact et les champs requis sont pris en charge et si leur provenance est visible. Il s’agit d’une inspection pédagogique en lecture seule, pas d’une transaction ou d’un lancement de jeton. Utilisez le jeu de données hors ligne fourni si l’accès ou les données sont indisponibles ; les informations manquantes restent inconnues. Une future action Ouvrir dans BlockAssay nécessite un acheminement runtime validé et une couverture des sources. Aucun appel exécutable sur un actif n’est fourni pour les identifiants illustratifs. La participation à Academy et le statut commercial ne changent jamais les observations Radar.

• Raydium — Bilan détaillé et prochaines étapes — Incident de décembre 2022 et chronologie d’atténuation rapportés par l’émetteur ; ni attribution indépendante ni constat de rug pull de memecoin. Vérifié le 2026-09-30.
• Tarification Uniswap v2 — Tarification d’un pool à deux réserves et à produit constant ; pas un modèle de chaque lancement ou pool. Vérifié le 2026-09-30.
• Solana — Définir l’autorité — Rôles d’autorité spécifiques et suppression d’une autorité sélectionnée. Vérifié le 2026-09-30.

Les tableaux et jeux d’exercice sont du matériel pédagogique original sauf désignation explicite HISTORICAL. Les identifiants fictifs sont volontairement invalides comme adresses de chaîne de blocs. La documentation étaye les définitions des mécanismes, pas les valeurs d’exercice inventées. L’inspection des sources est une recherche éditoriale, pas une mesure en direct sur la chaîne. Les sources peuvent changer ; les revoir avant publication.

P07 est terminé. Revoyez votre chronologie d’événements, votre modèle de liquidité et vos limites de preuve, puis revenez au tableau de bord Academy. Les laboratoires distincts conservent leurs prérequis indiqués.