Upstream Token Extensions From Helius

[kespinola]

Changes

• Upstream token extensions from the helius fork.
• Update program_transform after dropping plerkle as dependency of program_transforms crate.
• Update blockbuster to 2.1.0 which has parsers token extensions and mpl core.

[danenbm]

Does there need to be handling for burned tokens?

[kespinola]

There should but doesn't look to be handled. Getting an integration test in to confirm. This is a issue with token-metadata as well.

[danenbm]

Token Metadata has this handling if the metadata account is empty: https://github.com/metaplex-foundation/digital-asset-rpc-infrastructure/blob/main/program_transformers/src/token_metadata/mod.rs#L24-L27

But then I think how DAS effectively leaves out burned accounts is because the supply is zero, like here: https://github.com/metaplex-foundation/digital-asset-rpc-infrastructure/blob/main/digital_asset_types/src/dao/scopes/asset.rs#L67

So then supply is probably being set by handle_token2022_mint_account so maybe it is already not going to return them, but they would never be marked as burnt?

[kespinola]

@danenbm

Token Metadata has this handling if the metadata account is empty: https://github.com/metaplex-foundation/digital-asset-rpc-infrastructure/blob/main/program_transformers/src/token_metadata/mod.rs#L24-L27

Is the account owner not set to the system program so would this account update ever come through? Looking through this EmptyAccount creation though.

But then I think how DAS effectively leaves out burned accounts is because the supply is zero, like here: https://github.com/metaplex-foundation/digital-asset-rpc-infrastructure/blob/main/digital_asset_types/src/dao/scopes/asset.rs#L67

This is based on token_account same issue occurs if token account is closed and ownership transferred system program.

[kespinola]

I've looked into EmptyAccount which is what triggers flagging an asset as burned.

It is set within the handle_account of blockbuster when the data slice for the account is empty.

https://github.com/metaplex-foundation/blockbuster/blob/9b07c07dcdbbab468c0943c5b4d83916b99912c4/blockbuster/src/programs/token_metadata/mod.rs#L73-L78

This occurs in burn_nonfungible within the token-metadata program.

https://github.com/metaplex-foundation/mpl-token-metadata/blob/main/programs/token-metadata/program/src/utils/mod.rs#L243-L51

The token metadata account is re-assigned to the system program so does geyser send a change event under the owner of token-metadata or system program? If its the later DAS will never register the change since its account selector does not include system program.

The token extensions blockbuster parser does include the same EmptyAccount but again depends on the ownership assignment.

[kespinola]

On a local test validator stack when a traditional NFT is created and then the burn instruction of token-metadata is invoked. The following occurs:

1. The mint is left open but supply dropped to zero. This is correctly reflected in DAS.
2. The token account is closed and reassigned to the system program but DAS is not notified.
3. token metadata account is left open with 1 byte. DAS receives the update event but throws

{"timestamp":"2024-04-09T13:15:37.272578Z","level":"WARN","fields":{"message":"Error parsing account 5Yga8VnpA1GXnYohtH7w3NMKVczA7ZXUUA16T5UJEG16: \"Uninitialized account type\"","log.target":"nft_ingester::metrics","log.module_path":"nft_ingester::metrics","log.file":"nft_ingester/src/metrics.rs","log.line":94},"target":"nft_ingester::metrics"}

The asset is not marked as burnt because it the update event fails to parse. The supply is set to 0 on the asset because of the mint account so this scope does apply to filter out the zombie assets but they should be returned with status of burnt or if filtered out should be on burnt for list fetches unless burnt true a query param on getAsset should always return but correctly marked as burnt and supply 0.

https://github.com/metaplex-foundation/digital-asset-rpc-infrastructure/blob/main/digital_asset_types/src/dao/scopes/asset.rs#L67

[NicolasPennie]

This is because account closures go through the system program. It's annoying. We'll upstream this fix.

[kespinola]

This check does not trigger when the asset is burnt. The supply on the mint is 0 so it is no longer recognized as a token_nft though it is.

In this state the token supply is set to 0 but the supply on the asset is still 1.

[kespinola]

see #214