lending.pool_snapshot: totals aggregate non-borrowable collateral — reports 33% utilization / $29.9M available on a pool at 100% / $0

[spouletmathis]

Interface: MCP (via alter-cli mcp)
Alter version: 1.25.0
Platform: macOS 26.6.1 (Build 25G76)
Date: 2026-08-14

Résumé

Sur un pool dont certaines réserves ne sont pas empruntables, totals agrège collatéral pur et actifs empruntables. Résultat : une utilisation de 33 % et $29,9M de liquidité disponible sur un pool réellement à 100 % d'utilisation et $0 de liquidité.

Le détail par réserve est correct — seul l'agrégat induit en erreur.

Repro

alter-cli mcp lending.pool_snapshot --json '{
  "network":"gnosis",
  "pool_address":"0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3",
  "block_tag":"latest"
}' --timeout 90

Observé

totals:
  total_supply_usd:        44 574 025.84
  available_liquidity_usd: 29 936 466.88
  total_debt_usd:          14 711 414.74
  utilization_pct:         33.0

reserves (corrects) :
  WXDAI       supply=5 862 312.02   debt=5 863 207.29  avail=0.0          util=100.02
  USDC        supply=8 843 646.07   debt=8 844 974.11  avail=0.0          util=100.02
  RTW-USD-01  supply=29 868 067.75  debt=0.0           avail=29 936 466.38 util=0.0
  REUSD       supply=0.0            debt=3 233.34      avail=0.5          util=0.0

Attendu

utilization_pct: 100.02 et available_liquidity_usd: 0.0, calculés sur les seuls actifs empruntables (USDC + WXDAI).

RTW-USD-01 est un collatéral pur : borrowing_enabled = false on-chain, LTV 60 %. Sa "liquidité disponible" de $29,9M n'est empruntable par personne. L'inclure dans l'agrégat masque exactement l'information critique sur ce pool : il est gelé, plus aucun prêteur ne peut retirer.

Cause probable — borrowing_enabled non renseigné

Toutes les réserves remontent borrowing_enabled: None, y compris USDC/WXDAI (empruntables) et RTW-USD-01 (non empruntable). Le champ existe dans le schéma mais n'est pas peuplé, ce qui explique sans doute que l'agrégation ne puisse pas distinguer les deux catégories.

À noter : debt_totals_by_asset_type classe correctement collateral_only: 14711402.52, la structure de classification est donc déjà en place côté données.

Suggestions

1. Peupler borrowing_enabled par réserve depuis la configuration on-chain.
2. Exclure les réserves non empruntables de utilization_pct et available_liquidity_usd, ou exposer les deux agrégats côte à côte (borrowable_totals existe déjà mais retourne reserve_count: 0 et des zéros).

Impact

Sur RMM v3 (le pool utilisé ici), l'écart entre "33 % d'utilisation, $29,9M disponibles" et "100 %, $0 disponible" est la différence entre un pool sain et un pool en crise de liquidité depuis janvier 2026. Notre script contourne en recalculant sur USDC+WXDAI uniquement, mais un agent qui lit totals de bonne foi conclut l'inverse de la réalité.

[spouletmathis]

Complément — reproduit aussi via MCP direct, avec RPC sains

Le rapport initial passait par alter-cli mcp. Retest via le serveur MCP directement, sur une chaîne Gnosis fraîchement ajoutée avec 2 RPC sains uniquement :

meta.rpc_metrics: calls_total: 3, calls_succeeded: 3, fallback_used: false
data.result_confidence: "complete"

Le bug persiste à l'identique : utilization_pct: 33.0, available_liquidity_usd: 29936466.88.

Ce n'est donc pas un effet de bord des échecs RPC décrits en #71 — c'est bien un bug d'agrégation, reproductible sur les deux interfaces (CLI et MCP).

Cause racine identifiée — usage_role mal classé

La réponse MCP expose un champ usage_role par réserve, absent de ma lecture initiale. Les 4 réserves sont classées collateral_only :

Réserve	usage_role	total_variable_debt_raw	variable_borrow_apy_pct	Classement correct
WXDAI	collateral_only	5 864 593 128 549 717 934 229 287	7.94	empruntable
USDC	collateral_only	8 846 387 729 318	7.94	empruntable
RTW-USD-01	collateral_only	0	0.0	collateral_only ✔
REUSD	collateral_only	3 233 338 258 718 844 780 559	0.0	dette gelée

