address.statement (bêta v1.25.0) : ~14min de latence, résultat partiel — 8/11 endpoints RPC publics par défaut à 100% d'échec

[spouletmathis]

Contexte

Test de la nouvelle feature bêta v1.25.0 address.statement (annoncée dans les release notes du 30/07/2026) sur un cas d'usage réel : reconstitution de relevé RealT/RMM v3.

• Interface : MCP
• Version Alter : 1.25.0
• Appel : address.statement(wallet: <wallet Gnosis>, network: "gnosis", preset_id: "stablecoins", from: "2026-06-01", to: "2026-07-31")

Problème : lenteur excessive (850s / 14 min)

Pour un scope de 2 mois sur 5 tokens (Gnosis), l'appel a mis 850764 ms (~14 minutes) à répondre, contre quelques secondes pour address.portfolio/address.position sur des scopes comparables.

meta.rpc_metrics montre la cause : 8 des 11 endpoints RPC publics par défaut étaient à 100% d'échec durant le run :

• api.securerpc.com (ethereum) — 100% échec
• rpc.blocknative.com/boost (ethereum) — 100% échec
• gnosis-mainnet.public.blastapi.io — 100% échec
• rpc.ankr.com/gnosis — 100% échec
• gnosis.blockpi.network/v1/rpc/public — 100% échec
• gnosis.api.onfinality.io/public — 100% échec (+ rate limit hits)
• cloudflare-eth.com (ethereum) — 100% échec
• eth.drpc.org (ethereum) — 100% échec

Seuls 3 endpoints Gnosis ont tenu (rpc.gnosischain.com, rpc.gnosis.gateway.fm, gnosis.oat.farm), avec des taux de retry très élevés (ex. 1203 retries pour 420 appels sur rpc.gnosis.gateway.fm).

global_health et target_network_rpc_status remontent bien "unhealthy", et recommended_action suggère d'ajouter un RPC privé via chain.refresh — mais rien n'indique en amont (avant de lancer un scan de plusieurs minutes) que la configuration RPC par défaut est dans cet état.

Conséquence

Le relevé final revient marqué result_confidence: "partial" avec 4 limitations incomplete_transfer_logs imputées à ces échecs RPC — le scan de transferts n'a pas pu être exhaustif.

Suggestions

1. Vérifier la santé des endpoints RPC publics par défaut (Gnosis + Ethereum) — plusieurs semblent morts en permanence plutôt que ponctuellement dégradés.
2. Avant de lancer un scan long, faire un check RPC rapide et avertir l'utilisateur / suggérer chain.refresh avec RPC privé en amont plutôt qu'après 14 minutes d'attente.

statement_fingerprint disponible en privé si utile pour reproduire : 922a1d101e7a2d8206385094bcd26448dd928af1048e9e9263964e9807ee8b06

---

Interface : MCP Server

[spouletmathis]

Merci pour le rapport très détaillé, ça a permis de creuser efficacement.

Diagnostic

Aucun des 8 endpoints signalés (api.securerpc.com, rpc.blocknative.com/boost, gnosis-mainnet.public.blastapi.io, rpc.ankr.com/gnosis, gnosis.blockpi.network, gnosis.api.onfinality.io, cloudflare-eth.com, eth.drpc.org) ne figure dans le registre officiel actuel d'Alter (chain-registry.json). Les endpoints Ethereum/Gnosis actuels du registre par défaut sont publicnode.com, 1rpc.io, llamarpc.com, mevblocker.io, flashbots.net, gnosischain.com, drpc.org.

En testant directement les 8 endpoints signalés, on confirme qu'ils sont bien cassés durablement (pas une panne ponctuelle) :

• blastapi.io a fermé son service public gratuit définitivement (redirige vers Alchemy)
• rpc.ankr.com exige désormais une clé API (plus de tier gratuit anonyme)
• Le reste est down (521), rate-limité (429), ou injoignable

Cause racine probable

