address.inspect classe erc20/contract des adresses sans bytecode sur le réseau demandé (contamination cross-chain de la classification)

[spouletmathis]

Symptôme

Sur network: "gnosis", address.inspect retourne detected_roles contenant contract,
erc20, burnable, mintable et typeName: "Utility Token" pour des adresses dont
eth_getCode renvoie 0x sur Gnosis. Ces contrats existent sur Ethereum, pas sur la
chaîne demandée : la classification semble provenir d'une autre chaîne que celle passée en
paramètre.

Build testée : 5e4eb061d (2026-08-19), 83 commits après v1.25.0, compilée localement,
appels via --mcp-binary.

Cas de test

A=0xe5f7ef61443fc36ae040650aa585b0395aef77c8

# 1. vérité terrain : pas de bytecode sur Gnosis
curl -s -X POST -H 'Content-Type: application/json' \
  --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getCode\",\"params\":[\"$A\",\"latest\"]}" \
  https://rpc.gnosischain.com
# → {"result":"0x"}

# 2. le contrat existe bien sur Ethereum
curl -s -X POST -H 'Content-Type: application/json' \
  --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getCode\",\"params\":[\"$A\",\"latest\"]}" \
  https://ethereum-rpc.publicnode.com
# → {"result":"0x608060405234801561001057600080fd5b50..."}

# 3. Alter, sur gnosis, le classe pourtant comme ERC-20
$BUILD/alter-cli mcp address.inspect --json "{\"network\":\"gnosis\",\"address\":\"$A\"}" \
  --mcp-binary $BUILD/alter-mcp --timeout 150

Le tool chain.rpc d'Alter lui-même confirme l'absence de code, sur la même session :

$BUILD/alter-cli mcp chain.rpc --json "{\"network\":\"gnosis\",\"method\":\"eth_getCode\",\"params\":[\"$A\",\"latest\"]}" \
  --mcp-binary $BUILD/alter-mcp
# → {"chain_id":100,"method":"eth_getCode","result":"0x","result_confidence":"complete"}

Donc chain.rpc et address.inspect, dans la même session et sur le même réseau, se
contredisent sur la nature de l'adresse.

Observé vs attendu

Observé  : detected_roles = ['burnable','contract','erc20','evm','mintable']
           typeName       = "Utility Token"
           result_confidence = "partial"
Attendu  : detected_roles = ['evm']   (aucun rôle de contrat sur une adresse sans code)
           typeName       = ""        ou un marqueur explicite "non déployé sur ce réseau"
Vérité terrain : eth_getCode(gnosis) = "0x" sur 2 RPC Gnosis publics indépendants
                 (rpc.gnosischain.com, gnosis-rpc.publicnode.com)

Fréquence

Systématique, pas anecdotique. Sur les 12 premières adresses du preset realtokens qui
n'ont pas de bytecode sur Gnosis : 12/12 sont classées
['burnable','contract','erc20','evm','mintable'] / Utility Token.

Contre-exemple utile pour le diagnostic : 0x0675e8F4A52eA6c845CB6427Af03616a2073538c,
également sans code sur Gnosis, est correctement classée ['evm'] seul avec
typeName: "". Le défaut n'est donc pas universel — il touche les adresses pour lesquelles
une classification existe sur une autre chaîne, ce qui oriente vers un cache ou une
résolution multi-chaînes qui ignore le network demandé.

Sur un contrat réellement déployé sur Gnosis
(0xfe17c3c0b6f38cf3bd8ba872bee7a18ab16b43fb), la classification est en revanche juste et
précise : erc3643 + Security Token + proxy, total_supply conforme au RPC direct.
Le mécanisme fonctionne bien quand l'adresse est effectivement sur la chaîne visée.

Impact usage

Ici, address.inspect sert à qualifier une adresse avant de l'intégrer au suivi de
patrimoine RealT (3916, valorisation). Un faux erc20 sur la mauvaise chaîne conduit à
inscrire une ligne qui n'existe pas sur ce réseau, puis à interroger des balances qui
renverront 0 — sans qu'aucun signal ne distingue « je ne détiens rien » de « ce token n'est
pas sur cette chaîne ».

Le result_confidence: "partial" est un signal, mais trop faible : il ne dit pas quoi
est partiel, et une valeur partial est courante sur des réponses par ailleurs correctes.

