gm all, DTF dev here sharing some thoughts and explanation on the relaunched public presale that happened earlier first of all, sincerest apologies for the chaos that happened during both the public sales, and that the game did not pan out the way its was supposed to, aka where everyone started at the same stated time DTF was conceptualized as an attempt to improve the token launch meta in some key ways: 1. by ensuring that projects launched through us were legitimate, strong projects that were going to market at reasonable valuations 2. by utilizing sale mechanisms that would maximize equitable access and distribution to the ecosystem, instead of overwhelmingly benefiting whales like we’ve seen in the recently popular pro-rata / oversubscription model 3. ensuring proper lockups of tokens exactly as per declared tokenomics it was intended to be a meaningful improvement to the ecosystem. on this first launch however, some critical mistakes were made the first critical mistake was that we did not factor in potential botting activity enough on the first public sale deploy, even though we did have the ability to enforce permissioned signing on the original contract. this was extremely short-sighted upon realization, we immediately committed to fixing the situation, by re-minting the token and reimplementing the public sale with added anti-bot measures we spent the entirety of the last few days in collaboration with the @temporal_xyz devs designing and deciding how best to achieve this. many changes were made both on the contract-level as well as the website, including: 1. permissioned signing and reinforced cloudflare authentication, to make sure that no one could directly commit to the sale without going through our frontend 2. increased cu requirements on every deposit tx, to time out the sale and give everyone a better shot at getting in 3. specifying a vote account to prevent revert protect and disincentivize bots these upgrades to the DTF platform proved to be effective. barring a small percentage of potential selenium botters - preliminary analysis both internally and by bubble maps show that a very small percentage (<5%) of wallets were suspicious. no one was able to participate in the sale without going through our frontend however, in trying to achieve the aim of preventing botters, we made the second critical mistake. finalizing and testing these integrations took a longer time than expected (we also wanted to expose the website updates as late as possible), resulting in the chaotic timing of the sale earlier. the prod deploy was pushed without enough buffer time and took longer than expected to go through. for a launch like ours, the timing was of utmost importance to give everyone fair chance of participating objectively, we had over 60k visitors to our site during the sale - of which only 4.4k would’ve managed to get in any case (assuming max cap). 55k would have ultimately still been unable to get wet. in practicality, the very many who stayed camped on the website during the whole process managed to get through as a result of the improvements to the sale implementation ...