Compétence d'analyse des arnaques à token

Tu effectues une analyse médico-légale on-chain pour déterminer si un token (ou un ensemble de tokens) est une arnaque, un rug-pull ou un soft-rug. Le résultat est un rapport écrit enregistré dans le stockage fichier de l'utilisateur plus un verdict en chat.

Quand utiliser cette compétence

• L'utilisateur fournit une ou plusieurs adresses de contrat de token et demande une évaluation du risque.
• L'utilisateur mentionne une narrative de « migration » / « redéploiement » / « nouveau contrat ».
• L'utilisateur nomme un compte Twitter/X du projet et veut vérifier les affirmations par rapport à la réalité on-chain.
• Comparaison d'anciens contrats avec de nouveaux contrats du même équipe.

Principe fondamental

Le narrative est du bruit. L'état on-chain est le signal. Chaque affirmation de l'équipe doit être vérifiée par rapport à ce que le contrat et le portefeuille du déployeur ont réellement fait. Si les deux entrent en conflit, la chaîne gagne.

MAIS : la propreté on-chain ≠ pas une arnaque. Une équipe peut déployer un LayerZero OFT ou un ERC-20 parfaitement propre, le confier à un multisig, et toujours exécuter un pump-and-dump classique via coordination CEX et offre concentrée. Tu DOIS toujours exécuter le passage d'intelligence off-chain (Étape Finale-1) avant d'émettre un verdict, sinon tu sous-évalueras les vrais cas de manipulation.

Étape 0 — Lis les docs de déploiement de la plateforme AVANT de juger les affirmations de tokenomique

Avant de faire toute affirmation sur ce qu'une équipe « ne pourrait pas » ou « aurait dû » configurer, lis la documentation de déploiement pour la plateforme de lancement. Sinon tu manqueras les capacités et les appâts du narrative de l'équipe. Identifie la plateforme en regardant le champ context de allData() (par ex., "interface":"clanker.world"), l'adresse de la fabrique de déploiement, ou l'ABI du token (admin/originalAdmin/allData/isVerified est de style Clanker).

Lectures prioritaires par plateforme :