Alter fusionne les endpoints "custom" persistés localement avec les "defaults" du registre embarqué — les custom l'emportent sur les defaults pour un même chainId (PersistentChainRepository). Si un endpoint a été proposé par le registre par défaut d'une version antérieure d'Alter, puis retiré du registre officiel dans une release ultérieure (parce que devenu mort/payant), il reste indéfiniment dans le stockage local de l'utilisateur — Alter ne le distingue pas d'un ajout volontaire, et rien ne le retire automatiquement.

Le mécanisme de purge existant (ADR-0087, purge_tls_migration.dart, exécuté à chaque release) vérifie la conformité TLS des endpoints custom, mais pas leur disponibilité réelle — un endpoint mort mais TLS-valide passe cette purge sans problème.

Piste de correction

Étendre le mécanisme de purge pour retirer les endpoints custom qui ne figurent plus dans le registre par défaut courant et échouent un health-check, plutôt que de se fier uniquement à la conformité TLS. Tracé en dette technique côté monorepo.

Action immédiate côté utilisateur : chain.refresh (ou équivalent CLI/Flutter) devrait réinitialiser la config Ethereum/Gnosis sur les defaults actuels et faire disparaître la lenteur constatée.

[spouletmathis]

Mise à jour — correctif livré (en attente de confirmation terrain)

PR monorepo : [référence interne retirée]
Traçabilité : RPC-CUSTOM-STALE-01 (TODO + tests hermétiques)

Cause racine (confirmée dans le code)

Les endpoints RPC « custom » persistés localement écrasent les defaults du registre pour un même chainId. Un endpoint présent dans une ancienne version d’Alter, puis retiré du registre (service fermé, clé API désormais requise, etc.), restait indéfiniment dans le stockage local et continuait d’être interrogé — d’où les 8/11 endpoints à 100 % d’échec et la latence ~14 min.

La purge TLS (ADR-0087) ne couvre pas ce cas : elle ne juge que la conformité TLS, pas la disponibilité réelle.

Correctif

• Capacité core StaleCustomEndpointPurger : retrait uniquement si les deux conditions sont réunies :
  1. endpoint absent du registre par défaut pour sa chaîne ;
  2. injoignable au health-check eth_chainId.
• Consentement explicite : par défaut rapport seul ; le retrait exige --apply / apply: true (jamais de purge silencieuse — ADR-0096).
• Garde WebSocket : les URL ws:// / wss:// ne sont pas jugées mortes par la sonde HTTP (évite les faux positifs).
• Surfaces : CLI endpoint purge-stale [--apply] + MCP endpoint.purge_stale(apply?) (Flutter non exposé, dette consciente comme la purge TLS).

Scénario d’acceptation (à rejouer sur le build de la PR / prochaine release)

Préconditions : même profil / session que le rapport initial (endpoints custom hérités présents).

1. endpoint purge-stale --profile=expert (sans --apply)
   → les endpoints morts listés dans le rapport initial doivent apparaître comme candidats.
2. endpoint purge-stale --apply --profile=expert
   → retrait effectif.
3. Relancer exactement l’appel address.statement du rapport initial
   → latence attendue : quelques secondes, plus ~14 min ; meta.rpc_metrics ne doit plus montrer 8/11 endpoints à 100 % d’échec.

