network="gnosis" queries RPC endpoints of other chains (ETH/OP/Base/Arbitrum/Polygon) — 17/20 calls fail, silent false negative

[spouletmathis]

Interface: MCP (via alter-cli mcp)
Alter version: 1.25.0 (alter-cli, alter-mcp, meta.server_version tous en 1.25.0 — aucun décalage binaire/serveur)
Platform: macOS 26.6.1 (Build 25G76)
Date: 2026-08-14

Résumé

Sur une requête network: "gnosis", le pool d'endpoints inclut des RPC d'autres chaînes (Ethereum, Optimism, Base, Arbitrum, Polygon). 17 appels sur 20 échouent, et le résultat est un faux négatif silencieux (total_active_borrowers: 0) au lieu d'une erreur.

Les 3 endpoints Gnosis valides du pool répondent correctement — le problème n'est pas la disponibilité réseau, mais la sélection d'endpoints.

Repro

alter-cli mcp address.lending_risk_score --json '{
  "pool_address":"0xfb9b496519fca8473fba1af0850b6b8f476bfdb3",
  "variable_debt_token_addresses":["0x69c731ae5f5356a779f44c355abb685d84e5e9e6"],
  "network":"gnosis"
}' --timeout 180

Observé — meta.rpc_metrics.endpoints_used

calls_total: 20, calls_failed: 17

  https://gnosis-mainnet.public.blastapi.io   calls:1 failed:1
  https://rpc.ankr.com/gnosis                 calls:1 failed:1
  https://gnosis.api.onfinality.io/public     calls:1 failed:1
  https://1rpc.io/gnosis                      calls:1 failed:1
  https://gnosis-rpc.publicnode.com           calls:1 failed:None
  https://rpc.gnosischain.com                 calls:1 failed:None
  https://rpc.gnosis.gateway.fm               calls:1 failed:None
  https://rpcfree.com/polygon-rpc             calls:1 failed:1   ← Polygon
  https://cloudflare-eth.com                  calls:1 failed:1   ← Ethereum
  https://eth.drpc.org                        calls:1 failed:1   ← Ethereum
  wss://eth.drpc.org                          calls:1 failed:1   ← Ethereum
  wss://mainnet.gateway.tenderly.co           calls:1 failed:1   ← Ethereum
  https://optimism.drpc.org                   calls:1 failed:1   ← Optimism
  https://base.drpc.org                       calls:1 failed:1   ← Base
  https://arbitrum.drpc.org                   calls:1 failed:1   ← Arbitrum

8 des 15 endpoints appartiennent à d'autres chaînes que Gnosis (chain_id 100).

Santé réelle des RPC (test direct, hors Alter, eth_blockNumber)

OK    https://rpc.gnosischain.com          bloc=47727047  307ms
OK    https://rpc.gnosis.gateway.fm        bloc=47727047  321ms
FAIL  https://gnosis-rpc.publicnode.com    HTTP 403
FAIL  https://gnosis-mainnet.public.blastapi.io  HTTP 403
FAIL  https://rpc.ankr.com/gnosis          pas de 'result'
FAIL  https://1rpc.io/gnosis               HTTP 403

Deux endpoints Gnosis sont pleinement fonctionnels. Alter en a 3 marqués failed: None dans son propre pool, et retourne quand même 0.

Attendu

1. Une requête network: "gnosis" ne doit interroger que des endpoints de chain_id: 100.
2. Si des endpoints hors-chaîne restent dans le pool, leurs échecs ne doivent pas compter comme des échecs de la requête.
3. Avec ≥1 endpoint sain, le résultat doit être correct — ou signalé en erreur explicite, jamais 0 avec note: "No active borrowers found".

Impact

Faux négatif silencieux. Sur ce pool, la vérité terrain mesurée le même jour en RPC direct est :

• 1473 positions actives, $14 711 302 de dette, 200 liquidables (13,58 %)
• Alter annonce total_active_borrowers: 0, total_debt_usd: 0.0, avec note: "No active borrowers found for this pool. It may have no outstanding debt"

Un agent qui fait confiance à cette réponse conclut que le pool est vide.

Problème connexe — chain.add ne met pas à jour les RPC

