moved from the discord to discuss here:

Dear geraldb，From the perspective of a newcomer, let me make a few suggestions.

1. On the one hand, there is no limit to the total number of mints within the range, and on the other hand, only mints that do not exceed max are useful.

2. The most important thing is that every late comer does not know the current number of mints. After all, very few people hope to obtain a "cursed" punk, which will greatly reduce their interest and thus reduce the entry of new players

3. The changes in the version have made many people uneasy and doubt whether there will be v3 or v4 in the future. After all, a project should not have many branches before it is successful, it should have a most orthodox main line. But the information I have collected so far is that no one knows which version is better, which makes many newcomers who have seen this project uneasy.

4. The official document does not have a perfect JSON and those specious JSON specifications, after all, most people are not dev. There are many errors in Unisat search, which can make many people doubt whether their JSON format is correct. Just like those people asking in the group.

If there is anything wrong, I hope to understand. My friend and I have been studying this ORC721 project from a completely new perspective for half an hour, and our feelings about it.

One issue I see w/ the protocol as it is, is that there is no way for a deployer to control who mints it.

That is nice for free-for-all collections and the free market ethos of crypto but it does limit the usecases orc-721 can support.

Example: Lets say I want to do an orc-721 collection. I spend a lot of time creating the art and I want everyone to have a fair shot at minting.

I first inscribe the sprite file
Then the deploy json with a mint max of 1000.

a scanner spots the deploy json in the mempool and decides to claim 90% of the mint.

arguably this is a problem that solves itself as it can start to be a waste of money but it may mean hyped projects could not use this protocol to launch.

Thank you for your orc-721! Here are some ideas to so that it becomes the standard 721 protocol:

• use more than one image incription as source, similar to crc-721
• animated GIF (positioning of other images or texts)
• don't forget the creators, so add optional parameters like "Initial Owner Address", "Price", "Payment Address", similar to brc-721
• avoid robots and scripts to minted out collections, add "Max Per Address" and again "Initial Owner Address", "Price", "Payment Address", similar to brc-721

Other 721 protocols gains more traction, see https://dune.com/ordinalstats/bitcoin-tokens . Reason could be the above points because brc721 and crc721 are more attractive for creators. And more creators means more possibilities to mint, and that means more minters...

Ser, this protocol is quite interesting, One question: mint inscriptions did not point to the deploy inscription, so whether the production of the collection will be difficult?

PS: Could you provide inscription data for all 10,000 punks

this is an idea from @cbspears and I am just listing it here for the record.

instead of a 'mint' json, inscribe a compact html/javascript file that references the sprite inscription and dynamically pulls in the sprite and renders it inline.

pro: no marketplace support needed
con: external dependency on some hostname/url to get the sprite file from.

We care about the rest of the diypunks list.
Some guys mint diypunks after 721 , because he found some broken inscriptions.
We want to know range of diypunks collection
I think its fcfs for diypunks holder.

Hey Gerald,
Busy couple of days! Are you able to offer some points on why you feel ORC is better than the existing Gen BRC protocol that is also gaining steam? I want to be more prepared to answer that question. My understanding is that ORC is more flexible, with multiple types of data to use as source and build the images? Can you offer additional insights there?
Thank you sir!