USDC et WXDAI portent chacun une dette variable non nulle et un APY d'emprunt de 7,94 % — ils sont donc empruntables, et ne peuvent pas être collateral_only.

Conséquence directe : borrowable_totals.reserve_count: 0, donc l'agrégat "empruntable" est vide et totals retombe sur la somme des 4 réserves, RTW-USD-01 inclus.

La correction de usage_role devrait résoudre le bug d'agrégation en amont, puisque borrowable_totals existe déjà et est correctement structuré.

Tests d'acceptation

Vérité terrain (RPC direct, 2026-08-14, pool RMM v3 sur Gnosis) : utilisation 100,02 %, liquidité disponible $0.

Test 1 — usage_role correct par réserve

alter-cli mcp lending.pool_snapshot --json '{"network":"gnosis","pool_address":"0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3","block_tag":"latest"}'

Critère :

• USDC (0xddafbb505ad214d7b80b1f830fccc89b60fb7a83) → usage_role indiquant un actif empruntable
• WXDAI (0xe91d153e0b41518a2ce8dd3d7944fa863463a97d) → idem
• RTW-USD-01 (0xd3dff217818b4f33eb38a243158fbed2bbb029d3) → collateral_only

Invariant général : toute réserve avec total_variable_debt_raw > 0 et variable_borrow_apy_pct > 0 ne peut pas être collateral_only.

Test 2 — borrowable_totals non vide

Critère : totals.borrowable_totals.reserve_count == 2 (USDC + WXDAI), avec total_debt_usd ≈ 14 711 000 (±1 % pour les intérêts courus).

Actuel : reserve_count: 0 et tous les montants à 0.0.

Test 3 — agrégat principal cohérent

Critère :

• totals.utilization_pct ∈ [99,5 ; 100,5] → attendu 100,02
• totals.available_liquidity_usd < 1000 → attendu 0.0

Actuel : 33.0 et 29 936 466.88.

Note : si le choix produit est que totals couvre toutes les réserves, alors borrowable_totals doit être renseigné correctement (Test 2) et la documentation doit préciser lequel des deux agrégats représente l'utilisation réelle du pool. Un consommateur qui lit totals.utilization_pct sans savoir cela conclut l'inverse de la réalité.

Test 4 — non-régression sur le détail par réserve