Contexte aggravant : le preset realtokens (812 adresses) est décrit comme « RealTokens sur
Ethereum et Gnosis » mais aucune de ses 812 entrées ne porte son réseau
(collection.inspect → toutes les entrées ont la seule clé address). Impossible donc de
savoir depuis le preset sur quelle chaîne interroger une adresse donnée — ce qui rend la
mauvaise réponse d'address.inspect d'autant plus piégeuse.

✅ Test d'acceptation

1. Sur 0xe5f7ef61443fc36ae040650aa585b0395aef77c8 avec network: "gnosis" :
   detected_roles ne contient ni contract, ni erc20, ni burnable, ni mintable.
2. typeName n'est pas "Utility Token" ; l'adresse est présentée comme non déployée sur
   la chaîne demandée (champ explicite plutôt que rôles vides muets).
3. Si une classification issue d'une autre chaîne est retournée, elle est étiquetée par sa
   chaîne d'origine et ne peut pas être confondue avec la chaîne demandée.
4. Cohérence interne : pour toute adresse, address.inspect(network=X) ne peut pas annoncer
   contract quand chain.rpc eth_getCode sur ce même X retourne 0x.
5. Anti-régression : sur 0xfe17c3c0b6f38cf3bd8ba872bee7a18ab16b43fb (gnosis),
   la classification reste erc3643 / Security Token / proxy et
   total_supply == "1300000000000000000000".
6. Anti-régression : 0x0675e8F4A52eA6c845CB6427Af03616a2073538c (gnosis) reste ['evm'].

Suggestion connexe

Faire porter à chaque entrée du preset realtokens son réseau (network ou chain_id)
supprimerait la cause racine côté usage : aujourd'hui, rien ne permet de savoir quelle
chaîne interroger pour une des 812 adresses, ce qui rend l'erreur de chaîne quasi
inévitable côté consommateur.

Réserves

Testé sur profil chargé, chaîne Gnosis provisionnée, collection rmm-v3, sans clé API
explorer. Je n'ai pas cherché à déterminer si la classification erronée vient d'un cache
inter-chaînes, d'un registre statique ou d'une résolution d'endpoint — seulement à établir
la contradiction observable avec chain.rpc sur la même session.

[spouletmathis]

Retest — build 31076cc86 (v1.25.0 +94 commits) : ✅ corrigé

Build compilée depuis phoenix_0 HEAD 31076cc86, testée via --mcp-binary.
⚠️ --version affiche 1.25.0 comme la release publique → je cite le SHA.

Cas de test — avec contrôle négatif

Le cas positif seul ne prouve rien : si la classification devenait simplement
plus timide, on ne verrait pas la différence. J'ai donc joué les deux.

# (a) USDC mainnet — n'a PAS de bytecode sur Gnosis
$BUILD/alter-cli mcp address.inspect --json '{
  "address":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","network":"gnosis"
}' --mcp-binary $BUILD/alter-mcp --timeout 180

# (b) contrôle négatif : armmUSDC — RÉELLEMENT déployé sur Gnosis
$BUILD/alter-cli mcp address.inspect --json '{
  "address":"0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1","network":"gnosis"
}' --mcp-binary $BUILD/alter-mcp --timeout 180

Observé

(a) USDC mainnet sur gnosis : detected_roles = ["evm"]                          result_confidence: complete
(b) armmUSDC sur gnosis     : detected_roles = ["contract","evm","yield_token"] result_confidence: complete

Attendu : (a) aucun rôle contract/erc20 faute de bytecode sur le réseau
demandé ; (b) classification complète maintenue. Les deux passent.

Pour situer l'ancien comportement, la 1.25.0 installée classe encore armmUSDC
["contract","evm","yield_token"] sur network:"polygon", où ce token
n'existe pas — exactement la contamination décrite dans l'issue. La build rend
["evm"] sur ce même appel.

Test d'acceptation (anti-régression)

✅ Le correctif tient si :
   1. address.inspect(USDC_mainnet, network="gnosis").detected_roles == ["evm"]
   2. address.inspect(armmUSDC, network="polygon").detected_roles == ["evm"]
   3. address.inspect(armmUSDC, network="gnosis").detected_roles contient
      "contract" ET "yield_token"          ← anti-régression, le plus important
   4. les 3 appels rendent result_confidence == "complete"

