2.7 KiB
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.