Public cNFT trees with fixed cost-per-mint

[nhanphan]

Submitter: ChewingGlass
Email: chewinglass123@gmail.com
Submitter wallet: wwm872RcvN7XwNZBjXLSHfAYrFUATKgkV9v3BewHj5M
Submission transaction: 2xd5QZRQZyxnYew3Hb5UM8vCL4q1LYeKrXH7xBxy2QmX79APCNtnYT1ZNWZNhPJ9mrSKQmANW28fEKrceSqcyQzk
Title: Public cNFT trees with fixed cost-per-mint
Links:

cNFTs are currently difficult to use because in order to mint a cNFT, first you must initialize and fund a tree. This requires effectively paying for all of the rent up-front.

Trees themselves are not special, they are not tied to a collection, and so it doesn't matter which tree gets used to mint an NFT. As such, we can improve cNFT UX by offering pre-existing trees within the bubblegum program that charge a fixed rent cost to mint. This cost should be the cost of the merkle_tree + tree authority structs on chain, divided by the capacity of the merkle tree. When one of these trees fills up, the fixed sol charged per mint is used to create a new public tree. There should be public keys of several depths/configurations. For Helium, for example, a depth 20 canopy 17 public tree would be useful.

[ChewingGlass]

Worth adding that it's difficult to build a wrapper program to do this due to the fact that there is a CPI depth limit of 5. Wrapper > Bubblegum > Account Compression > Log Wrapper is already 4. So this type of feature needs to be added to bubblegum itself.

[blockiosaurus]

Is there any reason a max-depth tree can't be used for maximum cost savings with the (depth - canopy) depth being iteratively scaled back? Just to reduce the number of config variables to 1.

[ChewingGlass]

Well, you can't do more than a 17 canopy. So if you want proof length of 3, the max you can do is 17x20. Otherwise yeah, erring towards the larger sizes makes sense.

Maybe you need

17x17, 17x18, 17x19, 17x20, 17x21, 17x22, 17x23, 17x24, 16x24, 15x24, 14x24.... etc

[danenbm]

Were you thinking an automated programmatic solution for creating the replacement trees? In this case seems like the funds amount for tree MxN would be specifically known/escrowed to fund new-replacement tree MxN. Otherwise, I don't know how we would enforce correct tree parameters for tree recreation. Wondering if this is what you had in mind, or if there were other suggestions involving administration of tree creation.

[FreeSolDev]

yo this sounds good this should 100% get pass thru,drastically reducing onboarding costs of gaming related projects

[blockiosaurus]

One of the concerns for this is the way tree authority works. The tree authority has permission to update (if not part of a collection) and mint new assets.

The latter is fine if we treat this as a public tree, but the former is a little concerning. It seems like either these trees must be either immutable or part of a collection. Interested in hearing thoughts on one option or the other (or both).

[ChewingGlass]

Has permission to update what? The whole asset? Shouldn't there be a separate update authority for that

[blockiosaurus]

No, the tree authority has always been the one with permission to update the contained assets. However if the asset is part of a collection then the collection auth is the only one allowed to update the asset.

[FreeSolDev]

so theoretically public trees can still be used in this manner then aslong as the assets are apart of a collection

[blockiosaurus]

Pretty much. I'm pretty sure the two constraints would be:

1. Require every NFT in an amortized tree is part of a collection so the collection auth can update it
2. Make a Bubbegum PDA the tree auth for amortized trees and don't allow updates. This would basically mean any asset not in a collection is immutable.

[FreeSolDev]

that would not be bad at all