• Clanker v4 (allData() context = clanker.world, factory 0xe85a59c628f7d27878aceb4bf3b35733630083a9):
  • https://clanker.gitbook.io/clanker-documentation/general/token-deployments — aperçu : ERC-20 de 100B, extensions jusqu'à 90% de l'offre.
  • https://clanker.gitbook.io/clanker-documentation/authenticated/deploy-token-v4.0.0 — charge utile de déploiement complète (vault, airdrop, frais, jusqu'à 7 destinataires de récompense, config de pool).
  • https://clanker.gitbook.io/clanker-documentation/references/core-contracts/v4 — internes de ClankerVault / extension Airdrop.
  • Ce que tu DOIS savoir avant de juger :
    • La tokenomique (allocations, lockups, vesting, multiples partages de récompense, token appairé personnalisé, capitalisation initiale, frais statiques/dynamiques) est définie dans la charge utile de déploiement. Une équipe ne peut pas dire « on a dû redéployer parce qu'on ne pouvait pas configurer la tokenomique » — Clanker v4 supporte tout cela en une transaction.
    • Lockup vault min 7 jours, lockup airdrop min 1 jour.
    • Max 90% de l'offre sur tous les extensions (le reste va à la LP).
    • Le bytecode du token étant identique entre les déploiements est attendu (c'est un modèle de fabrique) — ne flagge pas l'identité des bytecodes comme un drapeau rouge en soi. Les différences de configuration vivent dans la charge utile de déploiement, pas dans le code d'exécution du token.
• Bankr / Doppler / Scheduled Multicurve : partages de bénéficiaires du déployeur, pas de migration, pool verrouillée, répartition des frais 95/5.
• Zora / Virtuals / Pump.fun : spécifique à la plateforme, cherche les docs officiels via search_tool.
• Tokens multichain LayerZero OFT (la source a import "@layerzerolabs/oft-evm/contracts/OFT.sol" et peers(uint32), setPeer, send, setEnforcedOptions) : pattern multichain standard. setPeer par owner est le principal pouvoir admin en direct — si les signataires colludent, ils peuvent ajouter une chaîne pair malveillante et frapper via _credit. Les pairs existants correspondant sur les exploreurs de chaîne = config de pont légitime. Endpoint LZ V2 sur Base : 0x1a44076050125825900e736c501f859c50fE728c.

Enregistre cette étape dans ton rapport. La section « Claim vs reality » doit citer une capacité spécifique des docs que l'équipe aurait pu utiliser et a choisi de ne pas utiliser.

Carte des outils (à peu près dans l'ordre d'utilisation)

1. token_search (identifier_type=address, chain=...) — données de marché de base : prix, mcap, volume, changement 24h, nombre de détenteurs, drapeau de scan de sécurité. Définis include_chart=false, include_market_data_image=false pour garder le contexte léger.

2. get_token_launch_info — si le token a été déployé via Bankr/Doppler, tu obtiens le portefeuille du déployeur + handle Twitter + URL du tweet gratuitement. Essaie toujours d'abord même si tu penses que c'est Clanker ; l'outil s'exécute proprement sur non-correspondance.

3. get_contract_abi (chain=...) — confirme que l'adresse est un vrai contrat et énumère les fonctions de lecture/écriture. Flagge les fonctions dangereuses : mint, crosschainMint, setOwner, updateAdmin, blacklist, setFee, pause, updateImage, updateMetadata. Pour les OFTs, note setPeer / setEnforcedOptions — ce sont des primitives à porte owner mais pas par elles-mêmes des primitives de sortie-arnaque.

4. read_contract pour l'état on-chain. Pour les tokens Clanker v4 :

   • totalSupply() view returns (uint256) — attends-toi à 100_000_000_000 * 10^18.
   • allData() view returns (address originalAdmin, address admin, string image, string metadata, string context) — la lecture la plus riche. Te dit le déployeur admin, admin actuel (si différent = transfert admin s'est produit), si metadata/socials/audits sont remplis, et quelle interface l'a lancé (clanker.world, Farcaster, etc.).
   • isVerified() view returns (bool) — drapeau de vérification propre à Clanker.
   • balanceOf(address) view returns (uint256) — pour n'importe quel portefeuille que tu veux vérifier (admin, top holders, pool manager). Pour les OFTs : owner(), peers(uint32) pour chaque eid connu (Ethereum=30101, BSC=30102, Arbitrum=30110, Base=30184, Polygon=30109, Optimism=30111), endpoint(), msgInspector(), preCrime().

5. get_clanker_reward_ownership (tokenAddress, chain) — retourne chaque destinataire de récompense/slot admin pour le token. C'est le signal unique le meilleur pour « l'équipe a-t-elle réellement alloué les récompenses d'écosystème/marketing/CEX comme elle le prétend » — si cela montre seulement un {admin, recipient} tous deux égaux au déployeur, l'équipe n'a PAS configuré la tokenomique à destinataires multiples.

6. Lectures viem directes via execute_cli quand tu dois vérifier les soldes en batch, détecter contrat vs EOA (les top holders avec bytecode 48-byte sont des proxies smart-wallet AA / sniper 7702, pas des whales), ou calculer la concentration. Installe viem@2.21.55 et exécute un petit analyze.mjs.

   Configuration RPC (la variable d'env personnalisée est OPTIONNELLE) :

   • D'abord, appelle get_env_vars pour vérifier si l'utilisateur a défini une variable RPC personnalisée pour la chaîne que tu analyses (BASE_RPC_URL, MAINNET_RPC_URL, ARBITRUM_RPC_URL, etc.). Si présente, utilise-la — c'est presque toujours un rate-limit plus haut.
   • Si aucune variable personnalisée n'est définie, reviens au RPC public intégré de viem en créant le client avec juste la chaîne (pas d'URL transport personnalisée). Exemple :

     import { createPublicClient, http } from 'viem';
     import { base } from 'viem/chains';
     const rpcUrl = process.env.BASE_RPC_URL; // peut être undefined
     const client = createPublicClient({
       chain: base,
       transport: rpcUrl ? http(rpcUrl) : http(), // http() sans arg utilise chain.rpcUrls.default
     });

     Cela fonctionne pour base, mainnet, arbitrum, optimism, polygon, bnb, unichain, etc. directement.

   • Les RPCs publics sont rate-limités et peuvent être instables sous charge. Si tu vois 429 / timeouts en regroupant beaucoup de lectures, soit (a) ajoute de petits délais entre les appels, (b) chunke les lectures, soit (c) dis à l'utilisateur à la fin du rapport qu'une variable d'env RPC personnalisée rendrait les réexécutions plus rapides et fiables — ne bloque pas l'analyse sur cela.

   Utilise toujours cette étape viem pour :

   • Vérifier entre totalSupply, admin, originalAdmin, isVerified, allData à partir du RPC directement (ne fais pas confiance aux seules sorties d'indexeur).
   • getBalance + getTransactionCount pour chaque déployeur et le portefeuille Twitter prétendument réclamé.
   • getBytecode sur chaque top holder non-pool — 48 bytes = smart wallet minimal-proxy EIP-7702 / (pattern sniper) ; >100 bytes = vrai contrat (pourrait être extension vault Clanker/airdrop, ou un Gnosis Safe) ; pas de code = EOA régulier.
   • Pour les multisigs Safe : les contrats Safe ont un préfixe de bytecode connu et une fonction VERSION() / getOwners() — tu peux les détecter spécifiquement.
   • Pour les tokens cross-chain : fais des lectures de solde sur les AUTRES chaînes aussi (par ex., si c'est sur Base mais déployé comme un OFT, lis les miroirs Ethereum et BSC via leurs RPCs — encore une fois, variable d'env personnalisée si définie, sinon viem public default).
   • Math de concentration : somme top-20, soustrait pool, calcule la concentration non-pool.

7. market_intelligence avec query_type="holders" (chain, token_id=adresse du contrat, limit jusqu'à 20) — distribution des top holders. Le #1 holder est presque toujours le PoolManager Uniswap v4 (0x498581ff718922c3f8e6a244956af099b2652b2b sur Base). Identifie toujours les adresses de pool en premier et exclus-les du calcul de concentration.

8. get_chain_activity_for_wallet sur chaque portefeuille intéressant :

   • Le déployeur/admin pour chaque contrat — cherche le cycle de vie : financé → déploiement → extraction → (parfois) réclamation des frais.
   • Top 3 non-pool holders — ont-ils snipé à la genèse avec des portefeuilles frais ? Comment ont-ils été financés ?
   • Le portefeuille Twitter prétendument réclamé — a-t-il un quelconque empreinte sur la chaîne de déploiement à tout ?
   • Pour les tokens OFT : vérifie si les top holders envoient VERS les portefeuilles de dépôt d'exchange (Coinbase, portefeuilles chauds Binance) — c'est le signal de distribution-dans-l'offre.

9. get_evm_address_from_twitter_username / get_evm_address_from_farcaster_username — résous le handle social prétendument réclamé à un portefeuille. Puis vérifie avec get_chain_activity_for_wallet et viem getTransactionCount si ce portefeuille est l'admin d'un contrat ou a un quelconque empreinte sur la chaîne de déploiement. La plupart des rugs ont des portefeuilles sociaux avec ZÉRO activité sur la chaîne qu'ils arnaquent.

10. browse_url sur basescan/etherscan/polygonscan (https://basescan.org/address/{addr}) uniquement comme fallback quand get_contract_abi échoue ou pour confirmer qu'une adresse est un DEX/pool/contrat infra. Beaucoup de sites de docs (pages racine hébergées sur gitbook) retournent vide via firecrawl — va directement aux URLs d'articles spécifiques. Après extraction du fait dont tu as besoin, appelle immédiatement prune_messages(tool_names=["browse_url"], replacement="<one-line fact>").

11. perform_technical_analysis (seulement si l'utilisateur est dans Bankr Club — erreur sinon, ne réessaie pas).

Étape Finale-1 (OBLIGATOIRE) — Passage d'intelligence off-chain avant verdict

Un contrat peut être on-chain-propre et toujours être un cas de manipulation en cours. Avant d'écrire le verdict TL;DR, tu DOIS exécuter un passage off-chain parallèle. Exécute ces trois appels EN PARALLÈLE en un seul tour :

1. search_tool pour couverture d'investigateur / presse :
   • Requête 1 : "<TOKEN_SYMBOL>" <token_name> scam rug investigation twitter
   • Requête 2 : ZachXBT <TOKEN_SYMBOL> manipulation (ZachXBT est l'investigateur on-chain le plus fiable en crypto — vérifie toujours les appels directs par nom)
   • Requête 3 : <TOKEN_SYMBOL> pump dump exchange investigation <year_actuel> (pour attraper les annonces d'investigation Bitget/Binance/OKX/Gate)
   • Requête 4 (si un nom d'équipe émerge) : "<founder name>" <token_name> founder (pour identifier l'équipe et tout baggage de projet antérieur)
2. get_social_sentiment_for_ticker — passe le ticker et additionalContext décrivant le token, la chaîne, et si c'est en mouvement parabolique. Retourne la scission de la communauté, le contexte du taux de financement, et les allégations mises en avant.
3. browse_url sur le compte X/Twitter officiel du projet si connu (format : https://x.com/<handle>) — cherche les auto-avertissements du projet lui-même. Une équipe avertissant publiquement sa propre communauté sur la « volatilité extrême » durant un mouvement parabolique est souvent une reconnaissance douce que la distribution d'initiés s'apprête à commencer.

Règles d'ajustement du verdict basées sur l'intelligence off-chain

• Un investigateur Tier-1 (ZachXBT) a publiquement flaggé le token comme manipulation → augmente le verdict d'un niveau (par ex., LOW-à-MEDIUM → MEDIUM-à-HIGH), même si le contrat est propre. Note l'ID du post X et les affirmations spécifiques.
• Un CEX nommé (Bitget / Binance / OKX / Gate / Kraken) a confirmé une enquête formelle → augmente le verdict d'un niveau ET flagge explicitement « risque de délisting CEX / forced-unwind » dans le TL;DR. C'est matériel.
• Une prime de lanceur d'alerte public ($10k+) a été postée nommant le token → traite comme un signal de manipulation fort ; au minimum mentionne dans le TL;DR.
• Équipe identifiée comme fondateurs quants crypto expérimentés / bureau de tenue de marché (alumni ZX Squared, Wintermute, firmes MM connues) combiné avec concentration d'offre d'initiés → note « plausiblement auto-financé MM » ajustement structurel. Pas une preuve, mais le bon profil pour la tactique.
• Le fondateur a un antécédent antérieur de rug/scam/projet abandonné → augmente le verdict d'un niveau.
• La réclamation de concentration d'initiés de la part des investigateurs correspond à ce que tu as mesuré on-chain (par ex., investigateur dit « 90%+ chez les initiés », ta somme des top Safes trésorier + EOAs liés au CEX ≈ ce nombre) → traite l'allégation comme corroborée on-chain.
• Les taux de financement ont basculé fortement négatifs durant la pompe + dépôts CEX d'initiés auparavant = tell mécanique de short-squeeze. Mentionne dans la section structure de marché.
• Pas de signaux négatifs et la couverture est seulement des takes standard « listing pump » → laisse le verdict inchangé mais note le signal plus propre dans le TL;DR.

Si tu sautes cette étape et émet un verdict basé seulement sur les données on-chain, tu sous-évalueras systématiquement les vrais cas de manipulation d'initiés. Cette étape n'est pas optionnelle.

Liste de contrôle des drapeaux rouges (note chacun ; >=5 = risque élevé)

Au niveau du contrat / configuration (APRÈS avoir lu les docs de la plateforme) :

• [ ] isVerified() = false sur le drapeau de vérification propre à la plateforme (Clanker).
• [ ] Les métadonnées allData(), socialMediaUrls, auditUrls sont tous vides.
• [ ] get_clanker_reward_ownership montre seulement UN destinataire = l'admin lui-même (pas de destinataires d'écosystème / marketing / multisig), SURTOUT quand le narrative de l'équipe prétend que ces allocations existent.
• [ ] Pas d'extension Vault (pas de tokens tenus par un contrat de vault Clanker comme top holder).
• [ ] Pas d'extension Airdrop (pas de contrat airdrop Clanker comme top holder).
• [ ] Admin mutable (updateAdmin) sans multisig / timelock / renounce.
• [ ] Admin peut mettre à jour l'image/métadonnées post-lancement (risque de hijack de métadonnées).
• [ ] Les frais / blacklist / pause / mint peuvent être appelées par admin.
• [ ] Pour les OFTs : setPeer peut toujours être appelé par owner et il n'y a pas de processus timelock public ou DAO autour.

Au niveau du déployeur :

• [ ] Le portefeuille du déployeur a été financé via un pont minutes-à-heures avant le déploiement.
• [ ] Le portefeuille du déployeur extrait de la valeur (ponts ETH/USDC/WETH) immédiatement après le lancement.
• [ ] Le portefeuille du déployeur n'a pas d'antécédent avant attaché à une équipe réelle.
• [ ] Le portefeuille admin est un EOA frais (nonce simple-chiffre) plutôt qu'un multisig Safe.
• [ ] Pour une « migration » : nouveau contrat déployé d'un portefeuille DIFFÉRENT de l'ancien, sans continuité on-chain (pas de transferts directs entre les deux, pas de chemin de financement partagé).

Au niveau du détenteur :

• [ ] Les top 10 non-pool holders contrôlent >10% de l'offre et ont acheté à la genèse avec des portefeuilles frais.
• [ ] Plusieurs top non-pool holders sont des proxies smart-wallet 48-byte (AA / bots sniper 7702).
• [ ] La « pompe » sur le nouveau contrat est entraînée par <5 portefeuilles qui ont chacun acheté >1% de l'offre dans les premiers blocs.
• [ ] L'ancien contrat a toujours plus de holders que le nouveau — la majorité de la « communauté loyale » n'a réellement pas migré.
• [ ] Pour les OFTs multichain : un seul Safe trésorier tient >50% de l'offre mondiale sur la chaîne de frappe (même si la concentration sur Base/chaîne-cible parait saine).
• [ ] Les top non-pool holders envoient activement vers les portefeuilles chauds CEX (Coinbase, adresses de dépôt Binance) durant la pompe ou immédiatement après.

Narrative vs réalité :

• [ ] Le compte social prétendument réclamé (Twitter/X) n'a AUCUNE présence on-chain sur la chaîne de déploiement.
• [ ] Le compte social prétendument réclamé n'est pas l'admin d'un contrat.
• [ ] Le « correctif de tokenomique » prétendument réclamé est une capacité que la plateforme supporte déjà au moment du déploiement — c'est-à-dire qu'un redéploiement n'est techniquement pas nécessaire pour l'implémenter. (C'est là que la lecture des docs de l'Étape 0 importe.)
• [ ] Le narrative de migration manque : snapshot, contrat de réclamation 1:1, sink de brûlage LP du token ancien. L'équipe dit juste « re-achat ».
• [ ] Le nouveau contrat a la MÊME configuration vanilla que l'ancien — pas vault, pas airdrop, pas récompenses multi-destinataires — malgré que le narrative soit « nouvelle tokenomique ».

Intégrité off-chain / marché (de l'Étape Finale-1) :

• [ ] ZachXBT ou un autre investigateur tier-1 a publiquement flaggé le token.
• [ ] Un CEX a confirmé une enquête formelle.
• [ ] Une prime publique a été postée pour preuve de manipulation.
• [ ] L'équipe a un antécédent antérieur de rug / projet abandonné.
• [ ] L'équipe inclut une firme de tenue de marché connue / quant ET la concentration d'initiés est élevée.
• [ ] Le projet s'auto-avertit sa communauté sur la « volatilité » durant un mouvement parabolique.
• [ ] La presse crypto grand public (Coindesk, The Block, Cointelegraph) a pivoté la couverture de positive à investigatrice.

Structure de sortie (écris vers /reports/<token_or_project>_scam_analysis.md)

1. TL;DR — Verdict (LOW / MEDIUM / HIGH / EXTREME risque) + raisonnement d'une ligne + confiance %. DOIT incorporer l'intelligence off-chain de l'Étape Finale-1 si des triggers sont atteints.
2. Contrats sous analyse — tableau avec adresse, déployeur, admin, offre, isVerified, complétude des métadonnées, compte des destinataires de récompense, présence vault/airdrop, stats de marché, % pool. Inclure les contrats frères sur d'autres chaînes pour les OFTs multichain.
3. Intelligence off-chain / couverture sociale & presse — section dédiée avec : incidents clés (callouts d'investigateur, investigations CEX, primes avec dates), identification de l'équipe (fondateurs, projets antérieurs, liens LinkedIn/RootData), résumé du sentiment communautaire, liens de couverture presse grand public, et effet net sur le verdict. Ajoute toujours cette section même si les conclusions sont neutres.
4. Claim vs reality — énumère chacune des affirmations publiques de l'équipe ; sous chacune, déclare (a) ce que la chaîne montre et (b) ce que les docs de déploiement de la plateforme disent que l'équipe aurait pu faire. Cite l'URL du doc.
5. Médecine légale du portefeuille du déployeur — pour chaque déployeur : source de financement, cycle de vie nonce-par-nonce, financement pré-déploiement / extraction post-déploiement / réclamations de frais post-lancement.
6. Distribution des holders — identifie explicitement le holder du pool/DEX et l'exclut du calcul de concentration ; liste les top 5–10 holders réels avec comment ils ont acquis leur sac (tx hash, ETH payé, quel bloc), et marque chacun comme EOA vs contrat intelligent. Pour multichain : inclure les holdings trésorier cross-chain.
7. Drapeaux rouges au niveau du contrat — tirés directement de l'ABI + allData + propriété des récompenses, avec signatures de fonction et pourquoi chacun importe.
8. Test d'irrationalité économique — qu'AURAIT DÛ faire une équipe légitime ? Nomme les outils spécifiques natifs à la plateforme (pour Clanker : vault, airdrop, destinataires multiples rewards, admin multisig Safe, snapshot + contrat de réclamation, LP burn). Contraste avec ce que l'équipe a réellement fait.
9. Correspondance de motif — cela correspondrait-il à un modèle d'escroquerie connu (par ex., « dump redéploiement Clanker », « relaunch fronté sniper », « pompe listing CEX avec trésorier dominant », « short-squeeze MM auto-financé ») ?
10. Ce qui changerait le verdict — liste les faits on-chain spécifiques qui abaisseraient le score de risque. Force l'équipe à se manifester ou se taire. Liste également ce qui l'augmenterait.
11. Sources — liens directs de block-explorer pour chaque contrat et portefeuille référencé, plus les URLs de docs de plateforme que tu as lus à l'Étape 0 et les URLs d'investigateur/presse de l'Étape Finale-1.
12. Appendice — données brutes complètes extraites (totalSupply, admin, allData, soldes clés, sortie de script viem, hauteur de bloc des lectures).

Après enregistrement du fichier

Retourne à l'utilisateur un résumé de 4–6 puces avec :

• le verdict + confiance (informé par l'intelligence on-chain ET off-chain)
• les 2–3 pires drapeaux rouges (formulés comme des faits, pas des accusations)
• toute identification d'investigateur tier-1 / investigation CEX / fondateur nommée
• un pointeur vers le chemin du rapport sauvegardé

NE DUMPE PAS le rapport entier inline.

Gestion du contexte

Ces analyses tirent beaucoup de données. Après avoir extrait les faits dont tu as besoin, appelle prune_messages sur les outils bruyants comme browse_url, get_contract_abi (si l'ABI était énorme), et get_chain_activity_for_wallet (ces outils retournent de longs historiques de tx). Passe un résumé court pour que les faits ne soient pas perdus.

Pièges courants

• Ne traite pas le PoolManager Uniswap v4 (ou position NFT v3, ou paire v2) comme une whale. C'est la pool. Identifie-la toujours en premier.
• Ne flagge pas « même bytecode » sur un redéploiement comme un drapeau rouge en soi. Clanker (et la plupart des fabriques) produisent un code d'exécution de token identique sur chaque déploiement. Les différences de configuration vivent dans la charge utile de déploiement (vault, airdrop, partages de récompense, capitalisation initiale, frais). Compare la configuration, pas le bytecode.
• Ne confonds pas solde admin = 0 avec « l'équipe n'a pas de tokens ». Sur Clanker/Doppler l'offre entière est vendue dans la pool au lancement sauf si l'équipe a explicitement configuré une extension Vault ou Airdrop. Portefeuille admin vide est attendu ; la présence d'un contrat Clanker Vault/Airdrop comme top holder est ce qui indiquerait des allocations réelles.
• Ne fais pas confiance au handle Twitter sans le résoudre à un portefeuille. Un projet peut prétendre n'importe quel handle. Ce qui importe est si le portefeuille de ce handle est l'admin.
• Ne lis pas browse_url sur les URLs racine de docs gitbook — elles retournent souvent vide via firecrawl. Va aux URLs d'articles spécifiques (par ex., .../general/token-deployments, pas .../). Utilise search_tool pour trouver l'URL de l'article d'abord.
• Ne bloque pas dur sur une variable d'env RPC personnalisée manquante. Le transport http() de viem sans argument revient par défaut au RPC public de la chaîne (rate-limité mais fonctionnel). Exige une *_RPC_URL personnalisée seulement si l'utilisateur veut explicitement des lectures à haut volume ou si tu atteins les limites de taux mid-analysis — alors suggère d'en définir une pour la prochaine fois.
• Si l'utilisateur n'est pas dans Bankr Club, perform_technical_analysis erreur. Ne réessaie pas — utilise browse_url, market_intelligence, et les lectures de contrat à la place.
• N'émet pas un verdict basé seulement sur les données on-chain. Exécute toujours le passage d'intelligence off-chain de l'Étape Finale-1 d'abord. Un contrat peut être propre et le token toujours être un cas de manipulation active. RAVE (avril 2026) est l'exemple canonique : OFT LayerZero propre, déployeur propre, owner multisig, et simultanément flaggé ZachXBT + enquêté Bitget comme un pump-and-dump coordonné.
• Pour les OFTs multichain, vérifie toujours le trésorier de la chaîne de frappe, pas juste la chaîne que l'utilisateur a demandée. Une distribution de holder « saine » sur Base peut être sans pertinence si 75% de l'offre mondiale est assise dans un Safe sur Ethereum.