Hello, turtles! I hope you guys are excited for launch! 🚀
As you may know, we’ve put in a lot of thought and effort to build our own self-launch protocol, to better support our custom standard and hopefully smoothly transition to post-sale goals (secondary markets, rarities, accessory interactions). More info about this can be found here https://medium.com/@icturtlesnft/the-icturtles-self-launch-341a329822bb.
This article will be focused on more technical aspects and hopefully will give people interested in minting an idea of the user experience.
The single-threaded nature of canisters
Canister function calls are single-threaded, which basically means (simplification) that when multiple users call a canister function at the same time, each request is only processed one at a time, sequentially.
How does that tie into the ICTurtles self-launch?
During the public sale, there will be one main canister (and a series of functions) responsible for all the minting logic. It is likely that many people will be sending requests to the canister simultaneously. Therefore, responses may take longer than expected to return to the client.
A typical function call on the IC (due to validation processes) will take a couple/few seconds each. This means even if 100 mint requests come in simultaneously, they will be added to a message queue and processed one by one.
But platforms like Entrepot are able to sell out in 3 minutes, how does that work?
We are not too sure how their launchpad works exactly, but as far as we know, it is impossible for 10000 NFTs to be minted on-chain in minutes with one main canister. It is possible they use the assistance from a centralized server to distribute NFT ids, then actually mint them on-chain later, which will go through the usual validation process.
Why are ICTurtles doing an on-chain launch?
Even though our current implementation of an on-chain self-launch may be slower, as each request must be processed sequentially, we believe there are some benefits.
- The process is all on-chain, so everything interacts with canister functions, which are public.
- We can detect failed transactions when they happen and adjust accordingly. If the NFT reserving part is done too quickly, you won’t be able to detect failed transactions until actually minting on-chain. If we do everything on-chain, if a transaction fails for a particular NFT, we can put the NFT back in the pool. Hopefully, this minimizes awkward situations where we have many failed transactions and unsold NFTs.
- There isn’t that much downtime between stages. By doing everything on-chain, we can fluidly move between the sale stage and listing stage. The sale mints the NFTs as it progresses, so once the sale ends, it is easy to enable listings on secondary marketplaces and allow users to immediately interact and see their NFTs. This is also true for things like rarities, which can only be calculated accurately after all NFTs have been sold.
What are some potential downsides of this approach?
There are some things that may be undesirable with doing everything on-chain. The main thing is the latency, as discussed above. Each mint request can take several seconds to process. Compound this across hundreds of simultaneous requests, and it is possible that getting through all the mint requests can take a while. This is more of a “cosmetic” issue, as ultimately, all the mints must take place on-chain, where the users are assigned ownership to their NFTs. Regardless of the approach, it will take some time for these relationships between the owner and NFT to be established on-chain in the end. However, this could be a big deal for some people, who want to see “quick sellouts”.
How are ICTurtles mitigating the downside?
We will try to minimize the number of failed transactions overall. This is one of the benefits of the on-chain approach. We can immediately identify which transactions have failed as they come in, which allows us to put the reserved NFTs back into the pool. For example, if a user reserves NFTs, but then declines the wallet transaction, we will unreserve those NFTs immediately. If a user has reserved NFTs for a certain period of time and still has not transferred the proper funds, those NFTs will be unreserved. Hopefully, this will minimize the potential of having “unsold NFTs” at the end.
We will try to prevent users from submitting many mint requests to the canister simultaneously. This way, a user is only dealing with one mint request at a time, lowering the load on the canister.
Regarding the speed of the sale, there is not much we can do to lower the time taken beyond the lower bound allowed by the IC as a whole. This is just the price we pay for doing everything on-chain with our one main minting canister.
I hope you guys understand our approach and reasoning behind this! Feel free to contact us with any feedback or questions!
We are one of the only NFT projects to do this type of self-launch, and we think this would create the best experience for our supporters! Go turtles 🐢!