Le critère 3 est celui à ne pas perdre : exiger la preuve de déploiement ne doit
pas déclasser les tokens réellement présents sur la chaîne visée.

Impact pipeline

Indirect mais réel pour nous : RMM classe des adresses EVM sur Gnosis
(address.inspect est notre 3e tool le plus appelé). Un rôle erc20 usurpé sur
une adresse absente de la chaîne fausserait un tri d'adresses en amont de
documents publiés.

Réserves

Un seul token testé par sens. Non couvert : proxies, contrats auto-destruits,
adresses déployées sur les deux chaînes à la même adresse (CREATE2) — ce dernier
cas serait le plus intéressant à border côté tests hermétiques.

Je ne clos pas l'issue.

[spouletmathis]

Beta-test build locale — ✅ corrigé

Build testée : 31076cc86 (2026-08-20), 94 commits après v1.25.0, dart compile exe,
macOS 26.6.1 arm64. Pas le Homebrew 1.25.0 (vérifié via token.holders).

Correctif identifié : 11dd3690a — fix(core): exiger la preuve de déploiement pour classer un token.

Commande rejouée — cas exact de l'issue

A=0xe5f7ef61443fc36ae040650aa585b0395aef77c8
$BUILD/alter-cli mcp address.inspect --json "{\"network\":\"gnosis\",\"address\":\"$A\"}" \
  --mcp-binary $BUILD/alter-mcp --timeout 200

Sortie observée

detected_roles    : ['evm']
typeName          : null
result_confidence : complete
chains[0]         : {"networkId":"gnosis","isDeployed":false,"isContract":false, ...}

Contre ['burnable','contract','erc20','evm','mintable'] / "Utility Token" avant.

Test d'acceptation — 6/6

OK  1. ni contract, ni erc20, ni burnable, ni mintable            → ['evm']
OK  2. typeName ≠ "Utility Token" + marqueur explicite            → isDeployed:false, isContract:false
OK  3. pas de classification d'une autre chaîne présentée comme gnosis
OK  4. cohérence address.inspect ↔ chain.rpc eth_getCode          → 8/8 (ci-dessous)
OK  5. anti-régression 0xfe17c3c0… : erc3643 + proxy + total_supply conservés
OK  6. anti-régression 0x0675e8F4… : reste ['evm']

Le critère 2 est mieux servi que ce que je demandais : plutôt que des rôles vides muets,
isDeployed: false / isContract: false dit explicitement pourquoi c'est vide.

Critère 4 — fréquence, sur 8 contrats ERC-20 majeurs absents de Gnosis