alter-cli mcp chain.add --json '{"chain_id":100,"rpc_urls":["https://rpc.gnosischain.com","https://rpc.gnosis.gateway.fm"],"display_name":"Gnosis"}'
→ {"success": false, "error": "chain_already_exists",
   "message": "A chain with chainId 100 already exists"}

Il n'existe donc aucun moyen de corriger le pool d'endpoints d'une chaîne déjà enregistrée. Souhait : que chain.add soit idempotent (met à jour rpc_urls), ou qu'un chain.set_rpc_urls / chain.refresh(rpc_urls:[...]) existe.

Suggestion

result_confidence vaut partial / rpc_degraded dans ces réponses — c'est le bon signal, mais il est facile à manquer. Avec 17/20 appels en échec, un résultat à zéro mériterait failed plutôt qu'un note en langage naturel affirmant l'absence de dette.

[spouletmathis]

Tests d'acceptation

Vérité terrain mesurée le 2026-08-14 en RPC direct sur le pool RMM v3 (0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3, Gnosis), scan complet de 1475 emprunteurs, 0 erreur :

Métrique	Valeur
Positions actives	1473
Dette totale	$14 711 302
Collatéral total	$26 068 628
Liquidables (HF < 1)	200 (13,58 %)
Ratio collatéral/dette	1,77

Test 1 — aucun endpoint hors-chaîne sur une requête Gnosis

alter-cli mcp address.lending_risk_score --json '{
  "pool_address":"0xfb9b496519fca8473fba1af0850b6b8f476bfdb3",
  "variable_debt_token_addresses":["0x69c731ae5f5356a779f44c355abb685d84e5e9e6"],
  "network":"gnosis"
}' --timeout 180

Critère : dans meta.rpc_metrics.endpoints_used, aucune URL n'appartient à une autre chaîne que Gnosis (chain_id 100).

Liste noire de non-régression — aucune de ces URLs ne doit apparaître sur une requête network: "gnosis" :

cloudflare-eth.com
eth.drpc.org
wss://eth.drpc.org
wss://mainnet.gateway.tenderly.co
optimism.drpc.org
base.drpc.org
arbitrum.drpc.org
rpcfree.com/polygon-rpc

Test 2 — taux d'échec RPC cohérent

Critère : sur la même commande, calls_failed / calls_total < 0.30.

Référence actuelle (à corriger) : 17/20 = 85 %.

Justification : au moment du test, rpc.gnosischain.com et rpc.gnosis.gateway.fm répondaient tous deux à eth_blockNumber en ~310 ms. Un taux d'échec élevé n'est donc pas imputable à l'indisponibilité du réseau.

Test 3 — résultat numériquement correct

Critère : total_active_borrowers > 1000 et total_debt_usd > 14_000_000.

Tolérance : la dette croît avec les intérêts courus (pool à 100 % d'utilisation), donc une borne basse suffit. Le résultat actuel est 0 / 0.0.

Test 4 — pas de faux négatif silencieux

Critère : si le scan ne peut pas aboutir, la réponse doit porter result_confidence: "failed" et un errors[] non vide.

Interdit : total_active_borrowers: 0 accompagné de note: "No active borrowers found for this pool. It may have no outstanding debt, or all borrowers have zero debt." alors que des appels RPC ont échoué. Cette formulation affirme une absence de dette qui n'a pas été constatée — c'est le comportement le plus dangereux du bug, car un agent la lit comme un fait.

Test 5 — chain.add idempotent sur les RPC

alter-cli mcp chain.add --json '{
  "chain_id":100,
  "rpc_urls":["https://rpc.gnosischain.com","https://rpc.gnosis.gateway.fm"],
  "display_name":"Gnosis"
}'

Critère : la chaîne existant déjà, l'appel doit mettre à jour rpc_urls et retourner un succès — ou bien un tool dédié (chain.set_rpc_urls, chain.refresh(rpc_urls:[...])) doit permettre cette mise à jour.

Vérification : après l'appel, une requête Gnosis ne doit utiliser que les deux endpoints fournis.

Comportement actuel : {"success": false, "error": "chain_already_exists"}, sans aucun moyen de corriger le pool d'endpoints.

