Katie Rance

WEN Post Launch Analysis WEN was a fantastic test for our overall LFG concept, stress test across the entire network, a real world test of our bot mitigation measures and our operational competence. We did not too bad on some fronts, learned a lot on others and had one big fuck up. 
 Recapping Key LFG Concepts Basically the main LFG concepts are: - open market environment - sufficient sell liquidity at every step of the way - avoiding isolated pools or fomo driven fake pumps - design of custom liquidity curves - mass distribution of tokens to intended audiences All of whom have the very high potential of hurting the most enthusiastic participants while benefitting other participants, leaving projects off to an bad start. In addition, we believe well done airdrops to be extraordinarily good mechanisms for targeting audience and rewarding users, but it adds an extremely complicated dynamic to the usual concept of token launches. Tt is very important to understand that the heavy sell pressure from airdrops is IMPOSSIBLE to predict, the only way to go is to allow the buy/sell dynamics to happen at the exact same time. But essentially if a token has enough buy pressure to push through but the early sell only pool liquidity and early dumpers, it looks likely that it will be able to sustain the price as it goes along, vs the extremely dramatic fomo driven Mount Everest price action we often see in launchpads. Unlike isolated price pools, this is open market, so it is likely an organic reflection of true buy/sell interest. How did WEN do? In this regard, we believed WEN did pretty well. While many enthusiasts were not able to get the tokens they wanted, but those that did had sufficient time to think about it, got it at a price they wanted and no one got moon trapped. Some botters gained the cheapest part of the price curve and exited early on, the amount they had relative to the total available liquidity was not big enough to affect price action significantly. It was also able to help WEN scale the number of holders via a voluntary mechanism - aka if you wanted to be part of the community you can hold it, otherwise you could sell it immediately thanks to the abundance of liquidity. The other key concept we were testing was the price curve design tool developed to help teams go from a super intuitive price curve into a full liquidity distribution loading for DLMM and way for projects to see how much usdc will be in the pool at various price points. While we worked the math insanely hard, it was good to see it playing out really well in actual test, increasing our confidence that it worked well. See the tool: lfg.jup.ag/design Lastly, the launch pool served its purpose of being a bootstrap and backstop liquidity pool, allowing buyers to provide liquidity early on (yeh, these are bots), while in the case of a massive withdrawal over next few days, the pool will act as a backstop. It looks like the token is doing fine, so we will be withdrawing the All in all, I believe the launch, despite major issues with allow regular users to get access to the cheaper tokens, resulted in a project with very wide holders (> 300K holders), abundance of buy/sell liquidity across the whole process and no artificially generated fomo buy created an good launch IMO. Let us go into detail on some issues below, some of which I am pretty unhappy with, and no it is not bots. Scaling We designed this launch to be as intensive a test as possible, with an even bigger number of recipients than jup. also it is focused on new users compared to jup (older users), so there is a reasonable chance that it will have more recipients than the actual launch. Solana network performed well, handling network was business as usual, with above average fees for all txns, with the biggest effect is slow confirmations, failed txns. But overall, the liveness was very good, increasing our confidence that Solana has improved substantially from the past. x.com/0xmert_/status… Across the ecosystem, there were a number of teams experiencing errors due to their systems being stressed out but we believe this to be a fantastic chance for all of us to learn and collaborate. x.com/kevin0kim/stat… (x.com/kevin0kim/stat…) Special thanks to @vidor_solflare for being hyper awesome and pointing on a few key issues, and @mert and @brianlong and @buffalu__ for providing a lot of scaling analysis and clarity on the bot issues (below) Bot Mitigation Features Basically, the 3 key things we had to help mitigate the sniping bot advantage worked, but they did not worked as well as we wanted them to. 1. Throttling max tokens per swap We had a mechanism for allowing only a maximum number of swap in the starting new minutes. However, the number was too high initially, in addition, it was in effect for too short, (only 2 minutes). The main constraint here for making this smaller and longer is basically the user experience - while bots can pack swaps and bundle, the user essentially can only have one swap. 2. Steep price curve Working with the Ovols team, we designed the following price curve. We believed that 1M was a reasonable starting point for price discovery given that that most coins were WAY below that and we did not want to overassume. Also, it was a conclusion between us and the ovols team that given this was still experimental, we should aim to have a smaller amount in the poo. We ended up with this configuration, which you can see below: See the exact configuration here: lfg-design.jup.ag/?k=0.6&i=0.000… With a low price and relatively steep curve, you can see that 5% of the pool starting from 1M FDMC to 5M FDMC was available, while the rest was available for 10M FDMC - 30M FMDC. So one could argue that the first 5-10% of the pool was “free money”, while the rest definitely detailed a good amount of risk. Snipers and spammers who essentially flooded the network was able to secure much of the first amount of liquidity. There are 2 reasons why these could happen today, mostly because the Solana network has 2 issues right now: 1. spammers have low fees
 github.com/solana-foundat… 2. higher fees does no guarantee inclusion
 helius.dev/blog/solana-fe… Given these constraints, we will be looking at very drastic updates for upcoming launches, though each comes wth pretty interesting tradeoffs, and there's probably not a one size fits all solution. First and foremost, you canont really have genuine open market price discovery with sufficient liquidity throughout the entire curve. Secondly, the team runs the real risk of sell demand from airdrops overwhelming stable liquidity built up. The other possibility is to throttle even more aggressively, but you get into a cat and mouse game with spam, jito bundles, etc. In addition, the more aggressive the throttling, the more it becomes an isolated pool, breaking the whole point of it being a open market play. In summary, both approaches will likely be needed to solve this problem. There is no right answer, but thankfully, we will have many chances to figure this out. 3. Having users be able to execute bots as well Via DCA/LO and other bots available, (and high slippage swaps) retail users were able to secure a fair amount of liquidity available, particularly in the 10-30M FDV. That said, most users did not get the orders they wanted for several reasons, namely orders greatly exceeded the amount of available liquidity, and blockspace was limited and due to suboptimal UI many users set limit orders to be too low. In particular, our DCA / LO keepers are not optimised for this use case, but rather with a lot important protections for users. We will be optimising a number of things in order to make it work better for this use case. Despite this, I stand by my statement that we should not hate on bots and bot operators. We need to both mitigate them harder while also empowering users with more tools. Transacting On Site Transactions on site was pretty soon, except for some wallets not functioning well and for users not being able to execute transactions due to blockspace limitations. On our end, we appeared to have an 2 UI error on LOs. - We had a frontend error causing active LOs not to load - Canceling LOs not using priority fees Those will be fixed in the coming launch. For general UX, the most glaring mistake was encouraging users to set an initial LO price that was too low, causing most users not to be able to secure any at all. Massive Operational Fail The biggest operational fail here is that after the loading of the airdrop merkle trees, there was 100 tokens left in an account used by the engineer loading the airdrop. He had the idea of loading it into a newly created DLMM pool that had been created for us by the Meteora team as a post launch market making vault to rebalance the active price point, However that 100 tokens, once deposited, were sniped and posted into a raydium pool for fun and profit. That created a massive panic internally, but we decided to go ahead given the very very small number of tokens affected. There was no ethical problem here, just incredible dumbness. So there’s no firing or anything like that, but he and some else got a fuck ton of MEOWWWWSSSSSS and cat smacks for one entire hour straight and they will be eating a lot of cat shit for the rest of the year. We already have very tight operational things in place, including creating the special “operator” role in DLMM where the hot operator can load the launch pool, but all LP withdraws into a cold pool. However, we missed this scenario of having a small amount of tokens being in hot accounts. Moving forward, the exact amount of tokens will be calculated and released for loading, not 1 token will leave a multisig with no I take responsibility for this for not being through enough, and I am incredibly thankful that we learnt this lesson in a lower stakes beta context, for the understanding of the ovols team, and for the low number of tokens involved. Summary This fulfilled our goals of being the first beta launch for LFG. It validated certain key conceptual ideas, but exposing serious holes across the ecosystem, our bot mitigation measure, and severe operational gaps. We will secure the gaps, fix the bugs and work with the ecosystem to make sure all the gaps are fixed. Lastly, I am very sorry that the DCA / LOs are not filled appropriately for most users - we will be working really hard to optimise it for this for the JUP launch, and we will have updates WEN was a seriously, seriously fantastic lesson for us, and I am very glad i did it. Next test: JUP!