0

I have a metaplex candy machine and collection that I set up several weeks back. Minting worked initially but is now failing.

The error reported is

custom program error: 0x3f

Which appears to be from the nested instruction to the metadata program. Which should be

set_and_verify_collection

  readonly code: number = 0x3f;
  readonly name: string = 'DataTypeMismatch';

It can be thrown from metdata deserialize.

https://github.com/metaplex-foundation/metaplex-program-library/blob/master/token-metadata/program/src/state/mod.rs

Which is called for the token metadata and collection metadata data.

I believe those are the only two places it would be thrown from in this method. AccountInfo is resolved for several accounts but it's only deserialized into a typed entity, with size and type considerations for those two entities.

Checking the metadata, on the collection, it's present and the length looks normal for metaplex metadata accounts at 679 bytes.

Now the metadata for the token being minted is not present because the tx failed. However, if, I attempt a transaction without the 'SetCollectionDuringMint' instruction added, the tx succeeds.

Interesting. The metadata account for the token has zero bytes allocated.

I don't recall this changing. In fact, if I go through my source history to older revisions, I've not been explicitly requesting to create the metadata account. I've simply been pre-allocating the account and calling mint nft on the candy machine.

Did the candy machine change to no longer automatically create the metadata account for the minted NFT?

Ahkilleux
  • 21
  • 4

1 Answers1

0

It occurred to me almost as soon as I finished typing up the question, what the likely cause was.

It came to my attention a few weeks back that this older v2 version of the candy machine, does not actually halt transaction execution on constraint violations, but rather, charges the client a fee , for executing the transaction incorrectly.

It's likely the 'bot tax' protocol is allowing the real error, which may be occurring earlier, to get suppressed.

v3 of the candy machhine has made this something you can disable but we are a bit coupled to v2 at the moment.

Anyhow, what I think has happened here is that the bot taxing version of the candy machine, allowed the nft to mint, but didn't actually finish setting it up. Then the next instruction, set collection during mint, was unable to complete.

The real failure is earlier in the transaction, somewhere during the mint, where we no longer meet the mint criteria, and the old version of the candy machine is just charging us and failing silently.

Unfortunately, the root cause is still not clear. One other change that would have occurred between now and then is that the collection is now 'live' having passed the go live date. I'll have to dig through the validation constraints and see if there are any bot tax related short circuits related to this golive date transition.

EDIT: UPDATE: Looks like there were some changes, specific to devnet's token metadata program and my machine was affected. I'll need some new devnet machines.

Ahkilleux
  • 21
  • 4