<!-- file: docs/V0_4_6_VALIDATION.md -->
<!-- version: 1 -->

# Validation finale `0.4.6`

## Périmètre

Le jalon couvre Token-2022 et le registre ElGamal comme programmes distincts, ainsi que la régression des décodeurs Solana Core/SPL livrés auparavant. Il ne transforme pas Anchor, Metaplex ou les futurs DEX en surfaces implicitement couvertes.

## Résultats de tests

| Suite                              | Résultat |
|------------------------------------|---------:|
| `kb_store_core`                    |    41/41 |
| `kb_store_pg` avec PostgreSQL réel |    46/46 |
| `kb_pipeline`                      |  124/124 |
| `kb_app_demo`                      |  118/118 |
| `cargo clippy --all-targets`       |   propre |

Les contrôles SQL sur `kb_sol_decode_events` et `kb_sol_mat_events` ne révèlent aucun doublon d’identité.

## Token-2022 et ElGamal Registry

- 55 instructions Token-2022 Mainnet ont été décodées sans échec persistant.
- Huit opérations publiques Token-2022 ont été confirmées sur Devnet : `MintToChecked`, `TransferChecked`, `ApproveChecked`, `Revoke`, `BurnChecked`, `FreezeAccount`, `ThawAccount` et `CloseAccount`.
- Chaque parcours Devnet a été simulé, confirmé, hydraté, extrait, décodé, matérialisé puis rejoué idempotemment.
- ElGamal Registry est validé synthétiquement/offline pour le wire, le PDA, l’état, les lectures RPC, les préflights et les preuves.
- La validation publique ElGamal Registry reste indisponible sur Devnet/Mainnet au 20 juillet 2026 ; aucune preuve réseau n’est revendiquée.

## Loader immuable et Loader v4

Le parser `Write` du loader immuable lit désormais la longueur vectorielle en `u32` et les données à l’offset 12. Le replay Mainnet a supprimé 68 diagnostics `loader_vector_length_mismatch`.

Les rejets persistants restants sont tous issus de transactions Solana échouées :

| Diagnostic                       | Nombre |
|----------------------------------|-------:|
| `immutable_loader_tag_truncated` |     31 |
| `loader_v4_tag_truncated`        |     44 |
| `loader_accounts_invalid`        |      1 |

Quatre variantes Loader v4 inconnues sont persistées comme traitement réussi avec résultat métier `Unsupported`. Elles ne sont pas assimilées à des décodages complets.

## Replay des signatures incomplètes

Le mode `incomplete_signatures` sélectionne les signatures contenant au moins une instruction `pending`, `failed`, `replay_requested` ou `unsupported`. La limite est appliquée au nombre de signatures avant expansion vers les instructions compatibles. Ce mode ne nécessite pas de force replay global.

Deux campagnes PostgreSQL réelles successives ont produit exactement :

```text
selected=81
started=81
completed=81
unmatched=0
notStarted=0
failedInputs=76
decoded=1
unsupported=4
failed=76
```

L’instruction décodée appartient à une signature incomplète contenant également une instruction valide. La répétition identique du second passage confirme la sélection stable ; les événements et matérialisations restent idempotents.

## Conclusion

Tous les décodeurs livrés jusqu’à `0.4.6` respectent leur contrat sur les tests synthétiques, les scénarios stateful et les données réseau observées. Les payloads malformés sont rejetés fail-closed et les variantes inconnues sont classées explicitement `Unsupported`. Cette conclusion ne prétend pas que chaque variante rare possible a été observée sur un cluster public.