address.statement : accounting_invariant_mismatch sur token wrappé RMM v3 sans mouvement observé

[spouletmathis]

Contexte

Test de address.statement v1.25.0 sur un wallet perso avec position RMM v3 (Gnosis). Voir aussi #67 (latence/RPC constatée sur le même run, cause probable de ce mismatch).

• 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

Le relevé signale diagnostic.status: "partial" avec, entre autres, un accounting_invariant_mismatch sur un token wrappé RMM v3 (0x0ca4f5554dd9da6217d62d8df2816c82bba4157b sur Gnosis) :

opening_raw: 20278630067209
closing_raw: 20532280888152
movement_net_raw: 0   (aucun mouvement détecté sur la période)
discrepancy_raw: 253650820943
status: "imbalanced"

Le solde a changé entre ouverture et clôture (delta ≈ +1,25%) sans qu'aucun mouvement n'ait été observé pour l'expliquer. Sur un token wrappé RMM, l'hypothèse la plus probable est un ajustement d'intérêt couru (aToken-like) ou un wrap/unwrap non capté par le classifieur générique — mais je n'ai pas de certitude.

Impact

Un relevé avec un invariant comptable cassé ne peut pas servir de base fiable à address.statement.translate (registre comptable/fiscal) — je n'ai donc pas pu tester cette seconde feature avec un statement propre.

Suggestion

