AC Reveals: DeFi’s Stagnation, Ethereum’s Crossroads

In the ever-changing and uncertain field of decentralized finance (DeFi), Andre Cronje's name is undoubtedly important. As the driving force behind multiple projects such as YFI, Solidly, and Fantom, and now leading the development of Sonic as CTO, AC has left a deep mark on the forefront of crypto finance.

In this episode of The DCo Podcast, AC candidly reveals his views on the bottlenecks of DeFi development, the challenges facing the Ethereum ecosystem, and the cruel reality that builders must face in this field where idealism and profit-seeking coexist.

From the game with regulators to the delicate balance between decentralization and user experience, his insights are both a wake-up call for industry builders and an inspiration to all those who dream of DeFi.

The following is the text:

 01 Addressing the Regulatory Challenges of Crypto Assets

The DCo Podcast:Welcome to the show, Andre. You are known for founding Yearn Finance, Solidly, Phantom, and now you are the CTO of Sonic. The crypto space has been through a crazy journey over the past few years. Can you share what the past three years have been like for you, especially the challenges you faced and how you dealt with them? I guess you should focus more on code now rather than dealing with regulatory issues.

Andre Cronje:Thanks for having me. To be honest, I wish I could say I was focused on code, but regulatory and legal issues still take up a lot of my time. The last four years have been a steep learning curve. I had to deal with things like the Eminence vulnerability, which was an important lesson about building in the open. Then with the Solidly project, I realized that the crypto space was shifting — people didn’t care that much about true decentralization or immutability anymore.

On top of that, I fought the SEC despite being a South African who developed locally in South Africa, didn’t raise money from anyone, and didn’t sell tokens. They sent me a lot of letters and requests, and it was exhausting. I learned a lot and grew a lot from it, but it was hard. Do you have a specific topic you want to go into more, 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 navigate the process, especially since it sounds so overwhelming at first?

Andre Cronje:At first, I was naive. The initial letters seemed simple enough—just requests for information, with implicit threats of escalation if I didn’t cooperate. They asked questions like, “Who did you sell your tokens to?” The answer was simple: I didn’t sell them to anyone. Or, “How do you make money from the protocol?” Just as simple: I didn’t.

I thought that was the end of it. But the second letter was more detailed, and by the fifth or sixth, it was clear that they understood DeFi, tokens, and how these systems work. It felt like they were trying to catch me making a mistake rather than actually seeking information.

By the third letter, I realized I needed help. I hadn’t raised money, so I had to rely on my connections. I reached out to Gabriel at Lex Node, a prolific crypto lawyer who had worked with many DAOs. He was fantastic and provided a lot of support. Through him, I met Steven Palley, another veteran in the space who really knows his stuff.

Gabe did the bulk of the work early on, and Steven got heavily involved later on. They were critical because it’s not just about the information you provide — it’s how you say it. There’s specific legal language you need to use to protect yourself.

This process evolved over time. At first, they focused on the tokens—did I sell them, to whom, and so on. When they realized there was no cracking up on that front, they turned to how I was earning income from the protocol. When that didn’t work, they argued that the vaults themselves were securities, citing the Howey Test, claiming that users were giving money to third parties in the expectation of a return. It was frustrating because they often asked me to prove the negative—like proving Santa Claus doesn’t exist. You can’t do that definitively.

The letters stopped because of the upcoming election. I got the last letter about six to eight months before the election. I was relieved to get a final letter a month ago saying they were not taking further enforcement action. But the time and effort it took was insane.

There was a period of three weeks where I did nothing but collect data for them—sometimes even data I didn’t have, like logs from the protocol’s third-party escrow provider. The drain made it nearly impossible to do anything else.

02 The Evolution and Stagnation of DeFi

The DCo Podcast：You sound very nervous. You mentioned decentralization earlier and suggested that people no longer prioritize it. Do you think there is a contradiction between running a crypto project as a sustainable business and ensuring it remains decentralized? Is this why we are seeing a decrease in focus on decentralization today?

Andre Cronje：It all depends on the market participants. Back when I launched Yearn, decentralization, self-custody, and immutability were very important. Back then the market was full of tech anarchists — purists who were in it for the idea, not the millions of dollars. The old meme “I’m in it for the tech” was unironically true back then.

