Andre Cronje Interview: 99% of Projects Are Garbage, but There's Still 1% with Real Value
TechFlow Selected TechFlow Selected
Andre Cronje Interview: 99% of Projects Are Garbage, but There's Still 1% with Real Value
"If you think a single blockchain project can solve global financial problems, that's absolutely insane."
Navigating Web3 tides with focused insightsGuest: Andre Cronje
Translation: loxia.eth
This is a comprehensive interview with Andre Cronje, lasting approximately 1 hour and 20 minutes.
It includes Andre Cronje's reflections on his past career, along with many insights, practical advice, and personal ideological perspectives.
As an OG figure across multiple sectors in the industry, this is the most recent and in-depth long-form interview with Andre Cronje—worth reading and referencing.
The article is around 20,000 characters long and divided into nine sections.
Andre Cronje believes it’s foolish to view any blockchain project as an “Ethereum killer.” Even if you sum up the total value locked (TVL) of all blockchain networks—including Bitcoin and Ethereum—they still represent a negligible fraction of the global financial system. If you think one blockchain alone can solve the world’s financial problems, that’s simply insane.
1. Introduction
Host 1: Hello everyone, welcome to the Bright Talks show! Today we have the privilege of hosting Andre Cronje, founder of Yearn Finance, Phantom, and Keeper Network, and a key contributor to many DeFi projects. Andre, welcome to our program!
Andre Cronje: Thank you. Uh, that introduction was a bit exaggerated—I’m just someone who likes writing code.
Host 1: When I listened to the “Uncommon Core” podcast back in 2020, they described you as a builder. I’m not actually a developer myself—more of an integrator—but I think you’re underselling yourself. You have a very interesting story from which we can all learn. Maybe we can start from 2017, when you first entered the space during the ICO era. It would be great to hear how you got involved, and also help explain to those who weren’t around then just how wild that period was.
2. The ICO Era: Andre’s Cryptocurrency Journey
Andre Cronje: Yes, before I got into crypto, I was a very traditional skeptic. I came from a conventional finance background—I was an architect and CTO at a small financial firm. We worked on high-throughput systems using Kafka and Scala. That’s my background in high-throughput financial solutions.
The 2017 era was very similar to now in many ways—there was so much noise, so many teams claiming to solve industry-wide problems that traditional finance and distributed systems had struggled with for decades. Yet 18- to 20-year-olds with no experience would launch an ICO, raise $20M or $40M, and claim they’d solved distributed systems or something else entirely.
So I initially entered the space to test my skepticism—to make sure I wasn’t missing out on some disruptive technology replacing the old. My concern was that the blockchain field lacked rigorous research and strong evidence despite countless bold claims. So I started reading whitepapers. Theoretically, many proofs seemed sound, but there was another issue—one that persists today—which is that even ideas that sound convincing on paper often hit hard constraints when implemented, preventing them from working as expected.
Even if the theory is correct—or even if the concept seems right—it might still not be feasible. After reading many whitepapers, I began looking at code and doing my own code reviews. I wasn’t doing these reviews from an investment due diligence perspective; it was more like: I read the whitepaper saying it solves problem X, so I go check the code to see if it actually does. It was mostly a personal exercise.
When I wrote about these processes on Medium, I’d just say things like, "This code doesn’t match what they’re claiming here," or "This codebase has nothing to do with their statements." For some reason, I made these public, and during the ICO era, they became very popular because there were few critics saying, "This won’t work because your code proves you don’t have what you claim." But then a problem arose—one of the main reasons I eventually stopped doing code reviews—was that people started treating them as investment signals rather than educational tools. I shared them so others could follow the same learning journey I was on.
Eventually, I partnered with a company called Crypt Briefing, working with Hana, John, and others—they’re still great, and I stay in touch with them today—doing formal reviews for them. But over time, things shifted uncomfortably. I preferred reviewing open-source code—if it’s on GitHub, I can see it, and so can everyone else, allowing verification or correction of my findings.
But as my influence grew, more teams wanted us to review their private code and publish results, which made me uncomfortable—it felt purely like providing investment signals. Anyway, that’s a tangent—we can discuss it later. Going through all this, I found that 99.9% was junk, but that remaining 1% with real value kept haunting and attracting me.
Looking back, my focus shifted from trying to understand what was happening to catching up with the industry. I think I managed this over about two years—around 2019, maybe late 2018. Catching up in this field is hard—so much new stuff emerges daily. You have to sift through 98% of garbage just to find the 1–2% of actual developments.
At that point, I started focusing on one thing: POW (Proof-of-Work) was clearly a bottleneck. Looking at blockchain systems, transaction speeds were obviously constrained. Bitcoin’s longest-chain rule meant transactions took 10–30 minutes. Before that, I was fascinated by cross-border payments, settlements, and instant online payments.
I’m South African. South Africa isn’t part of SWIFT or IBAN—we face foreign exchange controls and limitations on online spending. Our banking system is highly restrictive, always a challenge. Seeing a system free from single-entity control really attracted me—it aligned with my background.
So I started diving into consensus research. That work and code review led me to Fantom and their team, and I got more involved. They raised about $40 million in ETH during a market frenzy. Notably, they held onto all that ETH—even during the bear market—and only sold when ETH hit around $300. They made big promises that sounded good but couldn’t deliver. They seemed to realize this but didn’t proactively exit—like spending the money or doing something to burn it off. Eventually, they asked if they could use my research, which I’d been publishing. I’d been considering launching my own chain anyway. This fit well since I had zero experience interacting with VCs, fundraising, or anything like that. That’s not my skillset—it’s a skill I lack.
That’s why I’ve never launched anything—with VC funding or otherwise. Whether Yearn, Keeper, or anything else I’ve done—no VC involvement. Many assume this is some moral stance on work ethic, but it’s not. I’m just bad at it. I figured out ways to work around it—that’s all.
In the end, they had funds and a branded team, so I contributed my research. The first component was consensus—the original ABFT (Asynchronous Byzantine Fault Tolerant), which they called Lachesis. But it was essentially based on a 1990s paper, “Common Concurrent Knowledge,” just a P2P ABFT communication system. We launched at the end of 2019 or early 2020. The consensus itself was great—one of the first ABFT solutions—jumping from max 7 TPS to easily achieving 30,000–50,000 pure payment transactions per second depending on validator connectivity and network participation—before connecting a VM, since it was just a pure payment network.
But we wanted to enable a virtual machine because smart contracts are powerful. At the time, EVM was our only viable choice. We considered Wasm, risk-based compilers, etc., but even now, to make a blockchain truly usable, you need many service providers built on top. Building everything from scratch—wallets, RPC node providers, instant deployment—is extremely hard. Everyone said, “We’re just forking EVM,” so we stuck with EVM and connected our consensus as the base layer. Consensus is just a sequencing system—it receives transactions, orders them, and passes them to the VM for execution and state changes.
Then we noticed our TPS dropped to between 180 and 200—purely limited by the EVM. The next three years were spent solely trying to improve the EVM. We made some progress, but honestly, if I could go back and change that decision, I would.
We chose the easiest path at the time—going with EVM—because integration with third-party providers would be easier. It was a positive choice—we couldn’t build our own wallets, RPC providers, etc.—but again, this is something we can dive deeper into later.
3. Building Yearn Finance
Andre Cronje: Earlier, I mentioned they raised $40 million and kept it all in ETH. But when they finally converted to USD, only about $2.5 million remained. That was our entire team’s operating budget. To manage this, I started researching existing lending protocols like Compound, BZX, Fulcrum, etc. Aside from Compound, all others are gone now. Back then, Ethereum gas fees were just 3–6 cents, so frequent operations were possible. Every morning, I’d check which protocol offered the highest APY and manually move funds between them. Over time, I realized this daily routine was tedious. There should be on-chain smart contracts showing interest rates, so I could collect and display all data in one place.
My first smart contract on Ethereum was just an APY aggregator—pulling data from various sources and displaying it. I did this because I couldn’t figure out RPC infrastructure like Web3.js to fetch data from nodes and act on it. Deploying directly on-chain and reading from there was easier for me.
That’s how I began my Solidity development journey. With this contract, at least I could check each morning which rate was highest and move funds accordingly. Then I thought—hey, I could write a smart contract to automate this process. That’s how Yearn started. Later, it became far more sophisticated—modern Yearn is rocket science compared to my original code. But that was the origin: automating my manual daily operations to manage my funds. Eventually, I opened it up so others could use the same system. I no longer needed to click buttons every morning to rebalance funds across protocols—any deposit or withdrawal would trigger automatic rebalancing. This fully automated the process. That’s the birth of Yearn.
However, as Yearn evolved, the token launch didn’t go as planned. The distribution wasn’t fair. I was mocking worthless tokens—joking that I’d give away garbage for free if you provided liquidity. In my mind, that seemed the dumbest thing possible, but clearly, I was wrong. Still, it attracted massive attention. People joined, things got complicated—strategic investments, infrastructure, etc.
As strategies deepened, we spent a lot of effort on yield harvesting—like dumping tokens from any protocol. That became its own thing. I used to run scripts manually for this. I thought—surely there’s a way to do this publicly, where anyone can call it and be incentivized to do so. That’s how tasks and keepers emerged. Eventually, this evolved into the keeper network, which worked well for Yearn. We decided to open it up—anyone could register a task, and keepers would execute it. I didn’t know who these keepers were, but they’d do the job. My first on-chain task was fascinating—we didn’t advertise it, didn’t post anything. We just activated it, and bots immediately started calling it. Watching things happen autonomously on-chain was chaotic—this was probably what people once called the “dark forest,” now perhaps just the MEV forest.
4. Mistakes and Testing in Production
Andre Cronje: Then came many... let’s say, missteps. Before Yearn, people in the space noticed me, but I had no public reputation or visibility, so I developed poor coding habits. For example, I often tested in production—deploying experimental code to live systems. I actually did this. Another issue was the complete disconnect between intent and execution. Mixing testing and production is extremely risky. It’s like warning others: “Hey, I’m testing in production—if you interact, don’t expect safety, things could break badly.” I said this to warn users—interacting here carries extreme risk.
Testing in production eventually turned into a careless, reckless capital deployment practice—though that wasn’t my intention. I was still using old development practices while building Eminence. At the time, I was deeply frustrated with NFT culture—now somewhat improved, but then people used NFTs absurdly—turning a painting into an NFT and selling it for $100K. I love the idea of NFTs—I’m a hardcore gamer. They’re perfect for gaming. So I licensed the IP for Eminence from another game studio. We planned to build silly games to demonstrate how NFTs work. I’ve always believed NFT IP will be problematic if confined to a single game. The whole idea was creating multiple games sharing the same foundational layer.
Anyway, I deployed several tests, people interacted, a major bug occurred, and about $60M was lost. I stepped back significantly—realizing just how dangerous this space is, how quickly things can go wrong without proper safeguards. Meanwhile, due to Yearn, I faced intense regulatory scrutiny—authorities classified it as a financial instrument, which I agree with, but I also wanted distance. Eventually, I returned firmly because one thing haunted me: improving AMM curves. Back then, there was only one standard stableswap curve—Curve Finance, created by Michael Egorov. He’s absolutely brilliant—a genius developer, founder, architect. Probably still one of the smartest people I know in this space. But I obsessed over creating something as simple as Uniswap’s x*y=k. I ended up designing x³y + y³x, which worked excellently—you could define the curve, and it was elegant.
At the same time, I added a bunch of features. Back then, you had TWAP (Time-Weighted Average Price). I introduced RWAP (Reserve-Weighted Average Price). Because regarding how XY pools work, I don’t even need to explain—just know that TWAP uses fixed time price points, completely ignoring liquidity volume. It says, “You can sell a billion of this at this fixed price,” which is a huge problem for me.
Note: Time-weighted average price (TWAP) and reserve-weighted average price (RWAP) algorithms use different methods to calculate asset prices, forming the foundation of nearly all DeFi primitives.
Many liquidation bots, engines, lending platforms, even fully decentralized stablecoins need slippage to be part of calculations. Take a liquidation bot: it checks if it can repay someone’s debt, seize their 1M ETH collateral, sell it on Uniswap, and still profit. Using TWAP, the bot says, “Profit looks good—execute.” But if actual slippage is high after selling, it loses money. So I needed a method factoring in liquidity to accurately assess feasibility. And it had to be time-weighted so I knew no large flash loans were flooding liquidity. I could sell, but simultaneously, this creates frontrunning opportunities against my bot.
So I had to go back, verify everything, and build that mechanism. Launching on Fantom caused chaos because I left within a week or two. But aside from Fantom, I always felt this was what founders of fully decentralized protocols should do. If your protocol is immutable—no updates, no changes—you should step away because you shouldn’t be the central figure tied to it. I think Yearn and Keeper handled this well—they’re managed decentrally. With both, you can’t pinpoint a single owner. Though Fantom was definitely a mess. Still, it became one of the primary AMMs for new VM exchanges like Velodrome, Aerodrome, and many others I don’t even know.
So it achieved what I wanted, though not through my iterations. After that, I decided my days of coding and smart contracts were over—I lacked the necessary infrastructure. So I went full-time back to Fantom. Sorry for this long history—I’ve taken up quite some time already.
5. Fantom L1: Making Software as Efficient as Possible
Andre Cronje: I believe databases definitely have their place. I think FVM is currently the gold standard—nothing better exists today. From a data structure perspective, here’s what happened: Initially, we used Badger, then researched various databases and switched to Pebble, giving us a nice throughput boost—not revolutionary. All existing databases are designed for general-purpose data storage, capable of storing anything in any format. Meanwhile, using SQL on top means the backend does a lot—building indexes, P-trees, etc.—adding significant overhead.
So even switching to key-indexed storage—say, for EVM or VM-based data, or specifically, data for smart contract X—seems more rational and does improve throughput. But again, supporting query languages like GraphQL, SQL, or others requires substantial backend work. When we moved from standard database structures to Pebble, then to key-value stores, throughput increased significantly. Now we simply use flat files on disk—no complex structures.
Our lookup pattern is very simple. Like any smart contract, it has an address—the first part of the index. The rest is which storage slot holds the data—basically positions one through six. So if I look up, say, the first entry—smart contract name—it’s literally address one. I have it. No extra steps. No need for complex languages. Honestly, this now effectively solves the EVM limitation, since EVM’s MPT data structure—used with existing indexing—is extremely data-intensive.
You have leaf nodes with actual data, then composites of composites, until reaching the root—requiring heavy computation, mostly hashing. Every read/write becomes extremely intensive. For our VM, just optimizing Carmen—the data store—increased capacity peaks by 8.2x, adding 820 throughput. Many other incremental changes too, but that alone was massive.
One thing I constantly advocate: Many blockchain teams accept current limitations as fixed physical laws. Ask a Bitcoiner, and they’ll say POW is the fastest consensus. I interrupted you—sorry, I’ll stop.
Host 2: Actually, this aligns perfectly with Solana’s worldview. Look at Kevin Bowers, the new Fire Dancer client lead—his entire focus is making software as efficient as possible. As you said, strange abstractions cause odd performance issues that compound. They even optimize hash algorithms. Your point suggests huge gains come from vertical scaling and optimizing software to leverage physics. Only then add complexity. I won’t rant further, but could you briefly explain how Fantom works at a high level—for those less familiar? Highlight key differences and advantages?
Andre Cronje: Our initial priority was consensus. Back then, PoW was dominant. Though it’s just an analogy, I dislike calling blockchains like Fantom PoS. PoS is merely an anti-fraud mechanism, not consensus. PoW combines both. The core idea of consensus is shared synchronized knowledge—everyone agrees on an event and knows others know it too.
For example, suppose I’m wearing headphones. I tell you I’m wearing them—proof. Now you know, and I know you know. You tell Garrett: “Andre’s wearing headphones.” Andre confirms to me he’s wearing them. Now Garrett knows I know, and you know Garrett knows I know. Though I don’t yet know Garrett knows, via third-party confirmation, consensus is reached—every participant knows the event. That’s Fantom’s consensus. Validators constantly communicate—sending pings to check presence, sharing transactions known only to them—to maintain synchronization. Communication is continuous. We exploit P2P messaging to achieve consensus by sharing messages and shared knowledge of messages.
Message propagation in our network spreads like a virus—slow at first (1 to 2 nodes), but exponentially accelerating across the network. We use a DAG (Directed Acyclic Graph) structure—no traditional blocks—consensus formed purely through communication. We divide time into Epochs. When 2/3 of the network agrees, a new Epoch begins. This means we heavily rely on P2P communication—we’re actively improving and optimizing it for faster information spread and consensus.
Information propagation is critical in blockchains. Like me telling you something, you telling others, spreading wider. As more people know, like on Fantom, the message eventually reaches enough participants to form a chain. For EVM smart contracts, we introduced Epochs. When 2/3 of the network knows something, we call it an Epoch. Sounds odd, but it just means majority consensus. Then the Epoch acts like a block—passed to EVM for processing. Technically, we don’t have real blocks—communication is continuous, consensus forms continuously.
This makes us highly dependent on network topology. We’ve identified many areas in the P2P layer—our next focus. Communication is crucial—even globally, latency isn’t a major issue. Especially with broadcast protocols—not one-to-one, but sending to everyone I know. Slightly slower per hop, but information spreads very fast overall.
Now, consensus layer. Initially, just simple transfers—wallet to wallet—no frills, no VM. Then we wanted VMs, so we introduced Epochs. Two separate components cooperating—VM handles state processing and updates. Despite optimizations, throughput remains limited. Raw transaction network peak was 50k–180k TPS, hardware and network-bound. Our goal was testing true limits—we can scale further via hardware and tech.
Our research now focuses on VMs, especially consensus. We received peer review, with great help from Sydney University and Professor Bernard Schultz—a pioneer in programming languages and VMs. He brought amazing ideas and a full team. Kman and TSA are his creations. I can keep up, but I don’t own them. Let me briefly explain: TSA is a new VM. We have DApp developers and an ecosystem—we must consider them. Choices: restart from scratch—abandoning all prior work, devs, community—or compromise. We chose bytecode-level compatibility. Previous code runs unchanged on the new system. Even if forked, deployed contracts keep working. This remains internally debated, but we believe a decision must be made to reduce technical costs. Currently, TSA VM is EVM bytecode-compatible—no need to recompile Solidity, etc., though you can. Recompilation enables optimizations via new interpreters from high-level languages like Solidity and Viper. Not yet applied, but migration is ongoing.
In blockchains, opcodes (machine instructions) affect performance. EVM uses 8-bit opcodes; we use 16-bit. Might seem minor, but executing 50 million transactions, an 8-bit interpreter takes ~40 hours, while 16-bit takes ~27—30% performance gain. Many factors affect system performance, but this is significant.
In blockchain, distributed systems, VM research exists, but many ignore it—believing they can reinvent independently. We apply proven techniques to improve our system. That’s why we adopted 16-bit opcodes.
Let’s briefly explain opcodes. In traditional EVM, basic math like (a + b) * c requires multiple steps: first a + b, then multiply by c. But super instructions observe such patterns dominate (>95%). Why not merge them into one super operation? Reduces execution steps, boosts efficiency.
A super instruction set merges two operations—instead of separate a + b, default to add-multiply. Normally, you read, modify, write target, then execute second op. With super instructions, operations halve. Especially in current VMs—DeFi, NFT ops like ERC transfers—appear standard but involve multiple steps: read balance, check sufficiency, subtract amount, update recipient, verify consistency, commit.
Imagine how often these execute on-chain—many opcodes. A “super instruction” mechanism simplifies this. Note: Not a new concept—research from decades ago. Never applied in blockchain VMs—until now. Progress.
We spent much time on parallel execution—intuitive concept. If I send USDC to G, M buying an NFT shouldn’t wait for my transaction to finalize before committing to the same state. Usually, many interactions in a block are highly correlated. During high activity, same state sees multiple interactions—lots of pre/post activity.
After many optimizations and parallelization, we discovered CL (Clairvoyance)—an enhancement. Simply, brute-force sorting all transactions in the first 50 million blocks, then reordering to find optimal state-write sequence. We achieved Optimum Clairvoyance—30% performance gain. Nice improvement. But other areas saw 800%, 400% gains, making CL less critical.
Next major upgrade came after VM acceleration. We built Substrate—a simulation environment enabling rapid iteration. Like a container to test small changes and instantly see impact. Without it, testing changes is hard. We spent ages building systems only to find they failed—happened multiple times. Substrate was our first tool. We plan to open-source it—compatible with any EVM network—useful for other blockchain teams.
We use it daily to test theories and incremental changes. Tiny code tweaks, rapid execution—test large datasets in hours, not days. Part of this is our profiler—shows where we spend most execution time. After introducing VM-level improvements—opcodes, super opcodes—we added hot caching. Frequently accessed states stay cached—direct access, no reads. Basic web dev principle—even 50 years ago—but oddly underutilized. Also hash caching—we avoid recalculating hashes consuming resources. Many hashes—state tree roots—change frequently during transaction validation.
But next biggest bottleneck was disk—the database. Tracked all read/writes—many background, invisible, like index building. Moved from Badger to Pebble to final key-value store—Carmen. Has two main components—new schema sets. I’ll simplify—happy to dive deeper, but keeping high-level now.
Involves addresses and address spaces—basic lookup method for smart contract data. Second feature: real-time pruning—especially useful for Fantom. Since Fantom uses ABFT, it doesn’t need longest-chain rule. Once 2/3 confirm, you can truncate prior records—you care only about final state. Historical data can be archived, like Proof of History. No longest chain needed—you have true finality.
Long-debated topic—risks exist. Suppose someone has a secret quantum lab, cracks cryptographic hashes instantly, creates a new Bitcoin chain, submits it. Unlikely for Ethereum-like systems, but possible for Bitcoin. They could create a new longest chain: “Hey, this is the new chain—we own everything now, thanks.”
Assuming probabilistic finality carries risk. By now, so many blocks and work exist that changing it is near impossible—even Bitcoin can’t reverse easily. They could stage—all validators sign: “We agree this is our new state,” then operate forward—only that portion affected. But possibility exists—scary, unlikely in next 50 years.
Real-time pruning keeps disk usage low. In any longest-chain system, state bloat is huge. Solve it early—before economic activity explodes, state grows rapidly. Validators suffer—forced upgrades. State size remains a key concern.
With real-time pruning—even without—it reduces flat storage and address-index lookups. On our Sonic chain, disk storage decreased 98%. No more background indexing, lookups, or database overhead. Crucial—as activity rises, hardware demands rise. Constant trade-off—scaling specs vs. reducing requirements—unavoidable cycle. Web2, traditional finance—repeat every six months.
Overall, Carmen’s new data store solved our main bottleneck—~8x throughput. Current focus: P2P layer and transaction mempool—standard optimization engineering. Traditional approach—profile stack, find biggest bottlenecks, fix, re-profile—repeat until micro-optimizations drive you mad.
6. Ethereum’s Scaling Path
Host 2: You said something interesting—I’d like to transition with it. You mentioned skepticism toward parallel execution—since so much in blockchains is interdependent—whereas SUI or MOVE take optimistic parallel approaches. We don’t know real-world performance yet, but let’s pivot—being a pioneer in crypto, especially Ethereum—what’s your take on Ethereum’s new scaling methods?
Andre Cronje: Ethereum hasn’t really acted on scaling—they’re scared. Past attempts failed. I don’t fully agree—I often think about this, like Fantom. Our economic activity is modest, value low, yet every deployment or change makes me nervous—even for Sonic, tested repeatedly. One opcode or bytecode error can cause massive losses. After Eminence, I’m even more cautious—smallest overlooked detail can be catastrophic.
Due to fear of financial loss, I respect Ethereum’s choice. Transitioning to proof-of-stake was a historic moment—a huge success for Ethereum and all involved—my congratulations. But in any company, I’ve seen this: when you’re new, you take risks, break barriers. As reputation and value grow, you become risk-averse. Ethereum now takes a conservative path—focusing on L2s. People forget Lightning Network was Bitcoin’s first L2—but almost no one uses it. Might be correct, but shows complacency—low demand for improvement. Historically, whenever a new competitor emerges—willing to take risks, surpass predecessors—this happens. Ethereum did this to Bitcoin. I think next-gen L1s are doing the same to Ethereum. Calling anything an “Ethereum killer” is stupid. Our collective TVL—Bitcoin, Ethereum, Solana, etc.—merged, is trivial in global finance. Thinking this is the limit of global financial solutions—such tribalism is insane.
Anyway, I say this because sometimes you don’t use Ethereum to buy coffee at Starbucks. It’s more for portfolios, or old banks updating once a year. For these, Ethereum is perfect—built on security budget, etc. Slightly joking, but that’s why it exists. Like, you wouldn’t use Bitcoin to pay someone—almost no one does. I remember my first salary paid in Bitcoin—it was the main payment network then. Now, waiting an hour to receive Bitcoin feels unthinkable. I’d rather use Ethereum.
7. Fantom’s Market Strategy
Host 1: Andre, I have a question linking to much of our discussion—it’s about Fantom’s marketing, but to discuss it properly, I want to go back to Curve. When you were at Curve, you did that so-called fair launch—founders took no tokens—creating a cult-like following. Someone even wrote an ebook “The Blue Pill” portraying you almost as a god. I know you’ve talked about this—you said “code and prod,” then the cult formed, making your work difficult—everything scrutinized. Then you suddenly left Yearn—price crashed overnight. Later, you brought Fantom—Fantom surged, I think in 2022—then you left again.
You wrote a blog explaining leaving DeFi—due to toxic culture. Many blamed you—“you rug-pulled us”—though you were just one contributor. Token dropped 50%—despite
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@LXDAO_Official