[spouletmathis]

État vérifié sur main (2026-08-15)

Deux correctifs déjà intégrés traitent la contamination du pool RPC :

• révision interne retirée — sélection réseau et health-check paresseux du client load-balanced ;
• révision interne retirée — purge des anciens endpoints Gnosis retirés du registre.

Le rejeu de bêta-test documenté dans docs/testing/reports/beta-test-dev-2026-08-09-codex-cli-gpt-5.md confirme que les appels Gnosis observés dans meta.rpc_metrics.endpoints_used portent uniquement le réseau gnosis. Le dry-run de purge retrouve aussi exactement les anciens endpoints Ankr, BlastAPI et OnFinality ; aucune purge --apply n’a été exécutée sur le profil utilisateur, conformément au consentement requis.

Cela valide le critère d’isolation de chaîne dans le code courant, mais pas encore toute l’issue :

• le scénario numérique address.lending_risk_score ne peut pas être déclaré réussi tant que address.concentration and address.lending_risk_score hang >11min / >18min on Gnosis with healthy RPCs, with no progress signal or async job option #76 fait expirer le scan exhaustif ;
• la purge réelle du profil historique demande un endpoint purge-stale --apply explicite ;
• le seuil total_active_borrowers > 1000 / total_debt_usd > 14M reste donc à rejouer après livraison et purge.

Issue maintenue ouverte : la cause « endpoints d’autres chaînes » est corrigée et testée, mais la preuve fonctionnelle complète reste bloquée par #76 et par l’application consentie de la purge.

[spouletmathis]

Lien avec #67 — symptôme voisin, mais cause différente

#67 rapportait « 8/11 endpoints RPC publics à 100 % d'échec » sur address.statement, avec des endpoints Ethereum (cloudflare-eth.com, eth.drpc.org, api.securerpc.com) interrogés lors d'un run Gnosis. Le diagnostic retenu était RPC-CUSTOM-STALE-01 : des endpoints custom persistés localement, hérités d'un registre d'une version antérieure, écrasant les defaults (PR [référence interne retirée], tool endpoint.purge_stale).

Sur notre installation, cette explication ne tient pas — et le présent ticket décrit donc un second mécanisme, indépendant.

Vérification : le registre local est propre

alter-cli mcp endpoint.list --json '{}'

34 endpoints, tous is_default: true, aucun endpoint custom persisté :

chain_id	endpoints	tous is_default
1 (Ethereum)	13	✅
100 (Gnosis)	8	✅
137 (Polygon)	4	✅
42161 (Arbitrum)	3	✅
10 (Optimism)	3	✅
8453 (Base)	3	✅

Chaque endpoint porte le bon chain_id : cloudflare-eth.com est bien étiqueté chain_id: 1, arbitrum.drpc.org bien 42161, etc. Le registre n'est pas corrompu, et le classement par chaîne est correct.

Le problème est donc en aval du registre

Malgré ce registre sain, une requête network: "gnosis" interroge quand même les endpoints des autres chaînes (voir le ticket : cloudflare-eth.com, optimism.drpc.org, base.drpc.org, arbitrum.drpc.org, rpcfree.com/polygon-rpc dans endpoints_used).

Ce n'est donc pas un problème de contenu du registre (#67), mais de filtrage à la sélection : le pool d'endpoints utilisé pour une requête ne semble pas filtré sur le chain_id cible, alors que l'information est disponible et correcte.

Autrement dit : endpoint.purge_stale ne corrigera pas ce cas, puisqu'il n'y a rien de périmé à purger ici.

Note sur la disponibilité du correctif #67

Non testable sur la version installée — alter-cli et alter-mcp en 1.25.0 (dernière version disponible via brew au 2026-08-14, brew outdated ne remonte rien) :

alter-cli mcp endpoint.purge_stale → "Unknown tool: endpoint.purge_stale"
alter-cli endpoint purge-stale     → 'méthode "purge-stale" inconnue pour l'objet "endpoint"'

Le correctif de la PR #982 n'est donc pas encore livré en release publique. Je pourrai rejouer le scénario d'acceptation de #67 dès qu'une version l'embarquant sera disponible — mais l'observation ci-dessus (registre déjà propre) suggère que notre cas ne sera pas résolu par ce correctif.

