We want to take a moment to express our sincere apologies for the less-than-ideal user experience many of you encountered during the recent Orcfax Fact Token Launch.

We understand that the launch experience fell short of your expectations, and we take full responsibility for any inconvenience, frustration, or disappointment this may have caused. We deeply value your support and commitment to our project, and we are truly sorry for any negative experiences you may have had.

We have reviewed the issues that arose during the launch and their potential root causes and have identified areas to make improvements to prevent similar situations from occurring in the coming launches. Please read the summary report below.

Summary Report

The Orcrfax token launch was scheduled to start at Sep 8, 08:00 UTC. Around 07:46 UTC we received initial reports from both our development team and community moderators, that many participants are unable to connect their wallets and started immediately to investigate the root cause of the problem.

Per our initial analysis, either more participants were trying to connect at once that the infrastructure scaling setup was set to handle, or a form of attack contributed. This caused a short-time overload of the UI. So far what is known is that the server infrastructure upscaling was set with tight limits to prevent infrastructure attacks, but this also could have resulted in many participants being unable to enter the launchpad page and connect their wallets. These limits were introduced based on past experience with attacks and high-load instances on the DEX. We are still unsure of the exact cause of the overload.

To fix the problem, the dev team started to immediately increase the Launchpad’s system’s capacity just before the start of the launch. The first increase was at 7:54 UTC, followed by another one at 8:10 UTC, and the final one at 8:12 UTC. It took minimal time for each increase to become effective. After the last capacity increase, the vast majority of participants were able to connect their wallets nearly immediately. At the time of writing, 141 participants are fully eligible, and one participant is partially eligible for tokens. The last eligible participation in case of no withdrawal by an eligible participant is at 8:26:54 UTC.

Please keep in mind that withdrawals are still possible, and if they happen the next contributions in line will become eligible. Maximum eligible commitment is 500,000 ADA, minimum is 380 ADA, average is 31,629 ADA and median is 9,150 ADA. The current cut-off, not counting with future possible withdrawals, occurred at slot 102595323, and no transaction that was accepted by the blockchain after that is eligible.

These events might have provided an unintended advantage to participants with advanced technical skills. These individuals had in theory in the first minutes the opportunity to secure positions more swiftly amid the congestion, leveraging their potential blockchain know-how. Recognizing this, we are committed to improving the responsiveness of our services to ensure that all participants have a fair and equal opportunity during future launches, while improving our defenses against potential attacks. Our objective is to enhance system efficiency and security so that UI participants are not left at a disadvantage in such critical moments.

Why did some transactions have the submission timestamp within 1 minute before the Launch start time?

Due to the inherent technical constraints of wallets, which are unable to sign transactions with validity start time in the future or even within the short timeframe in the past (wallets require to have the most recent block from the blockchain to be after transaction validity start), the Smart Contracts were configured to accept the transactions initiated after 7:59:00 UTC (1 minute before the actual launch start time displayed in the UI), to ensure a smooth participant experience. This approach was necessary, as otherwise transactions created in the UI during the first minute of Launch would very likely be declined, causing poor UX. We opted for this strategy to favor the participant experience, allowing for the validation of all transactions initiated from 7:59 UTC onwards, including those signed at the 8:00 UTC mark.

Note that it is not possible to roll back the local time on your computer to get a valid contribution early. Smart contracts use blockchain time and no transaction that is valid before the Launch starts is accepted.

A glitch in the UI with color indicators for contributions

Some participants encountered a glitch in the UI, where the color indicators for commitments were not displaying correctly; commitments before the cutoff appeared yellow for some participants, while those after the cut-off showed green.

Lessons Learned

This experience has been a significant inspiration for further improvements. Looking ahead, the solution is already updated how it handles big increases in participant numbers to avoid system overloads, while still keeping everything secure against known attack vectors. The commitment stands on learning from this to make sure the Launchpad can handle big first-minute launches in a smooth and flawless manner.

The design of the Launchpad supports using NFTs to limit the max contribution per wallet for minimizing buy pressures for highly anticipated launches. It remains our recommendation to use the NFTs to segregate the launch into tiers, but it is always up to the project to decide on the launch strategy, tiers, and conditions.