46 lines
2.7 KiB
Markdown
46 lines
2.7 KiB
Markdown
<!-- file: kb_materializer_metadata/README.md -->
|
||
<!-- version: 2 -->
|
||
|
||
# kb_materializer_metadata
|
||
|
||
Ce crate matérialise les états et observations de metadata dans une projection métier canonique.
|
||
|
||
## Frontière
|
||
|
||
Le matérialisateur ne lit ni RPC, ni wallet, ni Tauri. Il reçoit des snapshots déjà décodés, bornés et accompagnés de leur provenance.
|
||
|
||
Une même réalité métier possède une seule projection canonique. Lorsqu’un snapshot de compte owned est disponible, il constitue la source autoritative de l’état final. Les instructions restent des observations de mutation et ne produisent pas une seconde copie concurrente du même état.
|
||
|
||
## Metaplex Token Metadata
|
||
|
||
`materialize_metaplex_metadata_snapshot` matérialise un `CanonicalMetadataAccountSnapshot` de type `MetadataV1` lorsque sa provenance est commitée.
|
||
|
||
La projection conserve notamment :
|
||
|
||
- l’identité stable programme/compte ;
|
||
- mint et update authority ;
|
||
- name, symbol et URI ;
|
||
- royalties en basis points ;
|
||
- primary sale et mutabilité ;
|
||
- creators, collection, uses, token standard et programmable config depuis le payload borné ;
|
||
- layout, lifecycle et version canonique ;
|
||
- source, slot, write version, signature et indices d’instruction lorsqu’ils sont disponibles.
|
||
|
||
La fonction ne télécharge jamais l’URI externe. Sa clé de sortie stable est basée sur l’adresse du compte Metadata, afin qu’un replay ou backfill mette à jour la même identité logique au lieu de créer un doublon par instruction.
|
||
|
||
Une provenance non commitée ou un autre layout est refusé.
|
||
|
||
## Token-2022 incorporé
|
||
|
||
`materialize_token_2022_metadata_snapshot` projette uniquement les extensions `TokenMetadata`, `TokenGroup` et `TokenGroupMember` d’un état Mint déjà parsé et borné. La provenance reste `token_2022_embedded_tlv`; aucun URI externe n’est téléchargé et aucune donnée Metaplex n’est fusionnée implicitement.
|
||
|
||
Les conflits éventuels entre Metaplex, Token-2022 embedded metadata et futures sources externes doivent être résolus par une politique de provenance explicite, jamais par écrasement silencieux.
|
||
|
||
## Metaplex Token Metadata — `0.4.7-pre.035`
|
||
|
||
Les comptes Edition, Master Edition, Edition Marker, Token Record, Delegate Record, Authority Record, Token Owned Escrow et Reservation List sont matérialisés depuis leurs snapshots owned commités.
|
||
|
||
Chaque compte conserve une clé stable, son lifecycle actif/expérimental/historique, sa provenance et un propriétaire unique du fait. Les comptes historiques restent matérialisables pendant les backfills et replays, mais leur politique d’exécution demeure `never_historical`.
|
||
|
||
Les instructions décodées décrivent les mutations ; elles ne produisent pas une seconde copie concurrente de l’état final du compte.
|