But the player base has changed. Yield mining, the NFT craze, and now meme coins have lowered the barrier to entry. You no longer need to be tech-savvy — just install a wallet, click a few times, or log into an app with your fingerprint. I think 90% of the market today doesn’t subscribe to the tech idea. They’re in it for token appreciation or yield, not the idea.

This creates a mismatch. If you’re building foundational DeFi primitives — things that others can build on top of — they need to be immutable. You can’t have someone build a company on your primitives and then you change it and cause their system to break. For example, 90% of DeFi is still built on Uniswap V2 because it’s predictable and immutable. If Uniswap had made V2 support proxy upgrades and changed the LP logic overnight, DeFi would have collapsed.

But today, projects are more siloed. Everyone is building their own AMM or lending market instead of using third-party primitives because those third-party systems are often upgradeable. If you build an immutable product that relies on an upgradeable system, when they upgrade, your product may break. So composability and reliance on third parties have been put on the back burner.

The market has shifted from building immutable and 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 there is to build, so more projects follow that trend. In 2019, I wrote that we vote with our money. Where we put our money is what we get. In early 2021, people poured money into forks of Uniswap and Compound because they were “safe.”

New primitives are riskier — there’s a high risk of being hacked or exploited — so innovation stagnated. This is why memecoin is so popular right now. Since 2022, DeFi innovation has stagnated. We’ve built better products, like Hyperliquid, but they’re not new primitives — just iterations of existing primitives.

The DCo Podcast:You mentioned earlier that DeFi innovation has stagnated and that composability — building on top of other products — has faded. Because liquidity isn’t shared, it becomes difficult to do things like use one asset as collateral across protocols. Is there enough incentive to break out of this siloed approach, and how can we achieve it?

Andre Cronje: This may sound a little egotistical, but the problem is that you need a rare combination of skills: the ability to program, but also the ability to come up with innovative ideas and primitives, and not need funding to support them. The intersection is very small. I can use myself as an example, but it's rare. Most builders need funding, but raising money and building are completely different skills.

I tried to raise money - it's not my strong suit, so I chose to build without relying on money. Others have great ideas but have trouble pitching or networking. Meanwhile, you see the 99th offshoot of the same project raising $50 million overnight because they know the right people.

The real builders have a hard time getting the money they need. Most people can’t afford to go six months without income to pay the bills. Hyperliquid is an exception — they didn’t raise money because their team had a successful market making business before and had the resources to build and even do a large airdrop.

But if you raise money, you face the pressure of VCs. VCs are in it for ROI, not because they believe in your vision. That’s their job, and it leads to misalignment of goals.

Historically, in traditional finance or Web 1/Web 2, companies built stable businesses and spun out small R&D teams to test new ideas. We’ve seen some of this in crypto — like Aave launching GHO, Lens, or Family — but not enough. The social and reputational risks are too high. If a sub-product is exploited, even for just $50, the headlines will say the main project was hacked. The risk is not proportional to the reward.

So, it’s a hard problem, and there’s no immediate solution. Most developers are crazy to even try — it takes a masochistic streak to deal with exploits and reputational damage.

The DCo Podcast:Let’s revisit DeFi primitives. You mentioned that new primitives are being developed. What stage is DeFi at in terms of its foundational building blocks, and what immediate primitives can we build to push it forward?

Andre Cronje:DeFi is still in its early days. Even basic primitives like automated market makers (AMMs) are not yet perfect. We’re stuck with constant product formulas like X*Y=K. Curve Finance introduced stablecoins, and I introduced X3Y through Solidly, but innovation has stalled there.

As blockchain speeds increase, dynamic liquidity market makers (DLMMs) are emerging, which is a step forward. There is still a lot of work to be done with AMMs - new curves, trading methods, and liquidity provision strategies.

The next big breakthrough is on-chain oracles. DeFi avoids using them due to concerns about exploitation, but we can make them safe through different implementation methods. Without oracles, we lack critical data such as volatility, implied volatility, or order book data. Once we have powerful on-chain oracles, we can build proper pricing models, Black-Scholes calculations, and European or American options. This will open up on-chain perpetual contracts and delta neutral strategies, which are not possible now.

Look at traditional finance: futures and options dominate, but they are barely on-chain. The roadmap is clear - you need data first, but everyone is afraid to build it. You can implement strong security schemes entirely on-chain, or use off-chain oracles with zero-knowledge proofs or decentralized methods to avoid trusting intermediaries.