Critère : les valeurs par réserve restent correctes (elles le sont aujourd'hui) — USDC et WXDAI à utilization_pct: 100.02 et available_liquidity_usd: 0.0.

C'est ce niveau de détail qui permet actuellement de contourner le bug en recalculant soi-même.

[spouletmathis]

Diagnostic terrain du 2026-08-15 — la cause proposée est infirmée par la configuration on-chain

Le résultat 33 % / 29,9 M$ est bien reproduit sur main (révision interne retirée). En revanche, usage_role: collateral_only ne vient pas d’un mauvais décodage : le bit Aave V3 borrowingEnabled (bit 58 de getConfiguration(asset)) vaut 0 on-chain pour les trois réserves citées :

Réserve	borrowingEnabled on-chain	Dette variable	Taux variable
WXDAI	false	non nulle	7,94 %
USDC	false	non nulle	7,94 %
RTW-USD-01	false	nulle	0 %

Les bitmaps ont été lus directement sur le pool via getConfiguration(address) puis le bit 58 a été extrait. Le service de domaine définit aujourd’hui explicitement borrowable comme « l’emprunt est activé dans la configuration ».

Une dette et un taux non nuls prouvent qu’un marché a porté — et porte encore — de la dette ; ils ne prouvent pas qu’un nouvel emprunt est actuellement autorisé. Reclasser WXDAI/USDC comme borrowable sur ce seul signal ferait donc annoncer une capacité active alors que la configuration du pool la désactive.

Reformulation recommandée

Le besoin d’agrégation reste légitime, mais il faut séparer deux axes :

1. rôle de marché : réserve portant de la dette / collatéral ;
2. état de la capacité d’emprunt : actif ou désactivé selon borrowingEnabled.

Une sortie telle que debt_bearing_totals (WXDAI + USDC, utilisation ~100 %) ou un market_role distinct permettrait de représenter le pool sans falsifier borrowable. Le critère actuel « dette + APY ⇒ borrowable » doit donc être révisé avant correction.

Issue maintenue ouverte pour trancher ce contrat de sortie ; aucun patch aval n’a été appliqué.

[spouletmathis]

Contrat corrigé selon la vérité on-chain — 2026-08-15

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

Le bit borrowingEnabled reste respecté : WXDAI/USDC ne sont pas faussement annoncés comme empruntables. Une dimension distincte market_role représente désormais le rôle économique observable et totals.debt_bearing_totals agrège les marchés portant dette et taux positifs.

Rejeu live RMM v3 :

totals.scope = all_reserves
debt_bearing_totals.reserve_count = 2
debt_bearing_totals.total_debt_usd = 14709689.77
debt_bearing_totals.available_liquidity_usd = 0.0
debt_bearing_totals.utilization_pct = 100.02
WXDAI.market_role = debt_bearing
USDC.market_role = debt_bearing
RTW-USD-01.market_role = collateral
REUSD.market_role = frozen_debt
RPC = 16/16 succès

Les totaux globaux restent explicitement tous-réserves ; le nouvel agrégat évite de confondre capacité d’emprunt actuelle et dette existante. Tests d’acceptation et make test-fast passent. Issue maintenue ouverte jusqu’au push/livraison.

[spouletmathis]

Mise à jour de livraison — 2026-08-17

La version publique actuelle est v1.25.0. Le contrat d’agrégation corrigé est désormais intégré à main et sera 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 test d’acceptation sur les binaires publiés : totals doit rester explicitement tous-réserves tandis que debt_bearing_totals doit isoler les deux marchés portant la dette et restituer une liquidité disponible nulle ainsi qu’une utilisation voisine de 100 %.

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

✅ Le fond est corrigé — agrégation vérifiée

$ alter-cli mcp lending.pool_snapshot --json '{"network":"gnosis",
    "pool_address":"0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3","block_tag":"latest"}' --mcp-binary <build>

totals.scope = borrowable_reserves

debt_bearing_totals   = {reserve_count: 2, total_debt_usd: 14721786.32,
                         available_liquidity_usd: 0.0, utilization_pct: 100.01}
all_reserves_totals   = {reserve_count: 4, available_liquidity_usd: 29923814.19,
                         utilization_pct: 33.03}

WXDAI.market_role      = debt_bearing
USDC.market_role       = debt_bearing
RTW-USD-01.market_role = collateral
REUSD.market_role      = frozen_debt

debt_bearing_totals restitue exactement la lecture attendue par le ticket :
utilisation 100,01 % et $0 de liquidité disponible sur les deux marchés portant la dette.
La séparation market_role / usage_role est la bonne abstraction, et frozen_debt
sur REUSD est un niveau de finesse utile.

Deux remarques avant clôture

1. totals racine vaut désormais 0 partout. Avec scope: borrowable_reserves et
aucune réserve empruntable au sens du bit Aave :

totals.reserve_count     = 0
totals.total_supply_usd  = 0.0
totals.utilization_pct   = 0.0

C'est défendable, mais un consommateur qui lit totals.total_supply_usd — le chemin le
plus naturel, et celui qu'utilisaient les intégrations existantes — lit maintenant 0 sur
un pool à $44 M. On a remplacé un agrégat trompeur par un agrégat vide : le premier
induisait en erreur, le second aussi, juste dans l'autre sens.

Suggestion : soit pointer totals sur all_reserves_totals (avec scope: all_reserves
explicite), soit retirer les champs plats de la racine pour forcer le choix d'un
sous-agrégat nommé.

2. borrowing_enabled est toujours None sur les 4 réserves. Le comportement est
correct sans lui (via market_role), mais le champ reste au contrat sans jamais être
peuplé. Autant le remplir depuis le bit 58 de getConfiguration(asset), ou le retirer
du schéma.

🔴 Bug distinct : le correctif est invisible depuis le CLI

$ alter-cli lending pool-snapshot --pool 0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3 \
    --network gnosis --profile=expert --mcp-binary <build>

→ data keys: [address, network, detected_roles, applicable_capabilities,
              overview, chains, sections, requested_sections, result_confidence]
   has totals: False | has reserves: False
   detected_roles: [contract, evm, lending_pool]

