[MIP-010] Optional deterministic cNFT assetID

[svc01-metaplex]

Submitter: vl-dev
Email: vladislav@matus.pro
Submitter wallet: 3uEPkEZsU2tQVTsoFmqrobT32RTrmSJ4zC7jtWAto77p
Submission transaction: QKtxYo55cyLNFSCVVM8wvcfnnj5Tb3bsqW1agvMjo4NCgEi2W4TJf6XnhjAGeTd7H8RWFmhesZphjET3v5a3LAw
Title: Optional deterministic cNFT assetID
Links:

The issue outline:
In the current cNFT minting solution there is no way to determine a cNFT Asset ID before the cNFT Mint transaction is processed on-chain. Here are a two examples when this is limiting or inconvenient:

• The AssetID is needed to construct a follow up on-chain call. This can be the case for example when using the Asset ID to deterministically construct a PDA tied to the underlying cNFT (e.g. with Access Protocol Transferable subscriptions). If there was a way to determine the Asset ID in advance these two calls could be merged into a single transaction or even into a single instruction utilising CPI calls.
• cNFT mint monitoring - To be able to store the Asset ID in a database for a later use (e.g. DAS API calls) a non-trivial asynchronous logic is required. Additional RPC call (or Other solution like Geyser plugin) and non-trivial transaction parsing is needed to retrieve the Asset ID.

Current implementation summary:
Currently the Asset ID is derived from the Merkle address and number of minted assets (num_minted) stored in the Tree Config PDA owned by the Bubblegum program. The num_minted is then used as the leaf index in a CPI call to compression program to set up a new leaf in the Merkle tree. Finally, the value of num_minted is increased by 1. This ensures that the mint instruction never fails if the tree is not full.

Proposed solution:
After thorough examination of the current Bubblegum code I've come up with a following plan of possible mitigation of the aforementioned issue:

• To keep the backwards compatibility this should be implemented as a separate instruction that would accept the Asset index as a parameter. This would be used for determining the leaf index instead of current num_minted value
• The instruction should either require the Asset index to be equal to num_minted for a backwards compatibility with existing trees, or only be available on dedicated trees that could be filled in non-deterministic order.
• Other than this change, the instruction logic would be exactly the same as the existing Mint instruction.

Happy to provide more details or discuss other possible solutions. Moreover, I am willing and able to implement this myself if required.

[danenbm]

Hello, and thank you for the submission! I have a few questions about the proposal:

1. Just to confirm, the new asset index would still be a u64, which can be any valid unused leaf index, and other than that the asset ID is the same PDA as before, right?

2. So then what makes this deterministic is you are choosing the leaf index before you mint. Assuming only one tree creator or tree delegate can mint, the limited access for who can mint means you could already keep track of the num_minted value or read it from the tree config and use that to determine the next asset ID. If minting can be done out of order, how does it improve the determinism?

3. Confirming that the idea would be to use spl_account_compression::replace_leaf rather than spl_account_compression::append_leaf. So the new mint would be planned to need a proof to be provided?

[vl-dev]

Hello @danenbm,

thank you for your response, let me answer your questions.

1. Yes, the new asset index and asset ID would still stay the same.
2. You are right here, if we keep the the ordering of the leaves and use num_minted to determine the next leaf, we can just assume in advance what the asset ID would be and use it optimistically to derive the address of other PDAs depending on it. However, the part with only one tree creator/delegate doesn't characterize our setup correctly as the NFT minting happens as a CPI call from another program that can be called by multiple users simultaneously. The out of order minting would enable us to keep track of the occupied and pending leaves off-chain and help users construct transactions in such way that they don't conflict with each other.
3. Yes, in case we decide to allow unordered minting to the tree, we would need to use spl_account_compression::replace_leaf and therefore would require a proof to be provided

The whole issue ultimately stems from the Solana design as we need to pass the address of the PDA we will be creating in the transaction and we cannot derive it dynamically in the on-chain.

[danenbm]

Thank you @vl-dev. This all makes sense to me and I like this proposal.

I agree on the idea of adding a new instruction, for compatibility and also because MintV1 and MintToCollectionV1 allow additional verified creators to be specified as remaining accounts.

As far as scoping goes, we also need to keep in mind is the new instruction will need to be indexed in DAS, which should be straightforward because on the asset side MintV1 and MintToCollectionV1 are (of course) already indexed, and on the change log/Merkle tree side, replace_leaf is already indexed as it's used for Transfer.

Also some SDKs in various places will likely need to be updated, as various things assume leaf_id == num_minted == nonce.

[vl-dev]

Amazing, thanks for all the provided info! I would love to help you with the implementation as much as possible as this really sounds like an interesting task. I've reached out in Telegram to smoothen out the details.

[MetaplexFoundation]

This proposal passed as MIP-10 in the Metaplex DAO. This will be a Metaplex implementation.

[MetaplexFoundation]

The Metaplex Foundation will work with the submitter vl-dev to implement MIP-10. Estimated completion date for development and security audit is February 2025.

[MetaplexFoundation]

Development for MIP-10 discovered unexpected changes to the lower level Merkle tree code in the Solana Program Library will be required. Accordingly, the timeline for completing development must be postpone until this blocker is resolved. The Metaplex Foundation will provide a further update by March 15, 2025.

[MetaplexFoundation]

Development for MIP-010 remains blocked due to the contingency in the Solana Program Library. The Metaplex Foundation intends to release new features for the Bubblegum program that may be able remove the blocker. Development for MIP-010 is paused until the new Bubblegum features are released and tested. The Metaplex Foundation expects development for MIP-010 to resume by end of May 2025 and will provide further updates when the timeline becomes more clear.

[MetaplexFoundation]

Development for MIP-010 remains blocked due to the contingency in the Solana Program Library. Implementing the changes outlined in MIP-010 is not possible at this time. Therefore, development for MIP-010 will be paused indefinitely.