Le défaut était systématique (12/12 à l'ouverture). Rejoué sur 8 adresses (DAI, USDC, SUSHI,
LINK, UNI, WBTC, COMP + celle de l'issue), avec eth_getCode(gnosis) comme vérité terrain :

0xe5f7ef6144..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0x6b175474e8..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0xa0b86991c6..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0x7fc66500c8..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0x514910771a..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0x1f9840a85d..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0x2260fac5e5..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non
0xc00e94cb66..  code=0x  roles=['evm']  isDeployed=False  VIOLATION=non

8/8 conformes, contre 12/12 en violation à l'ouverture.

Anti-régression 5 — la classification fine n'a pas été sacrifiée

0xfe17c3c0b6f38cf3bd8ba872bee7a18ab16b43fb (gnosis, réellement déployé)
  detected_roles : ['bridge_protocol_v2','burnable','contract','eip2612','erc20',
                    'erc3643','evm','mintable','proxy']
  isDeployed     : true    isContract : true
  totalSupply    : 1300000000000000000000   (conforme au RPC direct)

C'est le point important : le correctif n'a pas résolu le faux positif en appauvrissant la
classification. erc3643, proxy et le total_supply on-chain sont conservés.

Verdict : ✅ livré

Mesure : 8/8 adresses sans bytecode classées ['evm'] seul, 2/2 anti-régressions vertes,
cohérence address.inspect ↔ chain.rpc rétablie.

Impact usage

address.inspect sert ici à qualifier une adresse avant intégration au suivi de patrimoine
RealT (3916, valorisation). Le faux erc20 conduisait à inscrire une ligne inexistante sur
le réseau, puis à interroger des balances renvoyant 0 — sans rien pour distinguer « je ne
détiens rien » de « ce token n'est pas sur cette chaîne ». isDeployed tranche désormais
cette ambiguïté explicitement, ce qui est exactement ce dont la préparation 3916 a besoin.

Suggestion connexe — toujours d'actualité

Le point soulevé en fin d'issue reste entier : aucune des 812 entrées du preset
realtokens ne porte son réseau (collection.inspect → seule clé address). La cause
racine côté produit est corrigée ; côté usage, rien ne dit encore sur quelle chaîne
interroger une adresse donnée du preset. Je peux ouvrir une issue dédiée si vous préférez
la suivre séparément.

Réserves

Profil chargé, Gnosis provisionnée, collection rmm-v3, sans clé API explorer. Je n'ai pas
vérifié le comportement sur une adresse déployée sur les deux chaînes avec des rôles
divergents — le champ hasCrossChainDivergence vu dans overview suggère que le cas est
traité, je ne l'ai pas exercé.

[spouletmathis]

Beta-test build locale — ✅ toujours corrigé (anti-régression)

Build testée : d5126afb0 (2026-08-21), 99 commits après v1.25.0.
Pas le Homebrew 1.25.0. Aucun commit nouveau sur ce sujet depuis 31076cc86.

$BUILD/alter-cli mcp address.inspect \
  --json '{"network":"gnosis","address":"0xe5f7ef61443fc36ae040650aa585b0395aef77c8"}' \
  --mcp-binary $BUILD/alter-mcp --timeout 200

detected_roles    : ['evm']
typeName          : null
isDeployed        : false
isContract        : false
networkId         : gnosis
result_confidence : complete
rpc.scope         : gnosis
duration_ms       : 4537

Anti-régression RealToken déployé 0xfe17c3c0… : erc3643 + proxy +
isDeployed:true + total_supply=1300 conservés.

Verdict : ✅ livré

Mesure : adresse sans bytecode sur Gnosis classée ['evm'] seul, marqueurs
isDeployed/isContract=false explicites.

[spouletmathis]

Beta-test build c27f34c38 — ✅ toujours corrigé (anti-régression)

Build testée : phoenix_0 HEAD c27f34c38 (2026-08-21), 105 commits après v1.25.0. Pas le Homebrew 1.25.0. Aucun commit nouveau sur ce sujet depuis 11dd3690a.

$BUILD/alter-cli mcp address.inspect \
  --json '{"network":"gnosis","address":"0xe5f7ef61443fc36ae040650aa585b0395aef77c8"}' \
  --mcp-binary $BUILD/alter-mcp --timeout 200

detected_roles    : ['evm']
typeName          : (vide)
isDeployed        : false
isContract        : false
networkId         : gnosis
result_confidence : complete
rpc.scope         : gnosis
duration_ms       : 4502

Anti-régression RealToken déployé 0xfe17c3c0b6f38cf3bd8ba872bee7a18ab16b43fb : erc3643 + proxy + isDeployed:true + total_supply=1300 conservés.

Verdict : ✅ livré

Mesure : adresse sans bytecode sur Gnosis classée ['evm'] seul, marqueurs isDeployed/isContract=false explicites.

[spouletmathis]

Beta-test build locale — ✅ pas de régression : pas de erc20 usurpé hors chaîne

Build testée : c27f34c38 (v1.25.0 +105 commits), dart compile exe, --mcp-binary. Pas le Homebrew 1.25.0.

Correctif d'origine : 11dd3690a. Aucun commit de cette build ne retouche le sujet.

Commande rejouée

$BUILD/alter-cli mcp address.inspect --json '{
  "address":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
  "network":"gnosis"
}' --mcp-binary $BUILD/alter-mcp --timeout 60

Contrôle négatif : armmUSDC 0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1 sur network:"gnosis".

Observé

USDC mainnet sur gnosis : detected_roles=["evm"]  seul, rc=complete
armmUSDC sur gnosis     : detected_roles=["contract","evm","yield_token"]

Plus de contract / erc20 usurpé pour une adresse sans bytecode sur Gnosis.

Verdict

✅ pas de régression. Le contrôle négatif (token réellement déployé) reste classé.

Impact pipeline

address.inspect est consommé par positions.py (pool) et plusieurs scripts d'analyse. Une classification cross-chain fausse ferait router un token Ethereum comme collatéral Gnosis. Non observé ici.

Réserves

Je ne close pas. Contrôle Polygon (armmUSDC classé yield_token hors chaîne) non rejoué aujourd'hui.