La sous-commande route vers address.inspect, pas vers lending.pool_snapshot.
Un utilisateur CLI n'a donc aucun accès au correctif, alors que lending --help documente
bien pool-snapshot — Snapshot réserves, supplies, debts, utilisation.

Accessoirement, la sortie est l'enveloppe MCP brute
({"content":[{"type":"text","text":"..."}]} avec le JSON échappé en string),
donc inexploitable sans double parsing.

[spouletmathis]

Retest build 5e4eb061d — routage CLI corrigé, usage_role toujours pas

Build compilée depuis le monorepo à HEAD 5e4eb061d (tag v1.25.0 +83 commits), testée
avec --mcp-binary pointant sur le binaire de cette build. ⚠️ alter-cli --version
affiche 1.25.0, identique à la release publique : ce retest ne porte pas sur le paquet
distribué.

✅ Corrigé — le routage CLI (ce2ff9733)

Le bug que je signalais dans mon commentaire précédent (la sous-commande routait vers
address.inspect) est résolu :

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

→ data keys: [network, pool_address, reserve_count, reserves, result_confidence, totals]
   has totals: True | has reserves: True

L'utilisateur CLI atteint désormais lending.pool_snapshot. Merci.

⚠️ Reste en l'état : la sortie est toujours l'enveloppe MCP brute
({"content":[{"type":"text","text":"<json échappé>"}]}), donc un double parsing est
nécessaire côté client. Point mineur mais toujours ouvert.

✅ Corrigé — debt_bearing_totals est exact

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

totals.debt_bearing_totals.reserve_count            = 2
totals.debt_bearing_totals.utilization_pct          = 100.01
totals.debt_bearing_totals.available_liquidity_usd  = 0.0
totals.debt_bearing_totals.total_debt_usd           = 14724179.73

Vérité terrain (RPC direct sur rpc.gnosischain.com, même instant —
totalSupply(aToken), balanceOf(underlying, aToken), totalSupply(vdToken)) :

Réserve	supply	dispo	dette	utilisation
WXDAI	5 870 082,11	0,00	5 870 590,21	100,01 %
USDC	8 853 565,22	0,00	8 854 267,31	100,01 %

debt_bearing_totals correspond au centime près. Le nouveau champ market_role classe
correctement les 4 réserves :

Réserve	market_role	dette > 0
WXDAI	debt_bearing	✔
USDC	debt_bearing	✔
RTW-USD-01	collateral	—
REUSD	frozen_debt	✔

C'est la bonne abstraction, et elle rend le contournement client inutile à condition de
savoir qu'il faut lire debt_bearing_totals. À préserver.

❌ Toujours ouvert — totals racine vaut 0, usage_role inchangé

Verdict sur les tests d'acceptation que j'avais posés plus haut dans ce fil :

Test	Critère	Résultat
1 — usage_role correct	USDC/WXDAI non collateral_only	❌ échoue
2 — borrowable_totals non vide	reserve_count == 2	❌ échoue (0)
3 — agrégat principal cohérent	totals.utilization_pct ∈ [99,5 ; 100,5]	❌ échoue (0.0)
4 — non-régression détail réserve	USDC/WXDAI à 100,01 % / $0	✅ passe

Les 4 réserves restent classées usage_role: "collateral_only", alors que WXDAI et USDC
portent chacun une dette variable non nulle :

symbole        usage_role       market_role    borrowing_enabled  dette>0
WXDAI          collateral_only  debt_bearing   None               True
USDC           collateral_only  debt_bearing   None               True
RTW-USD-01     collateral_only  collateral     None               False
REUSD          collateral_only  frozen_debt    None               True

borrowing_enabled est toujours None sur les 4 réserves — inchangé depuis mon
commentaire précédent.

Conséquence : borrowable_totals.reserve_count = 0, donc totals (dont le scope est
borrowable_reserves) vaut 0 partout :

totals.reserve_count            = 0
totals.total_supply_usd         = 0.0
totals.total_debt_usd           = 0.0
totals.utilization_pct          = 0.0

Impact en aval

RMM consomme Alter pour des sorties publiées (état des positions RMM v3, community
calls). Un consommateur qui lit totals.total_debt_usd — le chemin le plus évident, et
celui des intégrations écrites avant l'ajout des sous-agrégats — publie
« $0 de dette, 0 % d'utilisation » sur un pool portant 14,7 M$ de dette à 100 %.