Autres symptômes liés

Trois autres tickets ouverts aujourd'hui présentent des symptômes que la sélection d'endpoints explique bien :

• address.deploy_block returns a near-present block with found=true (off by 15.6M blocks on armmUSDC) — breaks auto_from_block in address.allowances #74 — address.deploy_block retournait 47726807 au lieu de 32074665 (écart 15,6M blocs) avec found: true. En MCP direct avec 2 RPC Gnosis sains uniquement, le résultat redevient exact (result_confidence: complete). L'algorithme de dichotomie est correct ; ce sont les eth_getCode en échec, interprétés comme « bytecode absent », qui faussaient la recherche.
• address.concentration and address.lending_risk_score hang >11min / >18min on Gnosis with healthy RPCs, with no progress signal or async job option #76 — lending_risk_score et address.concentration abandonnés à 30 min de silence chacun. Même famille que la latence ~14 min de address.statement (bêta v1.25.0) : ~14min de latence, résultat partiel — 8/11 endpoints RPC publics par défaut à 100% d'échec #67.
• lending.pool_snapshot: totals aggregate non-borrowable collateral — reports 33% utilization / $29.9M available on a pool at 100% / $0 #73 — en revanche non imputable aux RPC : reproduit à l'identique avec 3/3 appels réussis et result_confidence: complete. C'est un bug d'agrégation (usage_role mal classé), à traiter séparément.

Vue consolidée pour le triage :

Ticket	Tool	Cause probable
#67	address.statement	endpoints custom périmés (RPC-CUSTOM-STALE-01)
#71	lending_risk_score	sélection d'endpoints non filtrée par chain_id
#74	deploy_block	échec RPC traité comme « pas de bytecode »
#76	concentration, risk_score	latence / absence de progression
#73	pool_snapshot	agrégation usage_role — indépendant des RPC

[spouletmathis]

État vérifié — isolation corrigée, preuve numérique encore ouverte

Correctifs déjà sur main : révision interne retirée et révision interne retirée. Le lot local révision interne retirée empêche en plus ChainList de remplacer les RPC curatés des chaînes connues.

Rejeu depuis un profil hermétique neuf :

chain.list = 4 RPC Gnosis uniquement
address.add(rmm-v3): 5 appels, 5 succès, failure_count=0, fallback_used=false
chain.refresh(chain_id=100, rpc_urls=[4 RPC Gnosis]): success=true, duration_ms=894

Aucune URL Ethereum, Optimism, Base, Arbitrum ou Polygon n’apparaît dans endpoints_used. Le scénario exact address.lending_risk_score avec les deux vdTokens retourne désormais immédiatement un job_id interrogeable en 0 ms, conformément à #76.

Issue maintenue ouverte : le scan exhaustif est resté running pendant le rejeu et a été arrêté avec la session hermétique. Les seuils total_active_borrowers > 1000 et total_debt_usd > 14M ne sont donc pas encore prouvés sur le résultat terminal.

[spouletmathis]

Mise à jour de livraison — 2026-08-17

La version publique actuelle est v1.25.0. Les correctifs d’isolation des RPC par chaîne sont intégrés à main et seront inclus dans la prochaine release publique d’Alter qui succédera à v1.25.0.

Le précédent statut indiquant que le dernier lot était local est donc obsolète.

L’issue reste ouverte car la preuve numérique terminale n’est pas encore acquise. Le test d’acceptation sur la release devra confirmer simultanément :

• aucun endpoint Ethereum, Optimism, Base, Arbitrum ou Polygon dans une requête Gnosis ;
• résultat terminal du job exhaustif ;
• total_active_borrowers > 1000 ;
• total_debt_usd > 14M.

La présence du correctif dans la prochaine release ne vaut donc pas encore clôture : le rejeu terrain reste obligatoire.

[spouletmathis]

Retest sur build phoenix_0 @ 1918d432d — 19/08/2026

Binaires : alter-cli + alter-mcp compilés localement depuis phoenix_0 @ 1918d432d
(HEAD main, ~90 commits après v1.25.0), dart compile exe, macOS 26.6.1 arm64.
Ce n'est pas le paquet Homebrew 1.25.0.

