# A New Chapter of My Life > From CTO of EVAA on TON to a solo founder on Solana: why I started over, and everything that happened to Coffer in its first eight months, fails and small wins included. - Author: Vladislav Bliznuk, Founder - Published: 2026-08-16 - Updated: 2026-10-21 - Canonical: https://coffer.so/blog/a-new-chapter-of-my-life ## 1. Preface: my path into building DeFi December 2021 - I find out about TON. February 2022 - I'm building an NFT collection on TON, [toncells.org](https://toncells.org). In parallel I'm working a regular job in Prague; together with a colleague from work I go to a [@solana](https://x.com/solana) hackathon [@hackerhouses](https://x.com/hackerhouses). There I hack away and launch a bridge between Solana and TON. My team and I call it **Tonana**. Tonana didn't live long, but through it I fully immersed myself in the world of web3 and, most importantly, fell in love with Solana hackathons (in ’22-’23 I was in Prague, Barcelona, and Paris at Solana hacker houses - at all of them we were building Tonana and presenting it). In the summer of 2022, at one of the Paris Solana afterparties, I met Vova [@vlzhr](https://x.com/vlzhr) and simply exchanged contacts. In those same days, at another event, I met Alex [@defi_defiler](https://x.com/defi_defiler). A few months later, in early fall 2022, I reached out to him asking whether we could work together, and he invited me to join the [@puzzle_network](https://x.com/puzzle_network) team as a fullstack dev to help with the development of Puzzle Lend. What a coincidence! Vova was the founder of Puzzle and would show up to team meetings like a rock star: sleepy and totally chill. He'd say he wanted to sync with the team, and then leave. Back then he seemed like a rock star to me - I don't know, that's just the association that stuck. By the way, Vlad K [@vld_kms](https://x.com/vld_kms) also worked on that same Puzzle Lend team, and he knew his way around lending protocols pretty well. I only worked there for a couple of months, after which I was let go, and a week later the whole of Waves fell apart, the project was frozen, and the entire team was disbanded. After that side gig of mine, in late fall 2022, our Prague crew decided to build a lending protocol on TON - **EVAA** (the name, by the way, was my idea - it's an acronym of the first letters of the original co-founders' names). In December 2022 I sat down to write the first version of the smart contracts, started studying other lending protocols, and realized I couldn't hack writing pure DeFi. After several months of attempts, research, and sleepless nights, I decided we needed to bring someone onto the team who really understood lending. In winter 2023 I invited Vlad K to join the [@evaaprotocol](https://x.com/evaaprotocol) team. And that's how the project that took several years of my life began. For those not in the know: I was EVAA's CTO - I co-wrote, deployed and upgraded the contracts; at the peak they held over **$87M TVL**. It was a genuinely big product with many different kinds of modules. > I want to do a separate post about EVAA in detail later. I think you could shoot a decent TV series based on the events that happened in my life and the life of that project. ## 1.1. Meeting Vova [@vlzhr](https://x.com/vlzhr) In the summer of 2024 I was passing through Amsterdam; at the time Vova was doing his master's degree there. He was my only contact in the entire city, and I decided to try my luck and invite him to meet up - to chat and get to know each other better, since back in the Puzzle Lend days we hardly ever talked directly: I was just a dev he had nothing to discuss with. Over those couple of years of building EVAA, my main value came to be my expertise in developing on TON. The CTO of a lending protocol on TON was essentially walking documentation, and apparently Vova saw value in that (UPD, Vova's comment: "*I saw real value in the fact that at 20 he was personally carrying a contract with millions of dollars in it. I've been there myself, and I know not everyone can handle that.*"). Anyway, we had a wonderful time, spending a couple of hours discussing orderbook DEXes and how one could build something like that in FunC TON smart contracts. ## 1.2. Getting to know the LMMM model And so - November 2024, Dubai. The second TON fam event. Everything is wonderful, and the future is bright. EVAA has its own booth; it had become one of the ecosystem projects. Over a thousand people at the event. I couldn't walk ten meters down a hallway without stopping to run into some acquaintance I'd spent two years chatting with in TON Telegram chats and was now seeing in person for the first time. Those were wonderful days. *[Image: EVAA booth at the TON community event in Dubai, November 2024]* By that point Vova had already started shaping the idea of Ranges and had picked [@ton_blockchain](https://x.com/ton_blockchain) as one of the chains he wanted to launch them on. By the way, here's his article from November 2024: [Megapools with Concentrated Liquidity as the DEX Endgame](https://medium.com/@izhur27/megapools-with-concentrated-liquidity-as-the-dex-endgame-049d2fe730d7). In general, I'd advise you to read all the articles about Ranges ([Inventing Ranges](https://medium.com/@izhur27/inventing-ranges-40054df9328e), [pt.2](https://medium.com/@izhur27/inventing-ranges-pt-2-6bcf36f68800), [pt.3,](https://medium.com/@izhur27/inventing-ranges-pt-3-single-token-liquidity-provision-59f96c482d11) [pt.4](https://medium.com/@izhur27/inventing-ranges-pt-4-quantitative-research-dc7fc95c0241)). They tell the story of how the LMMM model was invented from scratch, how the formulas were derived, and what consequences they produced. There are four articles - I recommend reading all of them. So, choosing TON at the end of 2024 was no surprise: $TON was at $7 back then, the whole ecosystem was growing like crazy, people from all over the world were coming to us from other chains, and so on. Half of the Waves foundation had moved over to the TON Foundation, so [@vlzhr](https://x.com/vlzhr) apparently decided it would be a good idea too. He developed a prototype of the Ranges contracts and decided to ask me whether I could help him with a review and advice on TON-specific technical details. We decided to meet in person. We talked the whole evening, and honestly we covered a countless number of topics. About life and meaning, about DeFi, and most importantly - about hunger. Staying hungry and not getting complacent when you already have everything is genuinely a hard task. But the main thing that happened was that Vova walked me through the Ranges idea in full. In every detail. **Multitoken pools + concentrated liquidity = endgame AMM architecture**. You know what I mean - open [app.coffer.so](https://app.coffer.so). That was the moment when, for the first time in several years, I felt real, genuine interest in something. By then I'd been doing EVAA-only for several years, the routine was starting to wear thin, and building on TON had become monotonous. And then someone tells me about **LMMM**! I wanted to build it; I wanted to be part of its story. I felt something new, something unique. In that moment the idea of this architecture dropped anchor in my head. I did look over Vova's contracts for TON and gave him feedback, but in the end the full launch was postponed. You could probably say that after TON fam #2, nothing good ever happened on TON again. All the big launches were canceled or postponed. And it's for the best that Ranges didn't launch on TON in early 2025. Both for me and for Vova. ## 1.3. First work on LMMM: [@rangesfinance](https://x.com/rangesfinance) on Ethereum August 2025. Vova invited me to work on this idea and be the CTO of Ranges on [@ethereum](https://x.com/ethereum). We did several calls where he explained what was built and how. What the math was and what mechanics followed from it. I grokked every formula and picked apart the behavior of p.min and p.max in a notebook with a pencil, working through examples, plugging different numbers into them, trying to calculate everything by hand and see the behavior of the formulas with my own eyes. Around that time I independently derived the consequences of the formulas, the problem-solution setups. I derived the idea visually, saw it for myself, and understood where the extra yield comes from that the LMMM model generates compared to [@Uniswap](https://x.com/Uniswap) v3 (and similar two-pair DEXes with CLMM). In short: in Uniswap v3, around 86% of liquidity sits in ticks that swaps never pass through. If you create a CL pool with several pairs, that unused liquidity gets reused for other pairs. Nowadays this is described on our landing page and seems obvious, but back then it was a discovery for me. I really loved that pioneering spirit. In the end my involvement was small, because in those months I was extremely swamped with EVAA. I realized I couldn't add much value while busy with EVAA, and decided to leave the project so as not to slow down the Ranges team. I really was more-than-full-time focused on EVAA. And since I'm a responsible person, if I myself know I won't be able to work on a project with full commitment, I'll say so directly and step away. On my way out of the project, I immediately put in writing that in 2026 I'd like to keep the option of going off to solo-found this idea, with Vova on board as an advisor. ## 2. On the motivation to be a solo founder I've always had a strong desire to become a true solo founder and see what I'm capable of. One of the main reasons - I really love freedom. At EVAA, in the CTO role, freedom was limited, because all the decision-making is done by the CEO. Building a project when the decision-making isn't yours is a completely different mindset: yes, you hold a C-level title, but your freedom essentially comes down to variations in how features get implemented, while the feature list / roadmap / strategy is decided by the CEO. And that's fine - the 2022-vintage sepezho had no clue what roadmap to make for a lending protocol on TON. But with years and experience, I started forming opinions of my own. And a restricted opinion is an absence of freedom. Anyway, that's why I have such a strong drive to be a solo founder. In 2024, in that format, I started the **Syntonics project** (like [@synthetix](https://x.com/synthetix) but on ton), [stx.tg](https://stx.tg) - synthetic derivatives on TON. Essentially the ability to mint a coin whose price is pegged via an oracle to any asset. Collateralized by TON. It was a cool project, but once again I didn't have the bandwidth to run it, and I made EVAA the priority. A CTO's responsibility in a lending protocol is quite large, and there was no way to pass it off to someone like a hot potato. You're forced to keep running the project by inertia, because there's simply no one else to do it. So Syntonics had to be frozen. In the end I handed the project over to my good friend Bogdan; he forked it and built [@sydefi](https://x.com/sydefi). Unfortunately, any TON DeFi project started after the 2023 DoraHacks era was doomed to a hard life. Anyway, here's my point: I had made attempts at being a solo founder. But I understood I had to keep my focus on EVAA, and, being a responsible person, I killed off every new venture myself for the sake of the great goal begun in 2022. [@coffer_so](https://x.com/coffer_so) is the first project where all of my focus finally belongs entirely to my own thing. ## 2.1. On the motivation to switch ecosystems: State of TON 2026 TON's ecosystem projects are shutting down one after another. Zero activity. The TON Foundation has been dissolved. Nobody paid the oracle provider subscription ([@PythNetwork](https://x.com/PythNetwork)) that serves all of DeFi on TON (because there is no TON Foundation) - everything's been left to drift. When we tried to ask the powers that be ([@durov](https://x.com/durov)) what TON DeFi is supposed to do if even the on-chain oracles are getting switched off, we were told: figure it out yourselves. "Honestly, the trend was already visible last year — in how TF (not)launched tgBTC, in the TF staff turnover, in other signs I'd rather not spell out here. That's not what this post is about. Anyway, back in 2025 I started scouting a plan B for myself and asking the question: "*what's the next big thing that I wanna build and where should I build it?*". ## 3. Solo founder of a project on Solana A small preface. What follows is simply a month-by-month recounting of events, of how the project developed. What path was traveled from 0 to 1. From my perspective, of course, and with my commentary on various situations. Right around the start of building [@coffer_so](https://x.com/coffer_so), I listened to a podcast with Bill Ackman [@BillAckman](https://x.com/BillAckman). And I really liked one phrase of his; put simply, it goes: "*every day I took small steps in the right direction, and each of them seemed unimportant and insignificant, but years later, looking back, I realized how far I had come.*" That phrase lodged deep inside me and gave me the motivation to start my own thing. Yes, every day I took micro-steps in the right direction, and each of them seems vanishingly small on the way to the great goal, but now, after just 8 months of working on the project (I'm writing this text in August, 2026), I look back and realize how much has been done. ## 3.1. January: hackathon - from zero to MVP January 2026. New Year holidays, but I'm in hackathon mode. From absolute zero to the first version of the contracts took me **ten days**. I had an excellent understanding of how to build DeFi (experience from EVAA) and what math to bake into an LMMM DEX (experience gained in 2025 while working on Ranges). With [@rangesfinance](https://x.com/rangesfinance) we signed a partnership and non-compete agreement saying I wouldn't go onto Ethereum and they wouldn't go onto Solana. And that's how the Coffer story began. I deployed the smart contracts to Solana devnet, and on January 14 I made **the first on-chain swap**. Then I threw together the first version of the site in my signature sepezho vibe-code style: black background, white text, Times New Roman font, dashed borders on all interactive elements, and all content laid out in a single column in a block up to 350px wide - that's so the desktop and mobile layouts are one and the same. The first version of the site had no backend. You could open a pool by its address and view its parameters; below, right on the pool page, there was a simple swap form. The swap was made directly in that specific pool. *[Image: First devnet version of the app: a minimal page with a four-token pool's parameters and a swap form]* Later, on January 20, in the third week of development, I hand-drew the first version of the logo. On the technical side: I added pages for depositing and removing liquidity to/from a pool. Added a page for deploying new pools. Then I stood up a backend with a database. The DB simply held pool addresses (they were automatically added to the backend DB whenever a pool was created on the frontend), those pools' token tickers, and a couple more parameters. Thanks to the backend I was able to build the pool list page. All of this was really exciting - I love creating projects from scratch for the sake of the creation process itself. When you see how there was "nothing" and then "something" appeared - that first stage from 0 to 1 is the most interesting and inspiring; building MVPs has always been my favorite part. Because it's the fastest visible result. Here are the posts with screenshots of the first version of Coffer's UI: [the first Devnet pool](https://x.com/coffer_so/status/2013770562875674980?s=20), [the new domain and liquidity removal page](https://x.com/coffer_so/status/2014021422071324724?s=20), and [the pool search and pool creation updates](https://x.com/coffer_so/status/2014345929864732787?s=20). ## 3.2. February: China and buying a pre-audit Then I flew to China for a month, worked less, and had a lot of time to think and reflect on goals. Coming back from China, I realized I needed to put my focus on this project, and started devoting more time to it. In February I found auditors [@serokell](https://x.com/@serokell); we agreed that the first pre-audit would be ready within March - it was a simple security review by outside professionals. I say pre-audit because it wasn't a full-fledged audit. It was more of a third-party assessment of the contracts pointing out the main issues. I fixed all of them quickly, and the contracts were ready to go out to mainnet. Obviously, for the first months only my own liquidity would sit on the mainnet contracts, so a full audit wasn't needed yet. I wanted to iterate fast and, above all, to deliver at a constant pace in small pieces. That's why the decision was made to go with a pre-audit and a mainnet launch on a simple version of the smart contracts. I planned to add a fairly long list of features of various kinds (for example max-selloff / range manager role / single-token deposit) later, and only after adding the new features go through a full audit with a big team, a detailed review of every function, feature, logic, etc., and a proper audit report. ## 3.3. March: pre-audit and a UX-friendly redesign In March, while the pre-audit was underway, [I redesigned the whole app with AI](https://x.com/coffer_so/status/2031379729824031142?s=20) into something more modern and more presentable to an outside user. *[Image: AI-assisted redesign of the app's landing page, March 2026]* I do of course adore my black-and-white layout style, and I also adore ASCII layout, but for a mass audience that approach just doesn't fly. A random visitor doesn't trust sites with that kind of layout and assumes it's either something very complicated or that they'll flat-out get scammed there. So I made the decision to go with a standard, "like everyone else's" design. For exactly the same reason, the app's first landing page was built, describing the basic problem and solution that I had grasped back last year while working through Vova's formulas with a pencil on paper. One of the realizations of that time was a unified swap page with a router. Just as with the design, I understood that I needed to focus on simplicity. On simplifying the UI. A couple of days after the full app redesign, I delivered the swap page. As with everything, my strategy is: deliver first, then polish it and make it shiny. So at first it was pretty dumb and only let you pick a single pool to swap in - there were no "smart routes" with optimal splitting of the transaction into parts. *[Image: Early swap page that let you pick a single pool to swap through]* From the Twitter posts you can see that for a while I went into berserk mode and was delivering one fairly big feature every single day. The next day [I added backend parsing of all pool transactions and displaying them in the interface](https://x.com/coffer_so/status/2032491440538890499?s=20). Then I created the second most important page for the user in the app - **the portfolio page**. Jumping ahead: in the future, along with the shift in the project's positioning and the change of target audience, this page would become the main page of the entire app, with swap page dropping to second place. But in the early days everything was different: we were building precisely a DEX, so the swap page (as in all normal DEXes) was the main page, and all the polish-it-to-perfection effort was aimed at it. ## 3.4. April: assembling the team I realized that the project's further development required a team. The first two employees were people I knew. **Arthur**, who came on to write posts, handle marketing, and look for partners. But most importantly - I brought in my good friend **Maksim**, with extensive experience in frontend development and AI systems. He took over the entire frontend and started rewriting it, updating the design (already to the third version) and noticeably improving the code quality. He significantly transformed the design and quality of every page, some of which he re-laid-out completely from scratch. Yes, that's the bad side of vibe-coding: if your vibe-coded app makes it to mainnet and to users, the trade-off is that you'll need a person who can clean all the technical debt out of the repository. He started rewriting page after page, scrubbing out every flaw. There were dozens of flaws on every page. You know, before Maksim arrived, only the perfect user flow worked reliably: one step to the side - and yet another bug would crawl out. In two weeks Maksim rewrote the app's main pages, and on April 13 [we shipped what was already the third redesign](https://x.com/coffer_so/status/2043804610109034816?s=20) *[Image: Third redesign of the app: the Explore Pools page with devnet test pools]* You really can do development entirely with AI, but before going to mainnet you still need people capable of reading through the entire codebase and making corrections. For the contracts, that's the auditors and me: I personally reviewed every line of the smart contracts many times over, plus the code went through a third-party pre-audit and is now going through a full audit as well. For the frontend, it's my friend Maksim whom I brought in. For the backend, it's **Dmitry**, the third person I invited to the team. In April we applied to the [@colosseum](https://x.com/colosseum) hackathon; hopes were high. We were practically certain we'd win - after all, we're building such an innovative DEX. Also in April [we created and published the first version of the Coffer SDK](https://x.com/coffer_so/status/2050301547637019005?s=20). I brought this experience over from EVAA: there, the SDK turned out to be a highly effective tool for onboarding new developers into EVAA so they'd build an ecosystem on top of it. Building an ecosystem around your DeFi project is very important. If your DeFi project is aiming for tier-1 in the blockchain space, it has to become a platform for new projects to grow on top of it. If you're aiming to be a liquidity hub (and we are), a quality open-source SDK is simply a must. So, EVAA is where I got this idea and this understanding. That's why with Coffer I also decided to take an SDK-first approach. The goal is to create the same kind of dev community around it. Arbitrageurs, solvers, DeFi degens with their scripts, on-chain event analysts, and everyone-everyone-everyone who wants to work with our smart contracts in any way at all. The SDK is fully open source under MIT, and anyone is free to do whatever they want with it. It's also simply very good documentation. Code as documentation for the contracts. I've noticed that it's easier for people to sic an AI agent on an open-source SDK to understand precisely and reliably what works and how, than to go read the docs. The SDK also gets maintained more actively. We use it in our own frontend and backend repositories. So when a new contract version is released, without updating the open-source SDK we can't update our own app's backend or frontend. That lets us enforce the SDK-first rule. As a result, all the developers out there get the same level of access to off-chain code for working with the smart contracts as our in-house devs. The SDK is a seriously big deal! I have high hopes for the SDK. Leaning on the EVAA experience, once again. ## 3.5. May: mainnet launch and a wave of events In the first days of May, after the security review of the contracts and fixing most of the frontend bugs, [we go to mainnet](https://x.com/coffer_so/status/2051384620537569351?s=46)! Now there's real money sitting on the contracts. A couple of days after launch I quickly vibe-coded an AMM bot that started syncing our pools' prices with Jupiter and other DEXes. I'll tell you about it a bit later. Also, practically from day one, I took on setting up our profile on [@DefiLlama](https://x.com/DefiLlama). I wanted to have the project's full development history on DeFiLlama. So that the history of the charts and so on would be visible for everyone. Also from the start of the month, Dmitry, our backend lead, joins the Coffer team - and immediately goes off to do the same thing as Maksim: cleaning up the codebase after sepezho's vibe-code :D First week of May, and I decided to drop by an Ethereum hackathon that was happening in Prague that day. I had reached out to the [@stabbleorg](https://x.com/stabbleorg) (it's a DEX on Solana) and wanted to talk to a person from that project. It turned out he was in Prague that day for the Ethereum events. We met, and he told me that a DEX's target audience should be the LPs. That was a pretty awesome insight, which he chose to share free of charge. A very important takeaway here: **it's not the swappers who matter most, it's the liquidity providers**. And you should do everything to make the latter maximally comfortable. If you have liquidity, the swappers will come on their own (arb bots / solvers / aggregators, etc.). So I decided to split the product's growth into two stages. In the first stage, the only liquidity provider is me, and our target audience is swappers; and the second stage is when we get volume (through arb bots, or solvers, or integrations into swap aggregators - doesn't matter), we switch the target audience to LPs and actively work on growing TVL and attracting liquidity. For that, it was strategically important to first do a full audit and sort out volume. In the middle of the month an amazing thing happens: **a liquidity provider with serious experience finds us**. He found us through Twitter recommendations. Fully organic. He used to provide BTC liquidity into Stabble pools, and he reached out to us himself, explaining his problem - he couldn't put together a stable bitcoin pool with yield-bearing tokens in it. This user realized that on our pools he'd be able to build such an LP position. When a user came to us and started explaining to us - the creators of the project - what a big problem this was for him and how important it was, I was in shock. Reminder: fully organic! We took his contact and agreed to get back to him once creating pools with large TVL would be safe for him - i.e., once there's a full audit of the contracts and a dex aggregator integration (you need volume too, after all). Literally a couple of days after that incident, yet another completely random user [@0xBiZzy](https://x.com/0xBiZzy) comes to us, having found us in Twitter recommendations. **He creates a memecoin pool** with Italian brainrot memes. *[Image: A seven-token memecoin pool with Italian brainrot memes created by a user]* [Here's our post about that case](https://x.com/coffer_so/status/2055975426162368986?s=20), in the comments of which he sends an emoji. We tracked down his Twitter account, and he turned out to be a Solana memecoin trader with 50k followers - Meteora and others follow him. [He even wrote a post about us](https://x.com/0xBiZzy/status/2055378400013889955?s=20)! Once again, please note: fully organic! Just for reference, on TON I never had anything like this. Not at EVAA, not in other projects - people finding out about a project this organically and testing things out on their own. A few days after that came the [DDoS](https://x.com/coffer_so/status/2056443840530137192?s=20). Yes, things were happening practically day after day! The DDoS itself was nothing special - we'd had DDoSes back at EVAA too. The standard scheme: a dude runs bots, starts taking your site down, DMs you on Telegram saying "I've found a critical vulnerability in your app that takes the whole thing down," and then extorts money. We had that at EVAA too - I believe they asked for 6 ETH back then; we handled it quickly there, and here at Coffer as well. The funny thing is, this "hacker" was essentially an early tester for us, and it was balm for the soul. I played along and said something like "oh no, oh my god, I can't believe it - do it again," and while he was running his DDoSes (which don't come free for him - he's essentially burning money to push millions of requests at our CF+backend), Dmitry, our backend guy, and I were testing different ways to shield the backend. He launched it like that several more times. To bait more DDoS waves out of him, we kept telling him we didn't believe he was the one hacking us — look, the app is running just fine. And whenever he'd start his "attack", we'd rush to the backend metrics to see what else was still exposed. He was a proper QA tester for us. Every time he launched a bot wave, I'd message him: "wait, wait — ahh, missed it again, didn't catch a thing." We ran this play a few times, and between waves we kept hardening the backend. The last time I straight-up told him he was photoshopping it all and I didn't believe him at all - go on, run it one more time))) By that point we'd already plugged all the holes, the DDoS didn't get through, and I blocked him. Thanks to this hero for the issues he found! To be fair, our backend back then was minimalist, and that was a conscious decision - development went faster that way, and it posed no risk to user funds: the money lives on-chain, not on the backend. We simply hadn't expected that someone would try to DDoS us in the very first weeks of mainnet. Just so you understand, for comparison: at EVAA, the DDoSes and these kinds of attacks only started something like a year+ into mainnet, when there were already millions in TVL. My point is the contrast and the comparison - just how alive the audience on [@solana](https://x.com/solana) is. *[Image: Cloudflare dashboard during the DDoS: 6.33M requests, 5.16M of them mitigated]* That month, right after launch, practically every day someone reached out to us fully organically, poked at the product, and tried to do something: hack it, or give advice, or create a pool! An amazingly alive community, full of people. They all find you themselves and try to do something themselves. I repeat: fully organically, from Twitter. With zero dollars spent on ads. All this time Maksim and Dmitry weren't sitting idle, and in May we launch two big updates. 1 - **smart routing for the swap page**. Previously, on the swap page, the user simply picked the pool they wanted to swap in; now the user picks token in, token out + amount, and the backend itself computes the optimal route across our pools. The backend also learned to split the volume into chunks and solve the "optimal flow" problem, taking into account all the pools' parameters (their slippage, fees, and other kinds of configs). Users were given the ability to manually pick a specific pool in routes if they want to, plus the ability to inspect the routes. 2 - and this is very important: [**we launch the XP program!**](https://x.com/coffer_so/status/2057891702933721184?s=20) This was a genuinely big release that required a lot of backend work to index all users and compute how much XP to credit them. At first I decided we'd hand out XP for providing liquidity and for swap volume, but then, right before publishing the campaign to prod, I realized that permissionless pool deployment would let someone deploy their own pool with 0% fees and start churning volume through it, farming XP endlessly. I came up with the fix literally within a few minutes, and practically right before publishing we changed the rule - XP is given not for swap volume, but for $1 of fees paid on a swap! That's a cardinally big difference: now it's precisely the actions useful to the protocol that get incentivized - providing liquidity and the fees left behind on swaps (with the swap fee split 80% to LPs and 20% to the protocol, for the record). This discounted any swap volume down to a concrete measure, equal across all pools - a dollar of fees! It doesn't matter whether you have a hundred thousand of volume on a pool with 0.01% or a thousand of volume on a pool with a 1% fee. This elegant solution makes those two cases equal. The action useful to the protocol is the fees left behind. By the way, for reference: for farming XP it's much more profitable to simply provide liquidity. If your goal is to farm XP, then either bring in referrals (more on that later) or provide liquidity. You won't farm much on fees. Although for arbitrage bots and solvers it is, of course, a nice bonus for their work and for routing swaps through our pools. Since all the tracking is fully on-chain, arbitrage bots rack up incredible amounts of XP, and my estimate is that in the end they'll take a good slice of the whole XP pie. By the end of May we already had **$40k TVL**, but still zero real volume and practically zero users. At first I started placing my own liquidity - remember, at this stage we still didn't have a full audit. Later [@vlzhr](https://x.com/vlzhr) started pitching in: he helped create a couple of pools and to this day is the protocol's #2 liquidity provider after me. Despite all the risks! There he is - a true believer! By the way, it was Vova who created one of the best-performing pools, **3pool3x** - the magic of this pool lies in its simplicity: SOL+USDC+cbBTC + 3x Concentration Factor (CF). Because this pool is one of the simplest and has the widest range, arbitrage volume would later flow through it constantly, giving this pool a good continuous APY. As for me - as the protocol's creator and a developer, the ordinary cases don't interest me at all: everything about them is already clear, so starting with my very first pool I began experimenting and creating completely different, unusual pools. For example, a bitcoin pool with 6500x CF. By the way, adding zBTC seemed like a mistake to me at first, but later I realized that the bulk of the volume started flowing precisely because of the fluctuations of the less stable zBTC against the more stable cbBTC (for comparison: one has a couple million of liquidity across pools, the other hundreds of millions). After creating the pool, while moving liquidity into it, I discovered unexpected behavior in my own protocol! And it's counterintuitive. Trying to add a less stable asset to the basket, I ended up in a situation where, as a liquidity provider, I had to hold more of that token on hand! *[Image: Bitcoin pool with cbBTC, xBTC, wBTC and zBTC, each with its own CF and price range]* Now let me explain how that happened: it comes down to a pool config. Because zBTC more volatile, I wanted to give it a wider price range. I set it a lower CF, thereby making the range window (p.min p.max) fairly wide, about 0.995 -> 0.999 zBTC to cbBTC. For comparison: the entire size of the wBTC and xBTC ranges against the base asset (cbBTC) was in single thousandths of cbBTC, i.e. several times narrower. Accordingly, to achieve such a narrow range I set a much higher CF (roughly speaking, 10x higher) on those tokens, on the order of 6500 units of CF (i.e. 1 wBTC token gives the pool depth as if 6500 wBTC were sitting there), versus a CF of 650 for zBTC. But to my amazement, when I deployed the pool and started providing liquidity into it, I discovered that with the lower CF, in order to maintain the required token ratios, I had to deposit several times more (!!!) of the zBTC token in actual liquidity than of the other, more stable assets. I.e., I wanted to give the less stable asset a wider range, and instead I got a setup in which I had to deposit more of the actual asset that is less stable (and obviously, as an LP I'd want to reduce my exposure to it). Anyway, it all sounds obvious now, but back then I was discovering, in practice, mechanics of my own protocol that no one before us had ever seen. And that drives me! And now for the solution: to solve the problem described above, zBTC's weight needed to be set even lower than I had set it. The weights I set were: zBTC 10%; wBTC 25%; xBTC 32.5%; cbBTC 32.5%. Let me illustrate right away with a concrete example: if I, as an LP, wanted equal exposure to all the coins, so that depositing into the pool required exactly 1:1 of all the coins, the weights would have to be around: zBTC 4.2%; wBTC 14.1%; xBTC 40.8%; cbBTC 40.8%. And at those weights, with the CFs I had set, all the assets deposited in a 1:1 proportion would have different ranges among themselves, with different widths and different depths. Can you believe it? That's really cool! It's exactly the problem that the user with serious experience LPing into BTC pools wrote to us about at the beginning of the month. In mid-May I met **George**. It was a spontaneous acquaintance at go-karting in Prague. We chatted, and I learned that he'd run a project launch with **$270M** first-week trading volume. In those days I happened to be looking for an experienced CMO for us, and we decided to meet with him again. By the end of May George was already working with us. He started setting up marketing processes, as well as planning campaigns for the project's growth and the budgets. Also in May **we opened Coffer's official entity**! For signing various kinds of contracts and so on. Looking back, I'm amazed at how much can get done in a single month! May was a very packed month for me and for Coffer. ## 3.6 June: the first big volume, a sea of development, and losing Colosseum We spent half of June on setups and tuning the team's internal processes, rewriting the project, and bug fixes. We also developed and launched **referral system v1**. For that, it was important to ship SIWS support. In plain terms, it's cryptographic verification on the backend that the connecting wallet really is the exact right address and that all subsequent actions within the session are performed by that very address; accordingly, with the same cryptography we confirm that the current user really did arrive via another user's link and becomes their referral. The system is the same one I built at EVAA, with the wallet address in the link, and anyone can create their own referral link. The difference from EVAA here is the two-level referral scheme, plus bonuses for the referrals themselves. EVAA didn't have that, and at Coffer we decided to make this system even more supportive. Those who refer and bring in their friends get a whole 12% of their XP and 6% of the XP of second-level referrals (a referral's referral - like a friend of a friend). We also understood that we needed to motivate the referred users themselves to become referrals, so we decided to give them a 3% XP boost if they became someone's referral. In short, at Coffer it's very profitable to be a referral. It's a free win-win for everyone. These extra XP percentages are simply minted on top into the overall pool and dilute everyone else's positions. In mid-June we found a design studio ([@relate_studio](https://x.com/relate_studio)) that was ready to develop our branding and professionally put together a brand kit for us, plus a landing page. We signed and agreed to start the work in July. Around those same days I signed the auditors. It was the same guys who did our pre-audit - [@serokell](https://x.com/serokell). They had audited [@1inch](https://x.com/1inch) on Solana and other projects. They have strong expertise and a lot of experience. We likewise signed for the work to start in early July. Since the pre-audit done in March, a number of features had accumulated that I'd developed on our smart contracts. For example, 1-token deposit (a standard module - other DEXes have this too), the max-selloff window (more on it below), dynamic fees (on them, also two paragraphs down), the range manager (about this below), the supervisor, and so on. Plus, a full audit meant several developers would be brought into the audit and a far more scrupulous and diligent job would be done reviewing every line of the smart contracts and every function. At the end of their work I'd receive an audit report and so on. So for August we had a target of rolling out a new version of the contracts (it was called v5) with a batch of new features and improved security. Plus publishing the audit report, and also updating the entire design and a complete rebrand from the design studio. --- > **The range manager** is a role that is allowed to change the virtual balance (and CF) and the weights. And to do only that - it is allowed to do nothing else. The admin sets the range manager and a config for how often and how strongly it can make changes to the weight and the virtual balance. From there, the range manager can be a script, a bot, or a real person who, every so often, will shift the weight and the virtual balance so as to, for example, change the pool's working range for some pair. Or change the weight and change the price of one token against another. The admin themselves sets how tightly constrained the range manager is in doing this, for example to 1% per year. This mechanic makes it possible to create LMMM pools with a veeeery narrow price range and a veeeery high CF, and to constantly shift the virtual balance and the token weights in the pool, thereby constantly moving the pair's price range toward the real price. For example, you can make a stable pool with very great depth, a narrow range, and high CF, consisting of USDC, USDT, USDe, sUSDe. Yes! That's a stablecoin pool with yield-bearing assets inside! And the range manager will itself shift the price window for sUSDe by, say, 5% per year! Basically, matching the speed of the price's growth. And there can be a huge number of mechanics like this. You can put together bitcoin pools or Solana pools with all kinds of wrappers and yield-bearing assets. A really cool mechanic. > **Dynamic fees and the max-selloff window.** 1) Max-selloff window: It's a moving sliding window with unique settings of amount-to-sell for each token. For example, the admin sets that only 100 units of token X can be sold per hour. That means users won't be able to sell 101 units of the token within an hour. This protects liquidity providers from a sudden, sharp zeroing-out of one of the tokens in the pool's basket. 2) Dynamic fees: Then, on top of this window, I conceived and developed the dynamic fee logic. The admin can set, for example, that from 80% of the window the protocol starts taking a 2% swap fee, and as the window fills up this fee grows, and after the slope mid it starts growing very fast. For example, having sold 80 tokens within an hour, the user pays 0 dynamic fee. Selling 10 more, they'll pay a 2% dynamic fee. And selling another 10 (filling the window from 90 to 100%), they'll pay, say, a 10% dynamic fee. My experience from the lending protocol helped me apply the approach of building an exponential growth curve for the size of the dynamic fees as the token's max-selloff window fills up, via an approximation using two straight lines and a slope mid point. Everything just like in lending protocols - I literally have the experience of building exactly that behind me. Only there the slope mid is the utilization target point, while for us it's simply the slope mid point. *[Image: Sell-off window tooltip: a rolling hourly cap with a fee curve that starts at 80% fill]* And by the way, I forgot to tell you the most important and coolest part! The dynamic fee **is paid in tokenOut and goes 100% into the protocol reserves** (i.e. it can't be swapped out; in the future I'll add a separate parameter so as not to mix it with the protocol reserves). This is needed because, obviously, LPs don't want depreciating tokens that pools get drained with (the ones all the other pool tokens get swapped out for): they're not interested in receiving dynamic fees in that token; they're interested in receiving those fees in any other token and stacking them into a separate basket that can't be swapped out. In the future I'll build the logic for claiming these fees separately. So that's the mechanism, and I don't know of any other DEXes that have a mechanic this cool. On top of that, the max-selloff window can be made as large or as small as you like, and you can also make the dynamic fee curves start from 0% window fill. In short, this mechanic holds a great many possibilities for customizing LP positions. Our LMMM DEX is becoming a hub of innovation in the DEX world! --- Just so you understand: for practically two months our pools sat with no volume whatsoever. And now back to the AMM bot that I launched when the contracts went live on mainnet at the beginning of May. This bot was as simple and janky as it gets, often failed transactions, and in total I lost about 400 dollars of its balance on it. One time it swapped all its tokens into SOL and I didn't notice, and right at that moment SOL dropped noticeably over a couple of days, and I lost 200 dollars on the exchange-rate difference. I added auto-swaps into stables so that the bot would always keep its balances in USDC. Later I decided to add a paid RPC key to it for more stable and faster operation, but I missed setting limits on RPC requests, and the account was on pay-as-you-go with a card attached. As a result, my vibe-coded AMM bot burned through $200 of RPC credits in a single day. At that moment I realized that vibe-coding from scratch had cost me more than hiring a backend dev who would have built this bot. For a while there was no on-chain movement on our contracts at all, and everything looked pretty stale. The liquidity sitting there was mine, and all the swaps were made by my own janky AMM bot (which lost more money to bugs than it earned on arbitrage :D). The little bot was doing about 100 dollars of volume a day - basically nothing. But by the end of June, it was finally our turn to celebrate! Suddenly, on one random day, some arbitrage bot integrated us and started pushing **8k of volume a day** through us! *[Image: DefiLlama chart for June: TVL around $35K and the first big daily volume spike]* We looked at its on-chain transactions and saw that it was a professional AMM bot with more than 1M transactions on it, one that found opportunities and evened out markets steadily about once every couple of minutes. The sheer fact that this happened spontaneously was astonishing. Exactly like all the other people who came to Coffer, this person came fully organically, probably having found us through Twitter or DeFiLlama. [We wrote a post about it](https://x.com/coffer_so/status/2071248252091961581?s=20) and tried to reach out to him, but we didn't manage to. So we still don't know who this hero is. He made our day - I walked around smiling for half the day. From the moment of his integration, volume began flowing through us steadily - it was as if the protocol came alive. Sleeping pools with 0% APY woke up, and the liquidity started working. This bot automatically parsed and connected new pools, knew how to work with different pool configs and so on - i.e., it could fully parse the store and construct custom transactions for our pools. Let me point out that he carried out the integration entirely without our help. Our contracts are fully written from scratch, and the contract code is not open source. He could only have worked with our open-source SDK and documentation. This case shows how important it is to have a public SDK: it lets people integrate us without our involvement and without even reading the contracts. At the end of the month [@colosseum](https://x.com/@colosseum) announced the winners of the hackathon that we'd applied to a couple of months earlier. And honestly, it really stung that we didn't win it. We weren't even mentioned in the "honorable mentions." Even though I filled out all the forms, provided all the access, and recorded video progress reviews every week, apparently I failed to get the idea itself across to them. We really had done a great deal over those months and come a long way. Just look at all the text I've written above. Herculean efforts were made to reach mainnet and get our first arbitrage integration with volume. At the moment the winners were announced, we had about **35k TVL** and around **8k of daily volume** flowing. In a protocol that was built from scratch! That didn't exist before this hackathon began! Looking back, I realized that I had leaned too hard on the tech and the product and devoted too little time to the presentation and to explaining the idea. Then again, could it have been any other way? I'm building a startup, and my first goal is to deliver the product, and I had no time to explain it and wrap it up prettily. Anyway, I reached out to Colosseum co-founder [@mattytay](https://x.com/mattytay) and asked him for feedback on why we were overlooked at all, and his answer was along the lines of "*yes, you did build the project, but we didn't understand what the project is - is it just a DEX? there are plenty of DEXes.*" It was entirely my mistake that I didn't explain clearly that this isn't just a DEX, but a CL + multitoken DEX. That combination has never existed before. It's a unique, fundamentally new AMM design. Anyway, it hurt a lot, but life doesn't stop there. Everyone falls - the ones who win are the ones who know how to get back up! I took this situation as a lesson: I need to work on pitching the idea. It also gave me a ton of motivation to build a big DeFi project and prove by action that the idea was underrated! ## 3.7. July: redesign, audit, TVL growth, and the first project pool On the first of July, the audit, the redesign, and the volume campaign all begin at once. Yes, in early July **we launch a month-long volume campaign**. George, who had come in May and set up all the processes in June, was already busy devising our first campaign. He found a platform for running campaigns of this kind and built the strategy. It turned out to be quite effective: yes, 95% of the participants will leave after the campaign ends, but that residue, those 5% of interested people, is very important to us. And even with poor conversion, it turned out to be one of the best ways to get the first on-chain users into the protocol. Interestingly, in the last two days of July (look at the volume chart on DeFiLlama), volume shot up to hundreds of thousands of $ per day. Since the campaign ran for a month and the winners were announced based on the month's results, nobody was interested in swapping at the beginning or the middle of the campaign. Everyone decided they'd be the smartest one and, at the last moment, swap their way sharply into first place. In the end, that's what everyone did, and in a single day almost a million dollars of volume passed through our pools. Watching this and analyzing it was very interesting. *[Image: DefiLlama chart through early August: TVL past $70K and daily volume near $600K]* Оver the course of the campaign at least three new arb bots found their way into our pools: they spotted the volume the campaign was generating and moved in. The mechanic turned out to be beautifully simple. People battling for prizes swapped in random directions, pushing token prices in the pools away from the market — and the bots instantly swapped the other way, pulling the price back in line and pocketing the difference. In the end it came out to almost exactly 50/50: every dollar of prize-hunter volume dragged a dollar of arb volume behind it, a bot running the same trade in reverse. I knew the theory, but I didn't expect it to work this reliably in practice *[Image: Top wallets by volume: cross-DEX arbitrage bots made about 51% ($258K)]* At the start of the month, [Coffer's TVL crosses the 1 BTC mark](https://x.com/coffer_so/status/2072687714994954274?s=20), and some incredible **50% APYs** show up on the pools *[Image: Explore Pools in July: $60.25K TVL across 7 pools with APYs up to 58%]* A third-party founder of a Solana project comes to us and decides to **launch a new pool with his token**, QMEMO/SOL/USDC/USDT. The cool thing about this is that, again, it's organic; and also the guy realized that by deploying a pool with us, first, **his project token could be bought directly for stables**, whereas if users wanted to buy his token for USDC on other DEXes, the transactions would go through 2-hop transactions usdc->sol->qmemo. And perk number two **- he'd receive swap fees not only for direct trades of his token in the pool, but for Solana-stablecoin volume**! On Solana, the biggest volume comes precisely from the SOL-USDC pair. So by creating a multitoken pool for their project, PROJECT/SOL/USDC, projects get a constant, stable APY farm from the automatic volume that flows through the sol/usdc pair, even if their project/sol or project/usdc sits inactive! We recognized this as a Solana-native problem + solution and will later use it in the pitch deck and marketing materials. *[Image: One Hop Instead of Two: a single PROJECT·SOL·USDC pool replaces two-hop routing]* All this time development didn't stand still, and by mid-July we roll out a big update - **we relaunch the portfolio page**. It gains detailed analytics of your portfolio, plus a display of the tokens in your wallet balance and dynamic computation of IL + profit from swap fees, and many other metrics that are useful for a liquidity provider. *[Image: Relaunched portfolio page with PnL, token exposure and per-pool fees, IL and APY]* All this time we were moving full speed ahead along the strategy I had drawn up in early May. And so in July we already have a full audit underway, a product rebrand, we have volume - and I make the decision to do a small pivot and change the positioning. We're actually not a DEX, and our target audience isn't swappers. **We are a liquidity hub on Solana**, and the core of the yield is the LMMM DEX. Accordingly, the target audience gradually starts shifting from swappers to LPs. We're moving full speed ahead and on plan to roll out the contract update in August, along with the redesign, and to start targeting LPs. About the redesign, I'll say that one of its main decisions was putting the portfolio page in first place! I.e., whereas before you'd open the app and the main page was the swap page, now the main page becomes the portfolio page, and the swap page recedes into the second place. Our main volume will come to us from integration with swap aggregators, and our goal is to build a platform where LPs feel safe. And one which, of course, they use not just for the sake of it, but for the yield that LMMM delivers. In the second half of July we start preparing to raise investment into Coffer - the pre-seed round. All the money I had put into Coffer up to that point, I labeled the FFF round. Technically the project already has money and development is proceeding even without additional rounds, but I judged that accelerating the startup's growth required additional outside financing. I hired my friend **Ilyia** onto the team as an intern to help me with the business side. We started preparing the pitch deck and gathering contacts. Organizing a Google spreadsheet with lists of funds and so on. By early August we already had the pitch deck ready, the table of who we want to write to, the blurb, the tokenomics, and the data room. We redid the pitch deck about 20 times, and it went through many forms. The dumbest part was polishing slides to perfection that later deleted them. And the more feedback we got from outside people and investors, the fewer slides remained in the pitch deck (25 slides got cut down to 16). What's the takeaway? First, find someone with a lot of pitch experience, build the structure, and collect feedback. First a rough draft of the structure and an understanding of which slides are needed and in what order, and only then can you make it pretty, polish it, and design the full deck. While preparing the pitch deck I also realized how important wording is. "Liquidity hub" sounds stronger than "DEX." The yield engine of this LP hub is our LMMM model. Users get the portfolio as the main page, and the whole product boils down to providing liquidity at a good APY. This is the realization we were sorely missing at the Colosseum hackathon - probably why we lost it. Even though the software's code stays the same, we simply change the wording, the target audience, and swap the pages around. And suddenly it's a whole different story! We collected about 100 contacts in the Google spreadsheet. There were plain funds, and accelerators, and my personal connections. Toward the end of the month, after several iterations, the design studio finally hands us **the brand kit and the new logo**. The design work went on for a long time and through a fiew iterations. We arrived at a brand built on a combination of classical paintings and ASCII layout. I really love classical paintings and I really love ASCII layout :D. The logo, by the way, is already the third one. The project's first name, Cube (now Coffer), actually comes from "cubed." Back in winter of 2026, my idea was that the combination of concentrated liquidity and multitoken pools would deliver yield cubed. Of course, that's pure marketing, but the name stuck. The first versions of the logo, which I made myself, featured actual cubes. The first version was a cube with arrows, where the arrows stood for volume; the second version was the letter R sitting inside a cube. Like, yield cubed - that kind of pun in the logo. And the third version of the logo, from the designers, was chosen as the inscription ^3 in a cool font. Which means the same thing - "cubed." *[Image: Three versions of the logo: a cube with arrows, a cube with the letter R, and the ^3 mark]* The redesign kept dragging on, and so the launch of the app redesign was apparently being pushed all the way to September. Toward the end of the month I decided to launch a USDC-USDT stablecoin pool with high CF and low fees. That turned out to be a very good call for attracting volume. The multitoken stable pool is slated for launch later, after the v5 version of the smart contracts rolls out. Same with the RWA pools: there's an expectation that this will be a very good utility. An ETF builder with RWA baskets of up to 10 tokens at a time. The pool's LP token is essentially an ETF with exposure to those tokens. The last day of July treated us to incredible volumes of **600k a day**. It was awesome! ## 3.8. August: we started raising - the state of Coffer now In early August the first stage of the audit was finished, I was handed the audit report, and I went off to fix all the findings. We start raising and going around everyone whose contacts we'd gathered in advance. And we immediately run into harsh reality. Raising in a bear market is brutally hard. Even with the experience from EVAA, even with a product and users on mainnet, with volume and traction, getting through to funds is really not easy. I dug into the statistics and realized that an order of magnitude fewer early rounds are being closed in crypto right now than in years past. We started raising for Coffer literally at the worst time for a raise the market has seen since the bottom of winter 2020! Now that's bravery, right? I started studying everything there is about raising, literally starting from 101 and YouTube videos from Y Combinator. I love difficulties, and when an acquaintance of mine told me that raising right now is insanely hard, I said I actually kind of like that. I'm ready to pass through this filter that sifts out the weak. And on top of that, we're not down to our last penny in the accounts, and the raise is needed not so much for survival as for more rapid growth. By the way, even on our own resources, super-frugally, we're managing to generate over **10% week-over-week growth** across all metrics. The guys from YC say that's a "wow" metric! Right now (Mid August) we are at this point. We have **2.6M total volume** on our pools. **TVL in our pools is 95k**. And we have **2k on-chain users**. The audit has gone off for review of the final fixes. The redesign is running a bit late, but that's okay - we have plenty tasks to keep us busy. In parallel, the process of integrating into a tier-1 swap aggregator on [@solana](https://x.com/solana) has been set in motion. We're in the middle of raising the pre-seed, and by the second week of the raise we've already come to terms with reality and taken the difficulty as motivation to break through.