# Case Study: WZRD
To launch a collection as large as WZRD, there are three main approaches:
## **Approach 1: Different Files**
Traditionally, minters would need to inscribe different files, leading to potential issues with file size and optimization, resulting in high inscription fees. This method does not support bulk mints and it leads to potential frontrunning, providing a poor user experience and causing minters to lose money. Thus we may have a lower success rate for the collection's complete minting.
## **Approach 2: Same Files, Full Inscription-Index Mapping**
This method, similar to the one used by [Commoners](https://commoners.com/), involves minters inscribing the same file and allows for delegate inscriptions, optimizing the inscription fee. It supports bulk inscriptions, improving the user experience by avoiding frontrunning. However, the creators face high costs post-mint, as they must inscribe a complete list of minted inscription IDs (sorted) and a mapping between these IDs and unique trait combinations (metadata). For smaller collections, this might be manageable, but for large collections, the inscription costs become prohibitively high.
For example, for the Commoners' **10,000 supply** collection:
1. The list of inscription IDs required inscribing a total of **745kb**.
2. The unique trait combinations required inscribing a total of **190kb**.
This amounts to a significant volume of data and associated costs. For a collection like WZRD, with its **111,111 supply**, the data volume would scale up by approximately **11.111 times**, leading to a total inscription size of around **10MB**. Given the constraints of Bitcoin's transaction size, this would require the data to be fragmented and inscribed across multiple transactions, complicating the process further.
## **Approach 3: BRC69+ - Same File, Perfect Hash Mapping**
BRC69+ combines the advantages of using the same file for inscriptions with a Perfect Hash Map to optimize costs for creators while maintaining an excellent user experience for minters. For a collection the size of WZRD, the inscription mapping would utilize:
1. A Perfect Hash Function mapping (*Hashtable.json*), expected to be around **100kb for all 111,111 inscriptions**.
For a collection like Commoners, the inscription mapping is anticipated to be around 9-10kb for all 10,000 inscriptions.
When comparing approaches, **BRC69+ is found to be 100 times more efficient, saving approximately 900kb for Commoners and 9,900 kb for WZRD. Given a rate of 30 sats/vB and a Bitcoin price of $47,600, this translates to savings of about 0.069BTC ($1,250) for Commoners and 0.75BTC($35,000) for WZRD.**
## **Summary Table**
| | Approach 1 | Approach 2 | BRC69+ |
| ------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Delegates | | | |
| Bulk mints | | | |
| Anti-Frontrun | | | |
| Creator Cost Efficient **100x Times** | | | |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://luminex.gitbook.io/luminex/brc69+/case-study-wzrd.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.