⚠️ Piège de méthode, à connaître pour les prochains retests : alter-cli mcp <tool> spawn
le binaire alter-mcp du PATH, donc par défaut le Homebrew 1.25.0 et non la build testée.
Il faut passer --mcp-binary <chemin> pour réellement tester la build. Mes premiers essais
tapaient l'ancien serveur sans que rien ne le signale.

⚠️ --version et meta.server_version affichent toujours 1.25.0 sur cette build.
Impossible de rattacher un retour terrain à une révision précise — un bump de version
(ou le SHA dans --version) rendrait les prochains retours traçables.

Résultat : partiel, et non concluant sur le scénario d'acceptation

✅ Sur les tools légers, l'isolation tient

$ alter-cli mcp address.balance --json '{"holders":["0x9166..."],
    "tokens":["0xddafbb..."],"network":"gnosis"}' --mcp-binary <build>
→ duration_ms: 166 | result_confidence: complete | endpoints hors-chaîne: 0

Et sur une session fraîche, collection.add rmm-v3 ne provisionne que 4 RPC Gnosis —
aucune URL Ethereum/Optimism/Base/Arbitrum/Polygon dans chain.list.

❌ Le scénario d'acceptation n'a pas pu aller à son terme

$ alter-cli mcp address.lending_risk_score --json '{
    "pool_address":"0xfb9b496519fca8473fba1af0850b6b8f476bfdb3",
    "variable_debt_token_addresses":["0x69c731ae5f5356a779f44c355abb685d84e5e9e6"],
    "network":"gnosis"}' --mcp-binary <build>

Job resté running pendant 1500 s (25 min), arrêté de mon côté, phase figée
à scanning_borrow_events avec pct=None de t=25s à t=1500s.

Les 4 critères d'acceptation restent donc invérifiables : pas de résultat terminal,
pas de total_active_borrowers > 1000, pas de total_debt_usd > 14M, et pas de
endpoints_used exploitable pour juger de l'isolation sur un scan complet.

⚠️ Un point qui mérite quand même un regard

Sur un profil utilisateur réel (30 endpoints custom sur 6 chaînes — 13× ethereum,
5× gnosis, 3× polygon, 3× arbitrum, 3× optimism, 3× base, tous jugés non obsolètes par
purge-stale), des requêtes network: "gnosis" font toujours apparaître des endpoints
hors-chaîne dans endpoints_used :

$ alter-cli mcp chain.add --json '{"chain_id":100}'      ← requête Gnosis
endpoints_used: cloudflare-eth.com (ethereum)      calls=1 failed=1
                eth.drpc.org (ethereum)            calls=1 failed=1
                wss://eth.drpc.org (ethereum)      calls=1 failed=1
                optimism.drpc.org (optimism)       calls=1 failed=1
                base.drpc.org (base)               calls=1 failed=1
                arbitrum.drpc.org (arbitrum)       calls=1 failed=1
→ 6/6 en échec

Même chose sur lending.positions_batch avec network: "gnosis" : 6 endpoints
interrogés, 6 hors-chaîne, 6 échecs, et result_confidence: rpc_degraded.

L'isolation semble donc tenir au provisionnement (session neuve, preset) mais pas
systématiquement à l'exécution sur un profil historique chargé. Je ne peux pas
trancher si c'est le même mécanisme que celui décrit dans le ticket ou un troisième
effet — précisément parce que le scan de référence ne converge pas.

À rejouer une fois #67 réglé : c'est la même dépendance que pour #70.

[spouletmathis]

Beta-test build locale — #71 corrigé côté MCP, toujours présent côté CLI

Build testée : 5e4eb061d (2026-08-19), 83 commits après v1.25.0, compilée localement.
Vérifié que c'est bien la build qui répond (token.holders existe ici, Unknown tool sur
le Homebrew 1.25.0), tous les appels MCP passés avec --mcp-binary.

Surface MCP — ✅ corrigé