Seule l’étape 3 prouve la résolution côté utilisateur (RÈGLE #19).
Issue maintenue ouverte jusqu’à cette confirmation.

Lien avec #70

Hypothèse d’origine : le accounting_invariant_mismatch pourrait être un effet collatéral de logs incomplets sous RPC dégradés. À réévaluer sur #70 une fois #67 confirmé avec des endpoints sains.

[spouletmathis]

Retour terrain 1.25.0 — correctif non encore livré, et un second mécanisme distinct

1. endpoint.purge_stale absent de la 1.25.0

Le scénario d'acceptation n'est pas rejouable sur la dernière version publique :

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"'

Versions vérifiées : alter-cli 1.25.0, alter-mcp 1.25.0, meta.server_version 1.25.0, brew outdated ne remonte aucune mise à jour (2026-08-14). La PR [référence interne retirée] n'est donc pas encore dans une release publique — je rejouerai le scénario dès qu'elle y sera.

2. Notre registre local est déjà propre — et le problème persiste

Point important pour le diagnostic : sur notre installation, la cause RPC-CUSTOM-STALE-01 ne s'applique pas, mais des endpoints hors-chaîne sont malgré tout interrogés sur des requêtes Gnosis.

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

34 endpoints, tous is_default: true — aucun endpoint custom persisté, et le chain_id de chacun est correct :

chain_id	endpoints
1 (Ethereum)	13
100 (Gnosis)	8
137 / 42161 / 10 / 8453	4 / 3 / 3 / 3

Aucun des 8 endpoints morts que vous aviez identifiés (api.securerpc.com, blastapi.io, ankr, blockpi, onfinality…) n'est présent chez nous. Le registre correspond bien au registre officiel actuel.

Pourtant, un run network: "gnosis" remonte dans endpoints_used : cloudflare-eth.com, eth.drpc.org, optimism.drpc.org, base.drpc.org, arbitrum.drpc.org, rpcfree.com/polygon-rpc — soit 8 des 15 endpoints appelés, tous étiquetés d'une autre chaîne dans le registre lui-même.

Il y a donc deux mécanismes distincts :

• 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 : le contenu du registre (endpoints périmés persistés) → corrigé par purge_stale
• network="gnosis" queries RPC endpoints of other chains (ETH/OP/Base/Arbitrum/Polygon) — 17/20 calls fail, silent false negative #71 : le filtrage à la sélection — le pool d'endpoints d'une requête n'est pas restreint au chain_id cible, alors que l'information est présente et juste

Le second survivra au correctif du premier. Détail complet et tests d'acceptation : #71.

3. Symptômes voisins sur d'autres tools

Sur #74 (address.deploy_block), l'effet est spectaculaire et bien isolé : le tool retournait un bloc faux de 15,6M de blocs avec found: true sur le pool d'endpoints par défaut, et redevient exact (result_confidence: complete) dès qu'on force une chaîne Gnosis à 2 RPC sains. L'algorithme est bon — ce sont les eth_getCode en échec, traités comme « bytecode absent », qui faussent la dichotomie.

Cela rejoint votre remarque de #67 : rien n'avertit en amont qu'un scan va être lancé sur un pool majoritairement défaillant. Ici, la conséquence n'est pas seulement la latence, mais un résultat faux retourné avec un flag de succès.

[spouletmathis]

Cause racine complétée et correctif vérifié — 2026-08-15

Implémentation locale : révision interne retirée (non poussée).

Le rejeu hermétique depuis un profil vide a identifié deux causes supplémentaires :

1. ChainList distante remplaçait les RPC Gnosis curatés par quatre endpoints devenus morts ou payants ;
2. gnosis-mainnet.gateway.tatum.io répond à eth_chainId, mais refuse eth_call hors offre payante.

Le provisionnement d’une chaîne connue conserve maintenant le registre local curaté et Tatum a été retiré. Rejeu final RMM → RMM v3 → rmm-v3 :

chain.list: 4 endpoints Gnosis, aucun endpoint hors chaîne
address.add(preset_id: "rmm-v3")
duration_ms = 1685
HTTP requests = 5
RPC success = 100 %
failure_count = 0
fallback_used = false

Test d’acceptation ajouté : une réponse ChainList obsolète ne peut plus réinjecter Ankr, BlastAPI, BlockPI, OnFinality ou Tatum dans une nouvelle configuration Gnosis. Les tests ciblés passent, ainsi que make test-fast.

Issue maintenue ouverte jusqu’au push/livraison. Pour un profil historique contenant encore des endpoints custom, endpoint.purge_stale --apply reste nécessaire et soumis au consentement de l’utilisateur.

[spouletmathis]

Mise à jour de livraison — 2026-08-17

La version publique actuelle est v1.25.0. Les correctifs décrits ci-dessus sont désormais 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 « implémentation locale non poussée » est donc obsolète.

L’issue reste ouverte jusqu’au rejeu du scénario d’acceptation sur les binaires publiés : provisionnement Gnosis limité aux RPC curatés de la chaîne cible, absence de réinjection des endpoints périmés par ChainList, puis nouvel appel address.statement confirmant la disparition de la latence et des échecs observés. Pour un profil historique contenant des endpoints custom, endpoint.purge_stale --apply reste soumis au consentement explicite de l’utilisateur.

[spouletmathis]

Retest après livraison de endpoint purge-stale — la latence persiste, l'hypothèse initiale est invalidée

Retest réalisé le 19/08/2026 sur le scénario exact de l'issue, avec les binaires compilés depuis phoenix_0 (commit c13599a95, postérieur aux correctifs #982/#983), pas le paquet Homebrew 1.25.0.

Ma propre hypothèse de départ dans cette issue — « les endpoints morts causent la latence » — ne résiste pas au retest.

Protocole

1. Mesure de référence avant toute modification
2. endpoint purge-stale --apply
3. Rejeu du même appel, même wallet, même période

Résultats

Mesure	Avant purge (8 endpoints)	Après purge (5 endpoints)
address inspect (Gnosis)	6,84 s	6,79 s
address.statement (scénario de l'issue)	922 s (15 min 22)	2150 s (35 min 50), sans réponse retournée

La purge a fonctionné comme spécifié : 4 endpoints retirés (rpc.ankr.com/gnosis, gnosis-mainnet.public.blastapi.io, gnosis.api.onfinality.io/public, plus rpcfree.com/polygon-rpc), les endpoints sains conservés. Le dry-run les avait correctement identifiés au préalable.

Mais address inspect est strictement inchangé (6,84 → 6,79 s). Si les endpoints morts portaient la latence, ce chemin aurait dû s'accélérer lui aussi.

Les endpoints restants sont sains

Sondage direct des 5 endpoints restants — tous sains, même bloc, réponse en 0,10 à 0,38 s :

gnosis-rpc.publicnode.com   0.103s
rpc.gnosischain.com         0.251s
rpc.gnosis.gateway.fm       0.160s
gnosis.oat.farm             0.379s
1rpc.io/gnosis              0.257s

Le facteur limitant apparaît sur eth_getLogs, l'appel réellement utilisé par le scan :

eth_getLogs sur 10 001 blocs :
  publicnode  → -32602 "Block range 10001 exceeds the maximum of 10000 blocks per logs request"
eth_getLogs sur 9 999 blocs :
  publicnode      OK 1.39 s
  gnosischain     OK 1.48 s
  gateway.fm      OK 1.40 s
  oat.farm        ERREUR
  1rpc.io/gnosis  ERREUR

Ordre de grandeur de la fenêtre demandée : 2 mois sur Gnosis (~5 s/bloc) ≈ 1 054 000 blocs,
soit ~211 chunks à la taille configurée dans le code (5 000 blocs).

Le détail du coût est dans la section suivante — il ne vient pas de la taille des
chunks, qui est correctement calibrée, mais de la façon dont les chunks échoués
sont retentés.

Effet contre-intuitif : la purge dégrade la latence

Sur les 5 endpoints conservés, seuls 3 acceptent une plage de 9 999 blocs (publicnode, gnosischain, gateway.fm) ; oat.farm et 1rpc échouent. Retirer des endpoints réduit donc le nombre de cibles utilisables pour le scan. Le run post-purge a tourné 2150 s (35 min 50) sans retourner de réponse — le client a coupé au timeout — contre 922 s avec un résultat exploitable avant purge.

endpoint purge-stale reste utile en soi — nettoyer des endpoints morts est sain, et le mécanisme de double critère (absent du registre + injoignable) est correct. Mais il ne traite pas ce que cette issue décrit.

Cause précise, localisée dans le code

alter/packages/core/lib/src/infrastructure/rpc/paginated_log_fetcher.dart

La passe 1 est correctement parallélisée (8 requêtes par vague, chunks de 5 000 blocs
calibrés sous la limite de 10 000). Ce n'est pas là qu'est le problème.

La passe 2 — le retry des chunks échoués, lignes 214-253 — est entièrement
séquentielle, avec un délai de 200 ms après chaque chunk :

if (failedRanges.isNotEmpty) {
  await Future<void>.delayed(const Duration(milliseconds: 500));
  for (final range in failedRanges) {
    final retry = await _fetchChunk(...);        // séquentiel
    ...
    if (_interWaveDelay > Duration.zero) {
      await Future<void>.delayed(_interWaveDelay);  // +200 ms par chunk
    }
  }
}

Sur une plage de 2 mois (~211 chunks), à 40 % d'échec en passe 1, cela fait
84 retries traités un par un.

Le modèle reproduit la mesure à 2 % près :

Étape	Coût calculé
Passe 1 (parallèle, 8/vague, 27 vagues)	46 s
Passe 2 (séquentielle, 84 chunks à 40 % KO)	143 s
Total pour 5 tokens du preset	944 s

Mesure réelle : 922 s.

Cela explique aussi l'effet contre-intuitif de la purge : moins d'endpoints valides
→ plus d'échecs en passe 1 → plus de retries séquentiels en passe 2 → 2150 s.

Pistes de correction

1. Paralléliser la passe de retry (levier principal). Réutiliser la mécanique de
   vagues de la passe 1 au lieu de la boucle séquentielle. Le commentaire justifie le
   séquentiel par le rate-limiting (address.events is 21-41x slower than in-house RPC scanner on identical contract/window, and doesn't complete the requested range #59), mais la passe 1 tourne déjà à 8 en parallèle
   sur les mêmes endpoints ; une vague de 4 en retry resterait sous ce seuil.
   Gain attendu sur le scénario de l'issue : ~143 s → ~20 s.

2. Retirer le +1 dans numChunks (~ligne 155) :

   final numChunks = ((latestBlock - effectiveFrom) / _chunkSize).ceil() + 1;

   Le .ceil() couvre déjà la plage. Le +1 demande un chunk au-delà de
   latestBlock à chaque scan — borné par le clamp, donc sans effet fonctionnel,
   mais c'est une requête inutile par scan et par token.

3. Adapter la taille de chunk à l'endpoint (secondaire). Les limites diffèrent
   d'un endpoint à l'autre ; un chunk fixe à 5 000 double le nombre de requêtes sur
   les endpoints qui acceptent 10 000.

4. Critère de purge : endpoint purge-stale ne juge que la réponse à
   eth_chainId. Un endpoint qui répond mais refuse les plages de logs utiles reste
   dans le pool, tandis que purger réduit le nombre de cibles capables de servir le
   scan. Intégrer la capacité eth_getLogs au critère éviterait de dégrader la
   latence en croyant assainir le pool.

Problème distinct trouvé au passage : sockets pendantes

Sur le run avec binaire recompilé à jour, le serveur MCP s'est retrouvé bloqué :
0 % CPU en état sleeping après 28 min, avec 59 sockets TCP dont 5 seulement
établies — 54 connexions en attente qui ne se fermaient jamais (hôtes majoritairement
derrière CDN : AWS Global Accelerator, Cloudflare). Le processus n'attendait pas un
calcul, il était bloqué sur des sockets mortes.

Cela ressemble à une absence de timeout de connexion (ou une fuite de descripteurs)
plutôt qu'à la latence décrite ici. Je le signale dans cette issue faute de repro
minimal isolé ; si vous préférez, j'ouvre une issue dédiée.

Test d'acceptation proposé

address.statement sur 2 mois / preset stablecoins / Gnosis répond en moins de 2 min avec result_confidence: complete, sur un pool d'endpoints publics sains.

Réserve de méthode

Les mesures chiffrées ci-dessus proviennent de binaires compilés le 09/08. J'ai
recompilé depuis le HEAD courant pour rejouer proprement, mais ce run s'est terminé
sur le blocage sockets décrit plus haut, sans mesure exploitable. L'analyse de code,
elle, porte bien sur le HEAD courant : paginated_log_fetcher.dart n'a pas été
modifié depuis (git log sur le fichier → dernier commit 2a8d35c8f), la boucle de
retry séquentielle y est identique.

---

Interface : MCP Server — binaires locaux phoenix_0

[spouletmathis]

Correctif proposé + rectificatif sur une des pistes

Rectificatif : la piste n°2 (+ 1 sur numChunks) était fausse

J'ai écrit plus haut que le + 1 provoquait « une requête inutile par scan et par
token ». C'est inexact, et je le corrige.

Le garde-fou if (from > latestBlock) break; dans la boucle de vagues empêche déjà
le chunk excédentaire d'être émis et d'être compté dans chunksTotal. Vérifié sur
plusieurs configurations de plage (multiple exact du chunk, reste partiel, plage
inférieure à un chunk) : le nombre de requêtes réellement envoyées est identique
avec ou sans le + 1.

Je l'ai découvert par contrôle de mutation : après avoir « corrigé » la formule et
écrit un test qui passait, j'ai réintroduit le + 1 — le test est resté vert. Le
test ne testait rien. Correctif abandonné, code d'origine conservé. La formule est
inhabituelle à la lecture, mais elle n'a aucun coût.

Correctif sur la piste n°1 (parallélisation du retry)

La passe de retry emprunte la mécanique de vagues de la passe 1. Le délai
inter-vagues s'applique entre vagues au lieu d'après chaque chunk ; la concurrence
reste bornée par _maxParallel, donc la protection anti-rate-limit de #59 tient.

Gain mesuré sur banc (211 chunks, latence RPC simulée à 150 ms, maxParallel = 8) :

Taux d'échec passe 1	Retry séquentiel	Retry parallèle	Scan total
20 % (43 chunks)	15,7 s	2,4 s	×2,1
40 % (71 chunks)	25,7 s	3,5 s	×2,7
62 % (106 chunks)	38,1 s	5,3 s	×3,2

La passe de retry elle-même gagne un facteur ~7 ; l'effet sur le scan complet dépend
du taux d'échec, qui est précisément ce qui varie avec la santé du pool d'endpoints.

Test d'acceptation ajouté dans le même lot : 8 chunks en échec en passe 1, tous
récupérés au retry, en vérifiant que la concurrence observée pendant la passe de
retry est > 1 et <= maxParallel. Validé par mutation (take(_maxParallel) →
take(1) fait échouer le test). 16/16 sur le fichier, 1756 tests des consommateurs
du fetcher au vert, dart analyze propre.

Ce qui n'est pas prouvé

Le gain ci-dessus vient d'un banc qui reproduit la structure des deux passes avec des
latences simulées — pas d'une mesure terrain de address.statement avant/après. Je
n'ai pas pu produire cette mesure : le run sur binaire recompilé se bloque (voir la
section « sockets pendantes » de mon commentaire précédent). Un scan réel de 95 000
blocs passe bien en 64,8 s, mais avec chunks_failed: 0 — la passe de retry n'y est
jamais déclenchée, donc ce run ne mesure pas le correctif.

Autrement dit : le correctif est prouvé au niveau unitaire et sur banc, pas encore
en conditions réelles au sens de la RÈGLE #0.

[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.

✅ Ce qui est livré et vérifié

endpoint purge-stale existe enfin (il était absent de la 1.25.0 publique, cf. mon
retour du 14/08) — en MCP (endpoint.purge_stale) et en CLI :

$ alter-cli endpoint purge-stale --profile=expert
Purge des endpoints RPC obsolètes
30 endpoint(s) personnalisé(s) analysé(s).
Aucun endpoint obsolète détecté.

Le provisionnement est propre. Sur une session MCP fraîche,
collection.add(collection_id: "rmm-v3") ne pose que 4 RPC Gnosis :

chain.list (chain_id 100) → rpc.gnosischain.com, rpc.gnosis.gateway.fm,
                            rpc.eu-central-2.gateway.fm, rpc.ap-southeast-1.gateway.fm

Aucun des 8 endpoints morts du rapport d'origine, et aucune réinjection ChainList.
La cause « endpoints périmés » est donc bien traitée.

❌ Mais la latence n'est pas résolue

Scénario exact de l'issue rejoué (wallet Gnosis, preset_id: "stablecoins",
01/06/2026 → 31/07/2026), en session MCP persistante, chaîne provisionnée via
collection.add rmm-v3 :

aucune réponse après plus de 30 minutes (test arrêté de mon côté).

Le rapport d'origine mesurait 850 s (~14 min). On est au-delà, avec des RPC sains cette
fois. perf(rpc): paralléliser la passe de retry des chunks de logs (bf4eeb887)
n'a pas suffi sur ce cas.

Cela confirme le rectificatif que j'ai posté le 19/08 : mon hypothèse de départ
— « les endpoints morts causent la latence » — était fausse. Les endpoints sont sains,
la latence demeure. Le goulot est ailleurs : volume de logs à scanner et stratégie de
chunking, pas santé du pool RPC.

Même symptôme sur les autres scans lourds de cette build, ce qui suggère une cause
commune plutôt qu'un défaut propre à address.statement :

Tool	Durée	État
address.statement (2 mois, 5 tokens)	> 30 min	jamais rendu
address.lending_risk_score (pool RMM v3)	1500 s (25 min)	toujours running
token.holders (vdUSDC)	> 400 s	toujours running

Observabilité : le point le moins cher à corriger

Sur les trois, progress.percent vaut None et progress_indeterminate: true,
avec des bornes figées :

t=25s    phase=scanning_borrow_events pct=None
t=750s   phase=scanning_borrow_events pct=None
t=1500s  phase=scanning_borrow_events pct=None

Impossible de distinguer « ça avance » de « c'est bloqué ». La suggestion n°2 du ticket
d'origine (avertir en amont plutôt qu'après 14 min) reste donc entière, et j'y
ajouterais : exposer l'avancement réel pendant le scan. Les bornes
from_block/to_block/estimated_blocks sont déjà calculées — il « suffirait »
d'y adjoindre les blocs effectivement traités.

Deux frictions CLI relevées au passage

• alter-cli endpoint --help et alter-cli help endpoint répondent
  « Aide non disponible pour "endpoint" », alors que les méthodes existent.
  Sans --profile=expert, purge-stale échoue avec un message correct, mais rien
  ne documente la commande.
• endpoint.list existe en MCP mais pas en CLI (méthode "list" inconnue pour l'objet "endpoint"), alors que purge-stale annonce « 30 endpoints analysés »
  qu'on ne peut donc pas inspecter depuis le CLI pour comprendre de quoi il s'agit.

[spouletmathis]

Beta-test build locale — #67 : endpoints assainis, latence toujours rédhibitoire

Build testée : 5e4eb061d (2026-08-19), 83 commits après v1.25.0, compilée localement.
Inclut bf4eeb887 perf(rpc): paralléliser la passe de retry des chunks de logs (alter#67).
Session MCP persistante (sinon le job async est perdu entre deux appels).

Commande rejouée

python3 mcp_probe.py --setup rmm-v3 --tool address.statement --args '{
  "network":"gnosis",
  "wallet":"0x1c9e5e2b5e2ff3d2e0f8d0bce2c2a1a1a1a1a1a1",
  "tokens":["0x0675e8f4a52ea6c845cb6427af03616a2073538c"],
  "from":"2026-06-01","to":"2026-07-31"
}' --poll --budget 900

Périmètre : 1 wallet × 1 token × 2 mois (blocs 46464691 → 47492863, ~1,03 M blocs).

Sortie observée

[time] 797s          ← 13 min 17 s
result_confidence : complete
diagnostic        : {"status":"complete","message":"Relevé réconcilié sur le périmètre observé.","limitations":[]}
rpc calls_total   : 261     calls_failed : 0     target_network_rpc_status : healthy

Santé des endpoints Gnosis pendant le run :

https://rpc.gnosis.gateway.fm                  63 appels, 63 OK,  0 échec  → healthy  (100%)
https://rpc.ap-southeast-1.gateway.fm/...      64 appels, 64 OK,  0 échec  → healthy  (100%)
https://rpc.eu-central-2.gateway.fm/...        79 appels, 70 OK,  9 échecs → degraded (89%)

Verdict : ⚠️ partiel

Ce qui est corrigé : le point le plus grave de l'issue — « 8/11 endpoints RPC publics par
défaut à 100 % d'échec » — ne se reproduit plus. Le pool Gnosis est sain (261 appels,
0 échec global, 2 endpoints sur 3 à 100 %), et le relevé se termine bien en état terminal
avec result_confidence: complete et un diagnostic explicite. C'est une vraie amélioration
par rapport au run d'origine.

Ce qui ne l'est pas : la latence. 797 s pour 1 wallet × 1 token × 2 mois, sur une
adresse sans aucun mouvement (observed_events: [], accounting_entries: [],
opening = closing = 0). Autrement dit : 13 minutes pour produire un relevé vide. Le
parallélisme du retry n'attaque pas le coût dominant, qui est le balayage de la plage de
blocs elle-même.

À noter aussi : un premier run lancé sur la même adresse sans tokens ni preset_id
échoue immédiatement (invalid_arguments: Provide exactly one of "tokens" or "preset_id").
C'est un bon garde-fou, mais il implique qu'un relevé « tout le portefeuille » passe par un
preset — donc N tokens, avec le coût ci-dessus comme unité.

Impact usage

C'est l'usage n°1 de ce tool ici : produire le relevé annuel de mouvements RealT/RMM v3
pour la déclaration 3916 et les justificatifs fiscaux. À 797 s pour 2 mois et 1 token,
un exercice complet (12 mois, portefeuille multi-tokens) n'est pas atteignable dans une
session — et la préparation IR retombe sur la reconstitution manuelle (exports RealT/Tediji

• explorer). Cela devient critique : Gnosisscan ferme le 11/08/2026 et l'API Gnosis passe
  payante le 01/09/2026, donc le contournement explorer disparaît sous peu.

Cas de test

Commande de repro ci-dessus. Reproductible sur build 5e4eb061d, session MCP persistante,
collection rmm-v3 provisionnée, sans clé API explorer.

Observé vs attendu

Observé : 797 s pour 1 wallet × 1 token × ~1,03 M blocs, relevé vide (0 événement)
Attendu : résultat terminal en < 300 s sur ce même périmètre
Justification de l'attendu : 261 appels RPC en tout, latence moyenne mesurée 52–183 ms,
soit ~30 s de temps RPC cumulé si séquentiel. Les 797 s ne sont pas expliquées par le
réseau — l'écart est dans l'orchestration du balayage.

✅ Test d'acceptation

1. Le relevé ci-dessus retourne un état terminal en < 300 s (borne temporelle).
2. Sur une adresse sans mouvement, le coût reste proportionné : observed_events == []
   ne doit pas coûter le prix d'un scan complet (court-circuit attendu).
3. meta.rpc_metrics.calls_failed == 0 et target_network_rpc_status == healthy
   (non-régression de l'assainissement des endpoints).
4. result_confidence reste complete et diagnostic.limitations reste vide sur ce cas.
5. Cas limite : sur 12 mois, le tool doit soit terminer, soit exposer une progression
   exploitable (progress.phase + bornes de blocs) permettant une reprise — pas un job
   opaque de plusieurs dizaines de minutes.

Réserves

Le wallet testé est vide sur ce token : la mesure isole donc le coût de balayage, mais ne
dit rien du coût additionnel de classification quand il y a des mouvements — qui ne peut
qu'être supérieur. Aucune clé API explorer configurée pendant le test.