C'est le même défaut de fond qu'au signalement initial, avec une valeur fausse
différente : 33 % hier, 0 aujourd'hui. Le faux zéro est à mon sens plus dangereux,
parce qu'il ressemble à un pool vide plutôt qu'à une anomalie — il ne déclenche aucune
suspicion chez le lecteur.

À noter : result_confidence vaut complete dans les deux cas. Ce n'est donc pas
rattrapable par le garde-fou strict=True côté client.

Ce qui reste à corriger, par ordre d'utilité

1. usage_role — c'est la cause racine. market_role prouve que l'information est
   disponible et correctement calculée ; usage_role ne la reflète pas.
2. totals racine — tant que usage_role n'est pas corrigé, faire retomber totals
   sur un agrégat non vide (ou retirer les champs plats de la racine pour forcer le choix
   explicite d'un sous-agrégat).
3. borrowing_enabled — le peupler depuis le bit 58 de getConfiguration(asset), ou
   le retirer du schéma.

Les tests d'acceptation 1 à 3 de mon commentaire précédent restent valables tels quels
comme critères de fin.

[spouletmathis]

Beta-test build locale — #73 : la classification est corrigée, l'agrégat de tête ne l'est pas

Build testée : 5e4eb061d (2026-08-19), 83 commits après v1.25.0, compilée localement.
Inclut ce2ff9733 fix(cli): router lending pool-snapshot vers lending.pool_snapshot (alter#73).

Commande rejouée

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

Sortie observée — data.totals

{
 "reserve_count": 0,
 "total_supply_usd": 0.0,
 "available_liquidity_usd": 0.0,
 "total_debt_usd": 0.0,
 "utilization_pct": 0.0,
 "scope": "borrowable_reserves",

 "all_reserves_totals":   {"reserve_count":4,"total_supply_usd":44566814.03,"available_liquidity_usd":29912065.08,"utilization_pct":33.05},
 "borrowable_totals":     {"reserve_count":0,"total_supply_usd":0.0,"available_liquidity_usd":0.0,"utilization_pct":0.0},
 "debt_bearing_totals":   {"reserve_count":2,"total_supply_usd":14722969.83,"available_liquidity_usd":0.0,"total_debt_usd":14724179.91,"utilization_pct":100.01},
 "collateral_totals":     {"reserve_count":4,"total_supply_usd":44566814.03,"available_liquidity_usd":29912065.08,"utilization_pct":33.05}
}

Détail des réserves :

WXDAI      | usage_role=collateral_only | market_role=debt_bearing  | supply=5869759.08  | debt=5870267.15 | util=100.01
USDC       | usage_role=collateral_only | market_role=debt_bearing  | supply=8853211.08  | debt=8853913.14 | util=100.01
RTW-USD-01 | usage_role=collateral_only | market_role=collateral    | supply=29843844.20 | debt=0.0        | util=0.0
REUSD      | usage_role=collateral_only | market_role=frozen_debt   | supply=0.0         | debt=3233.34    | util=0.0

Verdict : ⚠️ partiel

Ce qui est livré : market_role classe correctement — WXDAI et USDC en debt_bearing,
RTW-USD-01 en collateral, REUSD en frozen_debt. Et debt_bearing_totals donne
exactement les valeurs demandées par l'issue : utilization_pct = 100.01,
available_liquidity_usd = 0.0, reserve_count = 2. La distinction demandée existe donc
bien dans le modèle.

Ce qui ne l'est pas : l'agrégat de tête data.totals.* — celui qu'une intégration lit
en premier — annonce reserve_count: 0 et 0.0 partout, avec scope: "borrowable_reserves". La cause est usage_role, qui vaut collateral_only pour les
4 réserves, y compris WXDAI et USDC empruntés à 100 %. Comme totals est calculé sur
ce champ et non sur market_role, le seau borrowable est vide et l'agrégat s'effondre à
zéro.

Le symptôme du titre de l'issue (33 % / $29,9 M) a donc changé de forme : il est encore
présent dans all_reserves_totals / collateral_totals, et totals affiche désormais 0
au lieu de 33 %. Pour un consommateur qui lit totals.total_supply_usd, c'est passé de
« valeur trompeuse » à « zéro sur un pool à 44 M$ » — plus visible, mais pas plus juste.

Impact usage

Le suivi RMM v3 lit totals pour situer la position (collatéral, dette, santé). Une
intégration qui affiche totals.total_supply_usd publie 0 € sur un pool à 44,5 M$.
Contournement actuel : lire debt_bearing_totals en sachant qu'il faut l'y chercher —
ce qui suppose de connaître ce bug.

Cas de test

Commande de repro : celle ci-dessus (état de chaîne dépendant, mais le rapport
usage_role vs market_role est structurel).

Observé vs attendu

Observé  : totals.reserve_count = 0     totals.utilization_pct = 0.0     scope=borrowable_reserves
           WXDAI.usage_role = collateral_only   (alors que market_role = debt_bearing, util = 100.01)
Attendu  : usage_role de WXDAI et USDC reflète qu'ils portent de la dette
           totals non nul, ou scope explicitement documenté comme pouvant être vide
Vérité terrain : WXDAI et USDC à 100,01 % d'utilisation, $0 disponible — cohérent avec
                 debt_bearing_totals renvoyé par le tool lui-même

✅ Test d'acceptation

1. totals.debt_bearing_totals.utilization_pct ≈ 100 (±0,5)
2. totals.debt_bearing_totals.available_liquidity_usd == 0.0
3. totals.debt_bearing_totals.reserve_count == 2
4. reserves[WXDAI].market_role == "debt_bearing" et son usage_role n'est plus
   collateral_only (ou bien totals cesse d'être calculé sur usage_role)
5. totals.reserve_count != 0 sur un pool non vide — ou scope documente explicitement
   qu'un agrégat vide est un état légitime, et les consommateurs sont dirigés vers
   all_reserves_totals
6. Anti-régression : les 4 réserves restent listées avec leur usage_role,
   market_role, APY et available_liquidity_source

Réserves

Les valeurs USD dépendent de l'état de la chaîne au moment du run (block_tag: latest) ;
les ratios (100,01 % / 33,05 %) et la classification sont eux stables sur les runs répétés.

[spouletmathis]

Retest — build 31076cc86 (v1.25.0 +94 commits) : ✅ le grief est levé

Suite de mon commentaire du 19/08 sur la build 5e4eb061d. Nouvelle build,
11 commits plus loin, dont eec3ad551 fix(mcp): déclarer le scope vide et exposer borrowing_enabled (alter#73). Testée via --mcp-binary.

Commande — identique à celle du 19/08

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

Sortie observée — data.totals

{
 "reserve_count": 0, "total_supply_usd": 0.0, "available_liquidity_usd": 0.0,
 "total_debt_usd": 0.0, "utilization_pct": 0.0, "scope": "borrowable_reserves",

 "all_reserves_totals":  {"reserve_count":4,"total_supply_usd":44568374.05,"available_liquidity_usd":29912065.08,"total_debt_usd":14729147.39,"utilization_pct":33.05},
 "borrowable_totals":    {"reserve_count":0,"total_supply_usd":0.0,"utilization_pct":0.0},
 "debt_bearing_totals":  {"reserve_count":2,"total_supply_usd":14724529.85,"available_liquidity_usd":0.0,"total_debt_usd":14725914.05,"utilization_pct":100.01},
 "collateral_totals":    {"reserve_count":4,"total_supply_usd":44568374.05,"available_liquidity_usd":29912065.08,"utilization_pct":33.05},
 "debt_totals_by_asset_type": {"borrowable":0.0,"collateral_only":14729147.39,"debt_only":0.0},

 "scope_is_empty": true,
 "non_empty_scopes": ["all_reserves_totals","debt_bearing_totals","collateral_totals"],
 "scope_note": "Top-level totals describe scope \"borrowable_reserves\", which is empty here: no reserve currently has borrowing enabled. The pool itself is not empty. Read all_reserves_totals for the whole pool, or debt_bearing_totals for the markets actually carrying debt — top-level zeros do not mean an empty pool."
}

Réserves :

WXDAI      | market_role=debt_bearing | borrowing_enabled=false | util=100.01 | avail=0.0
USDC       | market_role=debt_bearing | borrowing_enabled=false | util=100.01 | avail=0.0
RTW-USD-01 | market_role=collateral   | borrowing_enabled=false | util=0.0    | avail=29912064.58
REUSD      | market_role=frozen_debt  | borrowing_enabled=false | util=0.0    | avail=0.5

Statut des 6 critères d'acceptation du 19/08

#	Critère	Statut
1	debt_bearing_totals.utilization_pct ≈ 100 (±0,5)	✅ 100.01
2	debt_bearing_totals.available_liquidity_usd == 0.0	✅ 0.0
3	debt_bearing_totals.reserve_count == 2	✅ 2
4	WXDAI.market_role == "debt_bearing" et usage_role n'est plus collateral_only, ou totals cesse d'être calculé sur usage_role	⚠️ usage_role reste collateral_only, mais borrowing_enabled: false est désormais exposé et rend la classification vérifiable
5	totals.reserve_count != 0, ou le scope documente qu'un agrégat vide est légitime et redirige	✅ par la seconde branche — scope_is_empty, non_empty_scopes, scope_note
6	Anti-régression : les 4 réserves restent listées avec leurs rôles	✅ 4 réserves, rôles + APY + available_liquidity_source intacts

Verdict

Le grief de fond est levé. Mon reproche du 19/08 n'était pas que totals
vaille 0 — c'est un état légitime sur un pool où aucune réserve n'a
borrowing_enabled — mais qu'un consommateur ne puisse pas distinguer « scope
vide » de « pool vide ». scope_note et non_empty_scopes répondent
précisément à ça, en dirigeant vers le bon seau depuis la réponse elle-même.

Sur le critère 4, je retire une partie de mon exigence initiale : demander que
usage_role change de valeur était une solution que je proposais, pas le
besoin. borrowing_enabled: false sur les 4 réserves explique le scope vide de
façon vérifiable, ce qui suffit. Je préfère le dire plutôt que laisser traîner
un critère qui enverrait vers une refonte inutile.

Impact pipeline

Le suivi RMM v3 peut désormais lire debt_bearing_totals en le sachant depuis
la réponse, sans avoir à connaître ce bug au préalable. C'était tout l'objet
de la remontée.

Réserves

Valeurs USD dépendantes de block_tag: latest ; les ratios (100,01 / 33,05) et
la classification sont stables sur runs répétés. Non testé : un pool ayant au
moins une réserve borrowing_enabled: true, où le scope de tête serait non vide
— c'est le chemin nominal, que je n'ai pas de moyen de jouer sur Gnosis ici.

Je ne clos pas l'issue.

[spouletmathis]

Beta-test build locale — ✅ corrigé sur les deux surfaces

Build testée : 31076cc86 (2026-08-20), 94 commits après v1.25.0, dart compile exe,
macOS 26.6.1 arm64. Pas le paquet Homebrew — token.holders répond ici, Unknown tool sur
le Homebrew 1.25.0.

Commande rejouée

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

Test d'acceptation de l'issue — 5/5

OK  1. debt_bearing.utilization_pct ≈ 100 (±0,5)      : 100.01
OK  2. debt_bearing.available_liquidity_usd == 0.0    : 0.0
OK  3. debt_bearing.reserve_count == 2                : 2
OK  4. WXDAI.market_role == "debt_bearing"            : debt_bearing
OK  5. anti-régression : 4 réserves, usage_role conservé

Ce que le correctif apporte au-delà du critère

Le vide n'est plus muet, il est qualifié :

"scope": "borrowable_reserves",
"scope_is_empty": true,
"non_empty_scopes": ["all_reserves_totals","debt_bearing_totals","collateral_totals"],
"scope_note": "Top-level totals describe scope \"borrowable_reserves\", which is empty
 here: no reserve currently has borrowing enabled. The pool itself is not empty. Read
 all_reserves_totals for the whole pool, or debt_bearing_totals for the markets actually
 carrying debt — top-level zeros do not mean an empty pool."

borrowing_enabled est exposé par réserve (false sur les 4), et market_role distingue
debt_bearing / collateral / frozen_debt. Un consommateur qui lit les totaux
top-level tombe désormais sur des zéros explicitement documentés plutôt que sur
33,05 % / $29,9M silencieusement faux. C'est le bon compromis : le chiffre trompeur est
supprimé sans casser la forme de la réponse.

Verdict : ✅ livré — MCP et CLI

Le CLI natif expose exactement les mêmes champs :

$BUILD/alter-cli lending pool-snapshot \
  --pool 0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3 --network gnosis \
  --mcp-binary $BUILD/alter-mcp --profile=expert
# → scope=borrowable_reserves  scope_is_empty=True  market_role=debt_bearing

ce2ff9733 (routage lending pool-snapshot → lending.pool_snapshot) fonctionne, et
help lending documente bien la sous-commande.

⚠️ Piège de méthode : --mcp-binary vaut aussi pour les commandes CLI natives

Signalé parce que ça m'a fait conclure à tort à une divergence MCP/CLI pendant ce test.
Sans --mcp-binary, alter-cli lending pool-snapshot spawn le alter-mcp du PATH —
donc le Homebrew 1.25.0 — et reproduit fidèlement le bug d'origine :

# sans --mcp-binary (= Homebrew 1.25.0, PAS la build)
utilization_pct: 33.05   available_liquidity_usd: 29912065.08
scope / scope_is_empty / market_role / borrowing_enabled : tous ABSENTS
result_confidence: rpc_degraded
endpoints: eth.drpc.org, optimism.drpc.org, base.drpc.org, arbitrum.drpc.org  ← #71

Aucun message ne signale que ce n'est pas la build testée. Le README du beta-test mentionne
le piège pour alter-cli mcp <tool> ; il vaut à l'identique pour toute commande CLI qui
délègue au serveur MCP. Un --version portant le SHA règlerait la question une bonne fois.

Impact usage

Ce pool est le RMM v3 sur lequel repose le suivi de position de ce projet. Une intégration
qui lit totals.total_supply_usd publiait 0 € sur un pool à 44 M$, ou 33 % d'utilisation
sur un marché à 100 % — les deux faussaient l'appréciation du risque de liquidation.
Vérifié en parallèle sur nos 2 positions réelles via lending positions-batch :
HF 0,9855 et 0,9816, collatéral 80 965 $ / 24 188 $, cohérent avec notre suivi.

Réserves

Profil chargé, collection rmm-v3, sans clé API explorer. Un seul pool testé (RMM v3
Gnosis) : je n'ai pas de pool avec borrowing_enabled: true sous la main pour vérifier que
le scope borrowable_reserves non vide reste correct — c'est le cas nominal que je n'ai
pas pu couvrir.

[spouletmathis]

Beta-test build locale — ✅ toujours corrigé, MCP et CLI

Build testée : d5126afb0 (2026-08-21). Pas le Homebrew 1.25.0.

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

OK  1. debt_bearing.utilization_pct = 100.01
OK  2. debt_bearing.available_liquidity_usd = 0.0
OK  3. debt_bearing.reserve_count = 2
OK  4. WXDAI.market_role = debt_bearing  (USDC idem ; RTW-USD-01=collateral ; REUSD=frozen_debt)
OK  5. 4 réserves, usage_role conservé
scope=borrowable_reserves  scope_is_empty=true
rpc.scope=gnosis  duration_ms=10411  rc=complete

CLI natif (lending pool-snapshot --mcp-binary … --profile=expert -f json) :
mêmes champs, mêmes totaux.

Verdict : ✅ livré — MCP et CLI

[spouletmathis]

Beta-test build c27f34c38 — ✅ toujours corrigé, MCP et CLI

Build testée : phoenix_0 HEAD c27f34c38 (2026-08-21). Pas le Homebrew 1.25.0.

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

OK  1. debt_bearing.utilization_pct = 100.01
OK  2. debt_bearing.available_liquidity_usd = 0.0
OK  3. debt_bearing.reserve_count = 2
OK  4. WXDAI.market_role = debt_bearing  (USDC idem ; RTW-USD-01=collateral ; REUSD=frozen_debt)
OK  5. 4 réserves, usage_role conservé
scope=borrowable_reserves  (reserve_count=0 au niveau totals racine — borrowing_enabled=false à 100 % d'util)
rpc.scope=gnosis  duration_ms=1620  rc=complete

CLI natif (lending pool-snapshot --mcp-binary … --profile=expert -f json) : mêmes champs, mêmes totaux, 7,9 s.

Verdict : ✅ livré — MCP et CLI