$BUILD/alter-cli mcp lending.pool_snapshot --json '{
  "network":"gnosis",
  "pool_address":"0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3",
  "block_tag":"latest"
}' --mcp-binary $BUILD/alter-mcp --timeout 200

4 runs consécutifs, répartition des appels par réseau (meta.rpc_metrics.endpoints_used) :

run 1 : {'gnosis': 17}  échecs {'gnosis': 1}   target_network_rpc_status=unhealthy
run 2 : {'gnosis': 17}  échecs {'gnosis': 1}   target_network_rpc_status=degraded
run 3 : {'gnosis': 16}  échecs {}              target_network_rpc_status=healthy   confidence=complete
run 4 : {'gnosis': 17}  échecs {'gnosis': 1}   target_network_rpc_status=degraded

0 appel hors Gnosis sur les 4 runs. Le pool d'endpoints est propre lui aussi :

$BUILD/alter-cli mcp endpoint.list --json '{"chain_id":100}' --mcp-binary $BUILD/alter-mcp
# → 5 endpoints, tous chain_id=100, aucune contamination

Surface CLI native — ❌ non résolu

Même pool, même réseau, chemin CLI :

$BUILD/alter-cli lending pool-snapshot --network=gnosis \
  --pool-address=0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3 --profile=expert

3 runs consécutifs :

run 1 : {'ethereum':3,'optimism':1,'base':1,'arbitrum':1}            → 6/6 hors Gnosis (100%), 6 échecs
run 2 : {'ethereum':3,'optimism':1,'gnosis':1,'base':1,'arbitrum':1} → 6/7 hors Gnosis (86%), 7 échecs
run 3 : idem run 2
target_network_rpc_status = unhealthy · result_confidence = rpc_degraded

Endpoints réellement interrogés : cloudflare-eth.com, eth.drpc.org, wss://eth.drpc.org,
optimism.drpc.org, base.drpc.org, arbitrum.drpc.org — tous à 100 % d'échec.

Verdict : ⚠️ partiel

Le correctif est livré sur la surface MCP mais pas sur la surface CLI, qui continue de
résoudre un pool d'endpoints par défaut multi-chaînes malgré --network=gnosis.

Impact usage

Le résultat CLI n'est pas vide — il est dégradé silencieusement : pool-snapshot
retourne bien ses 4 réserves, mais avec result_confidence: "rpc_degraded" et des données
issues d'un pool d'endpoints à 100 % d'échec. Pour du suivi de position RMM v3 (santé,
collatéral) c'est exactement le cas où une valeur fausse est pire qu'une absence de valeur.

Cas de test

# Repro — --network=gnosis interroge ethereum/optimism/base/arbitrum
$BUILD/alter-cli lending pool-snapshot --network=gnosis \
  --pool-address=0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3 --profile=expert \
  | python3 -c "import sys,json,collections;o=json.loads(sys.stdin.read());d=json.loads(o['content'][0]['text']);m=d['meta']['rpc_metrics'];c=collections.Counter();[c.__setitem__(e['network'],c[e['network']]+e['calls']) for e in m['endpoints_used']];print(dict(c))"

Observé vs attendu

Observé  : {'ethereum':3,'optimism':1,'gnosis':1,'base':1,'arbitrum':1}  → 86% hors cible
Attendu  : {'gnosis': N}                                                 → 100% sur la cible
Vérité terrain : le même appel via la surface MCP fait 17/17 sur Gnosis (4 runs)

✅ Test d'acceptation

1. Sur la commande de repro, endpoints_used ne contient que network == "gnosis".
2. calls_failed ≈ 0 et target_network_rpc_status ∈ {healthy, degraded}, jamais
   unhealthy du seul fait d'endpoints hors cible.
3. result_confidence != rpc_degraded quand les endpoints Gnosis répondent.
4. Anti-régression MCP : les 4 runs MCP ci-dessus restent à 0 appel hors Gnosis.
5. Cas limite : --network=ethereum interroge bien des endpoints Ethereum (le correctif ne
   doit pas épingler Gnosis en dur).

Réserves

Testé sur lending pool-snapshot. Les autres sous-commandes CLI réseau n'ont pas été
rejouées ; si la résolution d'endpoints est partagée, elles sont probablement affectées de
la même façon.