Investiguer si le classifieur générique capte bien les événements spécifiques aux tokens wrappés RMM v3 (accrual d'intérêt, rebase, ou event de wrap/unwrap) sur ce type de contrat.

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

---

Interface : MCP Server

[spouletmathis]

Mise à jour — dépendance à #67

Le correctif de purge des endpoints RPC custom morts/retirés du registre est livré dans [référence interne retirée] (suivi RPC-CUSTOM-STALE-01, issue #67).

Pourquoi ça touche #70

L’hypothèse initiale du rapport #67 était que le accounting_invariant_mismatch sur token wrappé RMM v3 sans mouvement observé pouvait venir de logs de transfert incomplets sous RPC massivement en échec, plutôt que d’un défaut du classifieur générique.

Prochaine action

1. Appliquer le scénario d’acceptation 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 (purge-stale puis même address.statement).
2. Si le mismatch disparaît avec des RPC sains → documenter ici et clôturer address.statement : accounting_invariant_mismatch sur token wrappé RMM v3 sans mouvement observé #70 comme collatéral 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.
3. Si le mismatch persiste → investiguer le classifieur / les events spécifiques aux tokens wrappés RMM v3 (accrual d’intérêt, rebase) — hors scope de la purge RPC.

Issue maintenue ouverte en attendant le résultat du retest post-#67.

[spouletmathis]

Correctif livré (indépendant de #67)

PR : [référence interne retirée]
Commit : fix(statement): comptabiliser l'intérêt aToken sans Transfer

Cause

Les aTokens RMM font évoluer balanceOf via liquidityIndex sans event Transfer → movement_net_raw: 0 alors que opening ≠ closing → faux accounting_invariant_mismatch.

Fix

• Détection via RebasingDetector (registre statique inclut le token aToken RMM signalé)
• Écriture synthétique interest_accrual pour combler l’écart d’index
• Câblé dans MCP address.statement

Scénario d’acceptation

Relancer le même address.statement (hold aToken RMM, période multi-mois) sur un build de la PR :

• plus de accounting_invariant_mismatch pour le seul drift d’intérêt
• présence d’une entry interest_accrual

Issue maintenue ouverte jusqu’à confirmation. Si le mismatch persiste après purge RPC (#67), rouvrir l’analyse classifieur.

[spouletmathis]

Tests d'acceptation anti-régression (RÈGLE #0)

Fichier hermétique (aucun RPC) :
alter/packages/core/test/acceptance/alter_bugs_65_70_18_59_acceptance_test.dart

Commit : révision interne retirée sur [référence interne retirée]

Les scénarios reproduisent la condition du bug (pas un assert cosmétique) et vérifient le comportement attendu post-fix. Exécution locale :

cd alter/packages/core && dart test test/acceptance/alter_bugs_65_70_18_59_acceptance_test.dart

[spouletmathis]

Correction par preuve on-chain exacte — 2026-08-15

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

Le correctif ne fabrique plus une écriture d’intérêt à partir du seul fait qu’un token est rebasing. Pour un aToken Aave V3-compatible, il exige simultanément la preuve du pool/réserve, un scaledBalanceOf identique aux deux blocs, un liquidity index croissant et la reconstruction exacte des deux balanceOf.

Rejeu publiable sur le contrat protocolaire armmv3WXDAI, blocs 47732088–47735097 :

observed_events = 0
classification = interest_accrual
rule_id = aave_v3_atoken_index_delta_v1
amount_raw = 658360525115079
opening_scaled_balance == closing_scaled_balance
wallet invariant = balanced, discrepancy_raw = 0
aggregate invariant = balanced, discrepancy_raw = 0
diagnostic = complete
RPC = 7/7 succès
duration_ms = 899

Le test d’acceptation couvre aussi le garde-fou : le même écart sur un token non rebasing reste imbalanced. Issue maintenue ouverte jusqu’au push/livraison.

[spouletmathis]

Mise à jour de livraison — 2026-08-17

La version publique actuelle est v1.25.0. Le correctif de preuve on-chain pour les intérêts courus 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 scénario d’acceptation sur les binaires publiés : le cas original doit produire une écriture interest_accrual uniquement lorsque les preuves Aave V3 sont exactes, avec invariants portefeuille et agrégat équilibrés, écart nul et diagnostic complet.

[spouletmathis]

Point de suivi 19/08/2026 — le retrait de l'écriture synthétique est le bon arbitrage, la dépendance à #67 se confirme

Retest sur les binaires compilés depuis phoenix_0 (c13599a95), scénario identique à celui de l'issue.

Le comportement actuel est correct

Le relevé ne fabrique plus d'écriture interest_accrual avec un observed_event_id synthétique. Il retourne désormais :

result_confidence: partial
diagnostic.status:  partial
limitations: [
  {code: "incomplete_transfer_logs",
   message: "Le scan des transferts pour le token 0xddafbb... a dépassé
             la limite autorisée ou a rencontré des erreurs RPC,
             limitant l'exhaustivité du relevé."},
  ...
]

C'est le bon arbitrage. Pour un usage déclaratif ou fiscal, un relevé qui annonce honnêtement « scan incomplet » vaut mieux qu'un invariant réconcilié par une écriture non prouvée. Le retrait du 09/08 conformément à ADR-0092 va dans le bon sens, et je ne demande pas son rétablissement.

La dépendance à #67 se confirme, mais par un autre mécanisme que supposé

L'hypothèse posée dans l'issue — logs de transfert incomplets à cause d'endpoints RPC dégradés — se vérifie sur le fond, mais la cause des scans incomplets n'est pas celle qu'on croyait.

Après purge des endpoints morts (voir mon retest sur #67), les 5 endpoints Gnosis restants sont tous sains (réponse en 0,1–0,38 s). Les limitations incomplete_transfer_logs persistent malgré tout, parce que le facteur limitant est le traitement des chunks échoués : la période de 2 mois est découpée en ~211 chunks de 5 000 blocs, et ceux qui échouent en première passe sont retentés séquentiellement.

Autrement dit : ce ne sont pas des endpoints morts qui tronquent le scan, c'est le traitement des chunks échoués sur des endpoints sains.

Précisément (voir mon retest détaillé sur #67) : dans paginated_log_fetcher.dart, la passe de retry des chunks échoués est séquentielle avec 200 ms de délai par chunk. Sur une plage de 2 mois (~211 chunks), les chunks qui échouent en première passe sont retentés un par un — d'où à la fois la latence et, quand le budget de temps est épuisé, les incomplete_transfer_logs qui subsistent.

Conséquence pour cette issue

Tant que le scan ne couvre pas la période complète, l'écart de balance sur l'aToken restera indistinguable d'un vrai trou de données — donc rebasing_balance_delta_unproven restera le verdict correct, et il n'y a pas moyen de trancher entre accrual d'intérêt et mouvement non observé.

La preuve on-chain explicite envisagée (index ou balance scalée aux bornes) reste la bonne direction, mais elle sera plus simple à valider une fois qu'un scan complet est possible. Je suggère de traiter #67 d'abord.

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

⛔ Non vérifiable sur cette build — bloqué par #67

Le scénario d'acceptation n'a pas pu être joué : address.statement (même wallet Gnosis,
preset_id: "stablecoins", 01/06/2026 → 31/07/2026, session MCP persistante avec chaîne
provisionnée par collection.add rmm-v3) n'a rendu aucune réponse après plus de
30 minutes.

Sans relevé, je ne peux donc rien observer : ni la disparition du faux
accounting_invariant_mismatch, ni la présence — ou l'absence — d'une écriture
interest_accrual correctement prouvée.

Ce que je peux dire, et ce que je ne peux pas

Le code du correctif est dans la build : RebasingDetector (avec les variantes
static_registry, symbol_prefix, abi_introspection) et interest_accrual câblé
dans generate_activity_statement_use_case.dart.

Mais c'est une constatation de présence de code, pas une preuve d'exécution. Je ne
la présente pas comme une validation : tant que le relevé ne se termine pas, le
comportement reste non observé.

Cette issue reste donc suspendue à #67, comme déjà noté dans le fil le 08/08. Je la
reteste dès que address.statement converge sur ce périmètre.

Pour mémoire, mon point de suivi du 19/08 tient toujours : le retrait de l'écriture
synthétique au profit d'une preuve on-chain exacte me paraît le bon arbitrage, et le
repli sur incomplete_transfer_logs est un comportement honnête. C'est la vérification
de bout en bout qui manque, pas la direction prise.

[spouletmathis]

Beta-test build locale — #70 : non reproduit, mais sur un cas qui n'éprouve pas l'invariant

Build testée : 5e4eb061d (2026-08-19), 83 commits après v1.25.0, compilée localement.
Inclut fbcd7222d fix(statement): comptabiliser l'intérêt aToken sans Transfer (alter#70).
Session MCP persistante, collection rmm-v3 provisionnée.

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

Sortie observée

"invariants": {"wallets": [{
  "scope":"wallet", "opening_raw":"0", "movement_net_raw":"0",
  "expected_closing_raw":"0", "closing_raw":"0", "discrepancy_raw":"0",
  "status":"balanced"
}]},
"diagnostic": {"status":"complete","message":"Relevé réconcilié sur le périmètre observé.","limitations":[]},
"observed_events": [], "accounting_entries": [],
"result_confidence": "complete"

Aucune occurrence de accounting_invariant_mismatch dans la réponse.

Verdict : ⛔ non vérifiable en l'état

Le symptôme ne se reproduit pas, mais le cas testé ne prouve rien : le wallet est vide
sur ce token (opening_raw == closing_raw == 0, aucun mouvement observé). Un invariant
0 = 0 + 0 est balanced par construction, y compris si le bug d'origine — l'intérêt
aToken qui s'accumule sans événement Transfer — était toujours présent. C'est
précisément le scénario que ce cas n'atteint pas.

Je préfère le dire plutôt que de porter un ✅ que la mesure ne soutient pas.

Ce qui manque pour trancher : un wallet portant effectivement un token wrappé RMM v3
avec une position active sur la période, où closing_raw > opening_raw sans aucun
Transfer entrant. Je n'ai pas de wallet de ce profil que je puisse publier ici en dur.

Ce que le test établit quand même

• Le tool termine en état terminal, réconcilie, et expose un bloc invariants structuré
  (opening_raw / movement_net_raw / expected_closing_raw / discrepancy_raw / status)
  — ce contrat est bien en place et exploitable.
• diagnostic.limitations est vide et explicite plutôt que silencieux.

✅ Test d'acceptation (à rejouer sur un wallet éprouvant)

Sur un wallet détenant un aToken RMM v3 avec intérêt accumulé sur la période, sans
Transfer entrant :

1. invariants.wallets[].status == "balanced"
2. discrepancy_raw == "0" alors que closing_raw > opening_raw
3. accounting_entries contient une écriture d'intérêt expliquant l'écart (et non un
   simple ajustement silencieux)
4. movement_net_raw == closing_raw - opening_raw
5. Anti-régression : sur un wallet vide, le relevé reste balanced avec des entrées vides,
   comme ci-dessus.

Réserves

Le run a coûté 797 s pour ce périmètre minimal (cf. #67) — ce qui limite en pratique
la possibilité de balayer plusieurs wallets candidats pour en trouver un éprouvant.
Les deux sujets sont liés : tant que #67 n'est pas réglé, valider #70 sur un cas réel
est coûteux.

[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é : fbcd7222d — fix(statement): comptabiliser l'intérêt aToken sans Transfer.

Commande rejouée

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis",
  "wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x0ca4f5554dd9da6217d62d8df2816c82bba4157b",
            "0xed56f76e9cbc6a64b821e9c016eafbd3db5436d1"],
  "from":"2026-06-01","to":"2026-07-31"
}' --mcp-binary $BUILD/alter-mcp --timeout 900

Même wallet, même token wrappé, même période que le run d'origine — l'opening_raw est
identique au chiffre de l'issue (20278630067209), ce qui confirme qu'on rejoue bien le
même cas.

Observé vs attendu

Avant (issue)          Après (cette build)
opening_raw      : 20278630067209        20278630067209   (identique)
closing_raw      : 20532280888152        20534438874517   (2 mois d'accrual en plus)
movement_net_raw : 0                     255808807308     ← le mouvement est capté
discrepancy_raw  : 253650820943          0
status           : "imbalanced"          "balanced"

L'écart n'est plus un trou : il est identifié, quantifié et rattaché à une cause.

Ce qui rend le correctif utilisable en comptabilité

L'écart produit désormais une écriture typée, avec sa règle et ses preuves :

{
 "accounting_entry_id": "proof:interest_accrual:0x15ed1e0c…:0x0ca4f555…:46464691:47492863",
 "direction": "incoming",
 "amount_raw": "255808807308",
 "classification": {
   "classification": "interest_accrual",
   "classification_source": "protocol_rule",
   "rule_id": "aave_v3_atoken_index_delta_v1",
   "evidence_refs": [
     "eth_call:scaledBalanceOf@46464691",
     "eth_call:getReserveNormalizedIncome@46464691",
     "eth_call:scaledBalanceOf@47492863",
     "eth_call:getReserveNormalizedIncome@47492863",
     "eth_call:getReserveData@47492863"
   ],
   "confidence": "high"
 },
 "metadata": {"kind":"aave_a_token","protocol":"aave_v3_compatible",
              "detector_source":"registry","detector_confidence":"registry_hit"}
}

C'est exactement la forme dont un justificatif fiscal a besoin : un montant, une nature
(interest_accrual — produit imposable, pas un transfert), une règle nommée et 5 appels
on-chain rejouables. Bien mieux qu'un simple rééquilibrage de l'invariant.

Les invariants aggregate sont balanced eux aussi (expected_closing_raw == closing_raw, discrepancy_raw: 0).

Verdict : ✅ livré

Mesure : discrepancy_raw passe de 253650820943 à 0, status de imbalanced à
balanced, sur le cas exact de l'issue.

Impact usage

L'issue notait que address.statement.translate était inexploitable faute de statement
propre. Ce blocage est levé : le relevé se réconcilie et l'accrual est classé. Pour ce
projet, c'est la brique qui permet d'isoler les intérêts RMM v3 des mouvements de
capital — la distinction qui compte pour la déclaration.

⚠️ Point restant, hors périmètre de cette issue

diagnostic.status reste "partial" avec deux incomplete_transfer_logs, alors que
result_confidence vaut "complete" au niveau du relevé. Les invariants sont bons, donc
ça ne remet pas en cause le correctif — mais les deux signaux se contredisent pour un
consommateur automatisé qui déciderait sur result_confidence. Je le remonte sur #67, où
je constate le même couple sur des scans dont les logs sont tronqués.

Réserves

Profil chargé, Gnosis provisionnée, collection rmm-v3, sans clé API explorer. Un seul
type de token wrappé testé (aToken WXDAI, kind: aave_a_token) : je n'ai pas exercé le
variable debt token côté emprunt, ni un wrap/unwrap réel — seul l'accrual d'intérêt est
couvert par ce test.

[spouletmathis]

Beta-test build locale — ✅ livré (rejoué à froid) — ⚠️ le preuve d'accrual est sensible à la charge RPC

Build testée : d5126afb0 (2026-08-21), 99 commits après v1.25.0, dart compile exe,
macOS 26.6.1 arm64. Pas le Homebrew 1.25.0.

Commande rejouée — cas exact (aToken WXDAI, 2 mois, wallet avec intérêt sans Transfer)

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis",
  "wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x0ca4f5554dd9da6217d62d8df2816c82bba4157b",
            "0xed56f76e9cbc6a64b821e9c016eafbd3db5436d1"],
  "from":"2026-06-01","to":"2026-07-31"
}' --mcp-binary $BUILD/alter-mcp --timeout 900

Observé — run isolé (pas d'autre scan lourd en parallèle)

opening_raw      : 20278630067209   (identique à l'issue)
closing_raw      : 20534438874517
movement_net_raw : 255808807308
discrepancy_raw  : 0
status           : balanced
n entries        : 1  (interest_accrual, rule aave_v3_atoken_index_delta_v1,
                       5 evidence_refs on-chain)
duration_ms      : 22904
rpc              : 183 appels, 180 succès, 3 échecs, scope=gnosis
result_confidence: partial     ← diagnostic.status=partial
                                 lims=['incomplete_transfer_logs' x2]

L'écriture d'accrual est identique à celle du 20/08 : même accounting_entry_id,
mêmes preuves scaledBalanceOf / getReserveNormalizedIncome. Le correctif
tient.

result_confidence est maintenant partial (hier complete malgré les mêmes
incomplete_transfer_logs) — c'est #80, pas une régression de #70.

⚠️ Run sous charge — le preuve peut échouer, et c'est dit

Premier essai, pendant qu'un token.holders scannait 33 M de blocs :

movement_net_raw : 0
discrepancy_raw  : 255808807308
status           : imbalanced
n entries        : 0
lims             : incomplete_transfer_logs x2,
                   rebasing_balance_delta_unproven,
                   accounting_invariant_mismatch
rpc              : 155 appels, 144 succès, 11 échecs

Message de rebasing_balance_delta_unproven :

Le solde […] présente un écart de 255808807308. Le token est détecté rebasing
(aave_a_token), mais aucune preuve on-chain d'index ou de balance scalée ne
permet d'attribuer cet écart à des intérêts plutôt qu'à un mouvement non observé.

Ce n'est pas un retour du bug d'origine (écart avalé sans écriture, annoncé
complete). L'outil refuse de classer l'intérêt faute de preuve, dégrade la
confiance, et nomme la cause. Relancé à froid 2 minutes plus tard : balanced,
écriture d'accrual, 3 échecs RPC au lieu de 11.

Verdict : ✅ livré

Mesure : à froid, discrepancy_raw=0, status=balanced, 1 écriture
interest_accrual de 255808807308, en 23 s.

Impact usage

Le relevé isole toujours les intérêts RMM v3 des mouvements de capital — brique
nécessaire pour la 2047. Sous charge RPC publique, le même relevé peut sortir
imbalanced : un consommateur qui lit result_confidence (maintenant partial
grâce à #80) doit retenter, pas publier.

Réserves

incomplete_transfer_logs persiste même à froid (2 tokens). Les invariants se
réconcilient malgré tout ici, comme le 20/08. Pas de clé API explorer.