AC Reveals: On DeFi Stagnation, Ethereum's Crossroads, and the Art of Building in Crypto
TechFlow Selected TechFlow Selected
AC Reveals: On DeFi Stagnation, Ethereum's Crossroads, and the Art of Building in Crypto
AC, Back to DeFi: What New Insights on Web3 Development?
Navigating Web3 tides with focused insightsWritten by: The DCo Podcast
In the fast-moving and uncertain world of decentralized finance (DeFi), Andre Cronje’s name carries undeniable weight. As the mastermind behind projects like YFI, Solidly, and Fantom, and now serving as CTO of Sonic, AC has left a lasting mark on the frontier of crypto finance.
In this episode of The DCo Podcast, AC candidly reveals his views on DeFi’s development bottlenecks, the challenges facing Ethereum's ecosystem, and the harsh realities builders must face in a space where idealism coexists with profit-seeking behavior.
From navigating regulatory battles to striking a delicate balance between decentralization and user experience, his insights serve both as a warning to industry builders and an inspiration to everyone chasing the DeFi dream.
Here is the full transcript:
Navigating Regulatory Challenges in Crypto
The DCo Podcast: Welcome to the show, Andre. You're known for creating Yearn Finance, Solidly, Phantom—and now you're CTO of Sonic. The crypto space has been through a wild ride over the past few years. Can you share what the last three years have been like for you, especially the challenges you've faced and how you've dealt with them? I assume you're probably focusing more on code now rather than regulatory issues?
Andre Cronje: Thanks for having me. Honestly, I wish I could say I'm focused on code, but regulation and legal matters still take up a huge amount of my time. The past four years have been a steep learning curve. I had to deal with things like the Eminence exploit, which was a major lesson in building in public. Then with Solidly, I realized the crypto space was shifting—people no longer cared so much about true decentralization or immutability.
Beyond that, despite being a South African developer building locally, without fundraising or selling tokens, I still ended up in a battle with the SEC. They sent me countless letters and requests—it was exhausting. I learned a lot and grew from it, but it was tough. Is there anything specific you'd like to dive into, or should we keep it broad?
The DCo Podcast: I’d love to hear more about how you handled those SEC letters. Did you have legal help? How did you manage that process, especially since it sounds overwhelming at first?
Andre Cronje: At first, I was naive. The initial letters seemed simple—just information requests, with veiled threats of escalation if I didn’t comply. They asked things like, “Who did you sell the token to?” Easy answer: No one. Or, “How do you make money from the protocol?” Again, easy: I don’t.
I thought that would be the end of it. But the second letter was more detailed, and by the fifth or sixth, it was clear they understood DeFi, tokens, and how these systems work. It felt less like seeking information and more like trying to catch me making a mistake.
By the third letter, I realized I needed help. I hadn’t raised funds, so I had to rely on my network. I reached out to Gabriel from Lex Node, a prolific crypto lawyer who’s worked with many DAOs. He was amazing and provided tremendous support. Through him, I met Steven Palley, another seasoned figure in the space who really knows his stuff.
Gabe handled most of the early work, and Steven stepped in heavily later on. They were critical because it wasn’t just about what information you provide—it’s how you phrase it. You need to use specific legal language to protect yourself.
The process evolved over time. Initially, they focused on the token—did I sell it, to whom, etc. When they saw no opening there, they shifted to how I earned income from the protocol. When that failed, they argued the treasury itself was a security, citing the Howey Test—that users were providing funds to a third party expecting profits. That was frustrating because they often demanded I prove a negative—like proving Santa Claus doesn’t exist. You can’t definitively do that.
The letters stopped due to the upcoming election. About six to eight months before, I got the last one. A month ago, I received a final letter saying they wouldn’t pursue further enforcement action, which was a huge relief. But the time and energy spent were insane.
There was a stretch—three straight weeks—where I did nothing but gather data for them—sometimes data I didn’t even have, like logs from third-party custodial providers I never used. That level of consumption made it nearly impossible to do anything else.
The Evolution and Stagnation of DeFi
The DCo Podcast: That sounds incredibly intense. You mentioned decentralization earlier and implied people no longer prioritize it. Do you think there’s a tension between running a crypto project as a sustainable business and ensuring it remains decentralized? Is that why we’re seeing less focus on decentralization today?
Andre Cronje: It entirely depends on the market participants. Back when I launched Yearn, decentralization, self-custody, and immutability mattered deeply. The market then was full of tech anarchists—purists participating for ideals, not millions. That old joke, “I’m here for the tech,” was genuinely true back then, with zero irony.
But the participant base has changed. Liquidity mining, NFT mania, and now meme coins have lowered the entry barrier. You no longer need technical knowledge—just install a wallet, click a few buttons, or log in with Face ID. I think 90% of people in the market today don’t care about the tech ethos. They’re here for token appreciation or yield, not ideology.
This creates a mismatch. If you’re building foundational DeFi primitives—things others build on—they need to be immutable. You can’t let someone build a company on your primitive and then change it, breaking their system. For example, 90% of DeFi still runs on Uniswap V2 because it’s predictable and immutable. If Uniswap allowed proxy upgrades on V2 and overnight changed LP logic, DeFi would collapse.
But now, projects are more isolated. Everyone builds their own AMM or lending market instead of using third-party primitives, because those third-party systems are usually upgradeable. If you build an immutable product relying on an upgradeable system, your product might break when they upgrade. So composability and reliance on third parties are de-prioritized.
The market has shifted from building immutable, composable primitives to building companies focused on revenue or token value. It’s a snowball effect: the more projects prioritize revenue, the less immutable infrastructure is available to build on, so more follow suit. Back in 2019, I wrote that we vote with our money. Where we put our money determines what we get. In early 2021, everyone funneled money into Uniswap and Compound forks because they were “safe.”
New primitives are riskier—high chance of hacks or exploits—so innovation stalls. That’s also why meme coins are so popular now. Since 2022, DeFi innovation has flatlined. We’ve built better products, like Hyperliquid, but they’re not new primitives—just iterations of existing ones.
The DCo Podcast: You mentioned DeFi innovation has stalled and composability—building on other products—is fading. With liquidity not shared, using an asset as collateral across protocols becomes hard. Is there enough incentive to break this siloed approach, and how do we achieve it?
Andre Cronje: This might sound arrogant, but the problem is you need a rare skill set: programming ability, innovative ideas and primitives, and financial independence. That intersection is tiny. I can cite myself as an example, but it’s rare. Most builders need funding, but fundraising and building are completely different skills.
I’ve tried fundraising—it’s not my strength, so I chose to build without relying on it. Others have great ideas but struggle with pitching or networking. Meanwhile, the 99th fork of the same project raises $50 million overnight because they know the right people.
Real builders struggle to get the funding they need. Most can’t afford six months without income to pay bills. Hyperliquid is an exception—they didn’t raise funds because their team previously ran a successful market-making business, giving them resources to build and even run large airdrops.
But if you raise funds, you face VC pressure. VCs care about ROI, not your vision. It’s their fiduciary duty, but it misaligns incentives.
Historically, in traditional finance or Web 1/Web 2, companies built stable businesses and spun off small R&D teams to test new ideas. We see some of that in crypto—like Aave launching GHO, Lens, or Family—but not enough. The social and reputational risk is too high. If a sub-product gets exploited—even for $50—the headline says the main project was hacked. The risk-reward ratio is absurd.
So it’s a hard puzzle, with no short-term solution. Most developers brave enough to try are already borderline masochistic—dealing with exploits and reputation damage takes a certain mindset.
The DCo Podcast: Let’s revisit DeFi primitives. You mentioned you’re working on new ones. Where is DeFi in terms of its foundational building blocks, and what immediate primitives can we build to move forward?
Andre Cronje: DeFi is still in its infancy. Even basic primitives like automated market makers (AMMs) aren’t mature. We’re stuck on constant product formulas like X*Y=K. Curve introduced stable swaps, and I brought in X3Y via Solidly, but innovation halted there.
With faster blockchains, dynamic liquidity market makers (DLMMs) are emerging—that’s progress. AMMs still have much room to grow—new curves, trading methods, liquidity provision strategies.
The next big leap is on-chain oracles. DeFi avoids them due to exploit fears, but we can implement them securely. Without oracles, we lack key data—volatility, implied volatility, order book depth. Once we have robust on-chain oracles, we can build proper pricing models, Black-Scholes calculators, European or American options. That unlocks on-chain perpetuals and delta-neutral strategies—currently impossible.
Look at traditional finance: futures and options dominate, yet they’re almost absent on-chain. The roadmap is clear—you need data first—but everyone’s afraid to build it. You can go fully on-chain with strong security, or use off-chain oracles with ZK proofs or decentralized approaches to avoid trusted intermediaries.
Beyond that, insurance primitives are missing. DeFi has vast uncharted territory. It’s still early. If we overcome fear of innovation, the potential is enormous.
Reconciling Decentralization and User Experience
The DCo Podcast: Do you believe user experience (UX) and decentralization are fundamentally at odds? Is that part of the problem?
Andre Cronje: Absolutely, 100%. True decentralization means no website, no third-party browser—just downloading node software, running a local node, and submitting transactions via CLI to interact with immutable smart contracts. That requires deep technical knowledge—syncing software, using 64-character hash-encoded transactions, not just calling JSON RPC. Globally, maybe 10,000 people can do it, perhaps fewer.
On the other hand, great UX means no private keys, no gas fees. Look at successful Solana apps: download a mobile app, log in with Google or Face ID, click a button. That’s far from decentralized—it’s something entirely different.
Today’s successful apps hide more from users—like managing private keys on their behalf. Hyperliquid is great, but once you deposit, it’s no longer decentralized. Your funds sit in wallets they control, with keys on their servers. Great UX, but centralized.
My approach is to first build for decentralization ideals—raw on-chain contracts that CLI users can interact with from their own nodes. Then I add abstraction layers: an API that simplifies actions, passkeys to eliminate wallet use, or gas fee abstraction. Eventually, you get a UI where users just click a button, and the backend converts that into a signed transaction via API and a signing wallet.
This is the “right” way, but for the tiny group using CLI, it adds infrastructure that may seem pointless. Decentralization and UX are like security and UX—true security needs complex passwords, isolated systems, key rotation, but users won’t do that for a free mobile game. Historically, when security clashes with usability, usability wins. Decentralization will be no different.
The goal is for users not to know they’re using blockchain—no wallet, no gas. Right now, this is achieved through centralized workarounds like APIs or backend servers. But I believe we can make these features first-class citizens of the blockchain, so users get great UX without trusting third parties.
We’re manually doing this now via centralized solutions, but we’ll codify them into decentralized systems. It’s like when I first started programming: manual steps first, then automation. We just need time.
The DCo Podcast: Two follow-ups: First, how do we reach that decentralized yet user-friendly future? Second, if decentralization and UX conflict, at what point do you compromise decentralization for better UX?
Andre Cronje: Let me answer the second question first. The line depends on user tolerance, which varies by application. For a free mobile game, users expect zero friction—download and play. If it requires username, password, or social login, they won’t bother because perceived value is low.
But for a banking app holding $100,000, users accept two-factor authentication or extra steps because the stakes are high. Every app must find that balance based on the psychological value users assign.
Currently, crypto apps offer little choice. Whether games or DeFi protocols, users must download wallets, secure keys, fund gas, sign messages—a high barrier. We saw similar patterns in mid-2010s cybersecurity: websites demanding 32-character signed passwords, but users forgot them, reset became a hassle. Eventually, apps let users choose their security level while adding backend protections. Crypto will evolve similarly.
For the first question—how do we get there—we need builders willing to execute. Ethereum has long been the leader, and their research, like Ethereum Improvement Proposals (EIPs), maps out the next five years. Features like operation bundling and account abstraction are steps in the right direction, but they’re not first-class yet—you need third-party infrastructure or deep knowledge to use them.
The upcoming PCRA upgrade will make them native, which is crucial. The roadmap exists; execution is key. But few teams are willing or able. Ideas are cheap—execution is everything. I believe we’ll see major improvements this year, like full on-chain gas and account abstraction, meaning no wallet or gas needed. It’s a massive UX leap—users won’t need to know which blockchain they’re on or use MetaMask. It’s coming, likely this year or next, but the path is clear.
Ethereum’s Challenges and Advice for Builders
The DCo Podcast: You mentioned Ethereum. What’s your view on its current state? There’s criticism that it lacks direction, focus in implementation, or that scaling solely via Layer 2s (L2s) is fragmenting everything.
Andre Cronje: I’ve been outspoken: L2s are a waste of time and energy. The resources and capital poured into them are part of the misalignment I mentioned earlier—we vote with our money. When only forks of known apps get funded, that’s all we see. Now, L2s are absorbing capital, but while claiming alignment with Ethereum, they’re becoming more centralized.
My issue isn’t that L2s exist—I believe they’ll eventually be necessary for scaling. But Ethereum is nowhere near its scalability limits. It might be using only 2% of its maximum capacity. There’s plenty of room on the base layer. Blockchains like Sonic, Avalanche, and Solana show high throughput is possible on base layers without L2s. Focusing on L2s is premature and fragments the ecosystem, hurting composability and UX.
L2s were supposed to be composable and interoperable, but they’ve become a pile of sidechains with centralized sequencers extracting fees for profit. That wasn’t the original vision. The bigger question is why. Ethereum went through a typical corporate lifecycle: initially agile, rapid R&D, fast building, constant iteration. As it gained attention and grew, it became cautious—adding compliance, oversight, testing, committees, boards.
This bureaucracy slowed it down. It’s now stagnant—too big to move quickly. Companies at this stage either shed excess and refocus on core tech, or get overtaken by faster rivals. Ethereum is at that crossroads. We see internal turbulence—CEO changes, board reshuffles, Vitalik trying to speak up. I hope they refocus, because I’m loyal to Ethereum; it’s why I entered DeFi. But we can’t wait for them to fix it.
Their research, like EIPs, still sets the standard for the next two to five years—especially around UX, account abstraction, and on-chain oracles. But most of that was written between 2018 and 2020. The ideas are there; implementation lags. On scalability, Ethereum’s base layer uses just 2% of capacity. Huge growth potential remains, even without L2s.
My work at Phantom (now Sonic) proves this. When Ethereum used Proof-of-Work, we saw it limited throughput by setting block time caps. We redesigned the consensus mechanism using an asynchronous Byzantine Fault Tolerant (BFT) system, achieving 50,000–60,000 TPS. But the Ethereum Virtual Machine (EVM) became the bottleneck, capping us at 200 TPS.
We analyzed the EVM and found obvious improvement points. The biggest issue was the database—LevelDB, PebbleDB—spending most time on read/write ops. These databases are overkill for blockchains, designed for general queries, not the simple address-nonce-data structure of EVM. We built SonicDB, a flat-file database tailored for blockchains, boosting EVM throughput eightfold and reducing storage needs by 98%. Ethereum could implement this tomorrow and gain massive benefits.
We made other tweaks—new compilers, supersets—but the database was the low-hanging fruit. Why haven’t they done it? Because they’re risk-averse. Their tech secures tens of billions in assets—any change feels terrifying. The trade-off is losing SQL query capability, but in reality, no one uses SQL queries on massive blockchain datasets—tools like Dune or Tenderly process transactions separately. It’s not a real loss, but Ethereum’s resistance to change is so strong that even low-risk upgrades get shelved.
The DCo Podcast: You mentioned ideas like on-chain credit scoring—we can dive deeper next time. But finally, what’s your most important advice for new builders entering the space?
Andre Cronje: My advice has evolved. Honestly, building in crypto isn’t the smartest choice—other fields are simpler, more stable, and less damaging. But if you decide to do it, go all-in publicly. Share your work on Twitter, open-source your GitHub, let people see and test your code. Build a community of contributors, not just exploit hunters.
If an exploit is going to happen, better it’s early—when risk is $50, not $50 million later. Build social proof, communicate what you’re doing and how, invite testing—hopefully white hats, not black hats. Small bugs can be recovered from; big ones cannot.
If you can get funding, prioritize security. Work with teams like TRM, Chainalysis, or Seal Team 6 for audits and red-teaming. Audits from firms like SlowMist are essential. Learn early how to handle security disclosures and emergencies.
This space isn’t for everyone—some leave after their first crisis because the pressure is too much. Building in public is a litmus test: you’ll quickly learn if you belong. Embrace it—you’ll either find your place or realize it’s not for you.
The DCo Podcast: Thank you for your time, Andre. Really enjoyed this conversation—hope we can do another soon.
Andre Cronje: Absolute honor. Just say the word, and we’ll do it again.
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