On top of that, insurance primitives are missing. There is a huge untapped space in DeFi. It's still early days, and if we can overcome the fear of innovation, the potential is huge. 03 Balancing Decentralization and UX The DCo Podcast: Do you think UX and decentralization are inherently contradictory? Is that part of the problem? Andre Cronje: Absolutely, 100%. True decentralization means no websites, no third-party browsers—just downloading the node software, running a local node, and submitting transactions through the command line interface (CLI) to interact with immutable smart contracts. This requires deep technical knowledge—syncing software, encoding transactions with base64 hashes, not just calling JSON RPCs. There are probably only 10,000 people in the world who can do this, or maybe even less.

On the other hand, a great UX means that users don’t need private keys or gas fees. Look at the successful Solana apps: you download a mobile app, log in with Google or Face ID, and click a button. That’s a far cry from decentralization, and a whole other ballgame.

Today’s successful apps hide a lot more from users — for example, managing private keys on their behalf. Hyperliquid is great, but once you deposit funds, it’s no longer decentralized. Your funds are held in a wallet they control, and private keys are held on their servers. It’s a great UX, but it’s centralized.

My approach is to build for the decentralized ideal first — pristine on-chain contracts that CLI users can interact with on their own nodes. Then I add layers of abstraction on top of that: an API that simplifies operations, saves users from having to use wallet passkeys, or gas fee abstractions. Eventually, you end up with an interface where users just click buttons, which translates operations into smart contract transactions via an API and a signing wallet.

This is the "right" way, but it requires a lot of additional infrastructure that may seem futile for the few people who can use a CLI. Decentralization and UX are like security and UX - real security requires complex passwords, isolated systems, and key rotation, but users won't do that for a free gaming app. Historically, when security conflicts with usability, usability always wins. Decentralization will be no different.

The goal is for users to not know they are using a blockchain - no wallets, no gas fees. 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 that users get a great user experience without having to trust a third party.

We do it manually now with these centralized solutions, but we will codify them into decentralized systems. It's like when I first started programming: manual first, then automated. We just need time.

The DCo Podcast:Two follow-up questions: One, how do we get to that decentralized but user-friendly future? Two, if decentralization and user experience are in conflict, at what point do you compromise decentralization for a better user experience?

Andre Cronje:I'll take the second question first. The boundary depends on what the user is willing to tolerate, which varies from app to app. For free mobile games, users expect zero friction - install and play. If a username, password, or social account binding is required, they won't bother because the perceived value is low.

But for a banking app with $100,000, users can accept two-factor authentication or extra steps because the value is high. Each application must find that balance point based on the psychological value assigned by users.

Currently, there are not many choices for crypto applications. Whether it is a game or a DeFi protocol, you need to download a wallet, protect your keys, recharge gas for them, and sign messages. This is a high threshold. We saw similar situations in cybersecurity in the mid-2010s - websites required 32-bit signed passwords, but users forgot their passwords and reset passwords became cumbersome. Eventually, applications allowed users to decide the level of security themselves while providing some back-end protection. The crypto space will develop similarly.

For the first question - how do we get there - we need builders who are willing to execute. Ethereum has long been a leader, and their research, like Ethereum Improvement Proposals (EIPs), lays out the blueprint for the next five years. Features like action bundling and account abstraction are a step in the right direction, but they are not first-class citizens yet - you need third-party infrastructure or deep knowledge to use them.

The upcoming PCRA upgrade will make them native features, which is very important. The roadmap is there; it's all about execution. But few teams are willing or able to do it. Ideas are cheap - execution is everything. I think this year we'll see major improvements, like full on-chain gas and account abstraction, meaning no wallets or gas required. This is a huge leap in user experience - users don't need to know which blockchain they're on, or use MetaMask. It's coming, probably this year or next, but the roadmap is clear.

04 Ethereum Challenges and Advice for Developers

The DCo Podcast：You mentioned Ethereum. What do you think of its current state? There are many criticisms that it has no direction, lacks implementation focus, or that everything is fragmented by only expanding the second layer (L2).

Andre Cronje：I have been outspoken that L2 is a waste of time and energy. The resources and funds invested in it are part of the misalignment problem I mentioned earlier - we vote with our money. When only forks of known applications are funded, that's all we see. Now, L2s are sucking up capital, but they’re becoming more centralized while claiming to be aligned with Ethereum.

