# Batch Minting Compressed NFTs

One key issue for compressed NFTs is that data availability for suitably large drops can be problematic. One poignant example is that a million+ sized drop (often exhibited by the DRiP team) takes roughly (1mm NFTs / 5,000 mints per min / 60) ~= 3 hours per million.

However, one key requirement for data availability of compressed NFTs necessitates the use of the Solana ledger in this way. Below i propose an improvement to a state compression tree that allows large amounts of data to be made available within the space of a single transaction, while still preserving the eventual data availability of the tree.

Otherwise known as "batch minting", state compression trees can be initialized with a precomputed Merkle root. The key issue for broad usage of that tree, however, is the "leaves" that represent NFTs on Solana. How can RPCs / indexers and subsequently wallets know enough information about that tree to take advantage of a precomputed root? While the state compression program will respect any proofs used to make modifications to the tree, we need to think critically about the data availability.

One option would be to add additional instructions to the state compression program to allow an InitializeTree instruction with a few additional fields:

- `uri`: points to an offchain database dump with all relevant information related to the leaves in the tree
- `activation slot`: the first slot that is the tree will allow updates

`uri`: preferably refers to an Arweave/IPFS-hosted database dump of the precomputed state of the tree. This is used to seed the databases of RPCs / indexers in preparation for calculating and serving proofs for this tree.

`activation slot`: since it does take some time for systems to handle ingestion of millions of rows of information, this slot signals a "warmup" period where information is accessible but the current state of the tree will remain stable.

## Eventual Data Availability
Despite the availability of data in some generally accessible space, it is still critical for data to eventually be available on the Solana ledger. The precomputed state root allows a large drop to happen in the space of a single transaction, allowing products + markets to work more efficiently, while providing an opportunity to reconcile the data availability after launch.

At any point after the `activation slot`, any updates to the tree make data available in the ledger, creating something that might be referred to as a "shadow tree" (h/t Noah Prince). An additional instruction could also be exposed to allow a permissionless crank to make that data available as well, and a `rewards` account could be made available to crankers whenever the tree has been made completely available.

## Incentives

There are two interesting opportunities to incentivize both RPCs / indexers as well as ensure eventual data availability.

"Proof of indexing" could be used with a two-sided marketplace. After a successful ingestion of the data dump, RPCs send a transaction which includes a generally accessible URL endpoint that is used to serve "challenges" for data. Between the initialization point and the `activation slot`, a set of rewards is available for challengers and RPCs who can successfully serve proofs for pseudo-randomly selected leaves in the tree. Challengers submit transactions that execute a successful verification of a piece of data in that tree.

"Eventual data availability" could also be a separate reward category for crankers who take proof of indexing information and make that data available in the ledger

The rewards are funded by the tree initializer. Since this dramatically improves the product experience of compressed NFTs relatively to a gradual rollout of NFTs, there are economic incentives to be shared across multiple parties.

## Open Questions
- The use of a MintToCollection instruction updates collection-related information incrementally over time. Precomputation of state would require some other strategy for associating collection-related information, but perhaps this can be addressed in "eventual data availability"
- State compression has been under-specified in the requirement for "updates" to share all the relevant data for that leaf. This would require updates to share all data, rather than just a diff.

## Conclusion
While one might question the validity of data presented in this way, remember that state compression trees store Merkle roots in onchain accounts. Even if zero RPCs end up indexing the relevant data, one could calculate that information for themselves and use those proofs to do everything they might want to do with an NFT like list it on a marketplace, or send it someone else.