My problem isn’t that L2s exist — I think they’re ultimately necessary for scaling. But Ethereum is nowhere near its scalability limits. It’s probably only using 2% of its maximum capacity. There’s a lot of room for base layers. Blockchains like Sonic, Avalanche, and Solana have demonstrated that high throughput can be achieved at the base layer without L2s. The focus on L2s was premature and fragmented the ecosystem, hurting composability and user experience.

L2s were supposed to be composable and interoperable, but they became a bunch of sidechains with centralized collators extracting fees for profit. That wasn’t the original idea. The bigger question is why. Ethereum went through a typical company life cycle: nimble at first, fast R&D, building quickly, and failing along the way. As it gained traction and grew, it became cautious — adding compliance, oversight, testing, committees, and a board of directors.

This bureaucracy slowed it down, and now it’s stagnant, too big to move fast. Companies at this stage either shed excess and refocus on their technological roots, or get outpaced by faster competitors. Ethereum is at this crossroads. We’re seeing internal shakeups—CEO changes, board reshuffles, Vitalik trying to take a stand. I hope they can refocus because I’m loyal to Ethereum; that’s why I’m involved in DeFi. But we can’t wait for them to figure it out.

Their research, like Ethereum Improvement Proposals, still sets the bar for the next two to five years, especially in terms of user experience, account abstraction, and on-chain oracles. But most of it was written between 2018 and 2020. The ideas are there; implementations are lagging. In terms of scalability, Ethereum’s base layer is only using 2% of its capacity. Even without layer 2 solutions, there’s a lot of room for growth.

My work at Phantom (now Sonic) demonstrated this. When Ethereum used proof-of-work, we saw that it limited throughput by imposing block time limits. We redesigned the consensus mechanism to use an asynchronous Byzantine Fault Tolerant (BFT) system and achieved 50,000-60,000 transactions per second. But the Ethereum Virtual Machine (EVM) became a bottleneck, limiting us to 200 transactions per second.

We analyzed the EVM and found obvious areas for improvement. The biggest problem was databases - LevelDB, PebbleDB, etc. - which spent most of their time in read and write operations. These databases were overkill for blockchains, designed with general-purpose queries in mind, not the simple address-nonce-data structures of the EVM. We built SonicDB, a flat-file database tailored for blockchains, which increased EVM throughput by eight times and reduced storage requirements by 98%. Ethereum could do this tomorrow and reap huge gains.

We’ve made other tweaks — new compilers, supersets, etc. — but the database is the easiest improvement to make. Why don’t they do it? Because they’re risk averse. Their technology handles tens of billions of dollars in assets, and any change is scary. The tradeoff is losing SQL query capabilities, but no one actually uses SQL queries on large-scale blockchain data — tools like Dune or Tenderly process transactions individually. It’s not really a loss, but Ethereum’s resistance to change is so strong that even low-risk improvements are put on hold.

The DCo Podcast: You mentioned ideas like on-chain credit scoring, which we can dig into next time. But finally, what’s your most important advice for new builders in this space?

Andre Cronje:My advice has evolved. To be honest, developing in crypto is not the smartest choice - other areas are simpler, more secure, and have less negative impact. But if you decide to do it, do it publicly. Share your work on Twitter, open source your GitHub, let people see and test your code. Build a community of contributors, not just exploiters.

If a vulnerability is bound to happen, it's better to do it early on, when the risk is only $50, not $50 million later when it's open. Set up social profiles, communicate what you're doing and how you're doing it, invite testing - hopefully white hat, not black hat. Small vulnerabilities are recoverable; big ones are not.

If you can get funding, prioritize security. Work with teams like TRM, Chainalysis, or Seal Team 6 for audits and red team exercises. Audits by firms like SlowMist are critical. Learn how to handle security disclosures and emergencies early on.

This field isn’t for everyone — some leave at their first crisis because it’s too stressful. Building in the open is a litmus test: you’ll quickly know if you’re a good fit. Take it, and you’ll either find your place or realize it’s not for you.

The DCo Podcast:Thank you for your time, Andre. I enjoyed this exchange and hopefully we can do it again soon.

Andre Cronje: My pleasure. Let me know and we'll do it again.