AC Revealed: The Stagnation of DeFi, Ethereum's Crossroads, and the Art of Building in the Crypto Space

Author: The DCo Podcast, Baihua Blockchain

In the rapidly changing and uncertain world of decentralized finance (DeFi), Andre Cronje's name is undoubtedly significant. As the driving force behind several projects such as YFI, Solidly, and Fantom, he is now leading the development of Sonic as CTO, leaving a profound mark on the forefront of crypto finance. In this episode of The DCo Podcast, AC candidly reveals the bottlenecks in DeFi development, the challenges facing the Ethereum ecosystem, and the harsh realities that builders must confront in this realm where idealism coexists with profit-seeking behavior.

From the tug-of-war with regulators to seeking a delicate balance between decentralization and user experience, his insights serve as a wake-up call for industry builders and inspiration for all those who harbor DeFi dreams.

Addressing Regulatory Challenges for Crypto Assets

The DCo Podcast: Welcome to the show, Andre. You are known for creating Yearn Finance, Solidly, and Phantom, and now you are the CTO of Sonic. The crypto space has gone through a wild 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 be focusing more on code now rather than dealing with regulatory issues.

Andre Cronje: Thank you for having me. To be honest, I wish I could say I focus on code, but regulatory and legal issues still take up a lot 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 an important lesson for building in public. Then in the Solidly project, I realized that the crypto space is changing—people no longer care as much about true decentralization or immutability.

Moreover, despite being a South African developer who has not raised funds or sold tokens, I still had to fight with the SEC. They sent me a lot of letters and requests, which were exhausting. I learned a lot from it and grew quite a bit, but the process was tough. Do you have specific topics you want to delve into, or should we keep it broad?

The DCo Podcast: I would love to learn more about how you handled those SEC letters. Did you have legal assistance? How did you navigate this process, especially since it sounds overwhelming at first?

Andre Cronje: At first, I was naive. The initial letters seemed straightforward—just requests for information with implied threats of escalation if I didn’t cooperate. They asked questions like, "Who did you sell the tokens to?" The answer was simple: I didn’t sell to anyone. Or, "How do you make money from the protocol?" Again, simple: I don’t.

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

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 has worked with many DAOs. He was fantastic and provided a lot of support. Through him, I met Steven Palley, another seasoned professional in the field who really knows his stuff.

Gabe did most of the early work, and Steven got heavily involved later on. They were crucial because it’s not just about the information you provide—more importantly, it’s how you express it. You need to use specific legal language to protect yourself.

The process evolved over time. Initially, they focused on the tokens—whether I sold them, to whom, and so on. When they realized there was no breakthrough there, they shifted to how I made income from the protocol. When that didn’t work either, they argued that the treasury itself was a security, citing the Howey Test, claiming users provided funds to a third party with the expectation of profit. It was frustrating because they often asked me to prove a negative—like proving Santa Claus doesn’t exist. You can’t definitively do that.

The letters stopped because of the upcoming elections. About six to eight months before the election, I received the last letter. A month ago, I got a final letter stating they would not take further enforcement action, which was a relief. But the time and energy spent were just insane.

For a while, I did nothing but gather data for them for three weeks—sometimes even data I didn’t have, like logs from third-party custodians I didn’t have agreements with. This drain made it nearly impossible to do anything else.

The Evolution and Stagnation of DeFi

The DCo Podcast: That sounds very stressful. You mentioned decentralization earlier and hinted that people no longer prioritize it. Do you think there is a contradiction between operating crypto projects as sustainable businesses and ensuring they remain decentralized? Is this why we see a decrease in focus on decentralization today?

Andre Cronje: It entirely depends on the market participants. Back when I launched Yearn, decentralization, self-custody, and immutability were very important. The market was filled with tech anarchists—purists who participated for the ideology rather than millions of dollars. The old adage "I’m in it for the tech" was genuinely true back then.

But the participant base has changed. Liquidity mining, the NFT craze, and now meme coins have lowered the barrier to entry. You no longer need to understand the technology—you just need to install a wallet, click a few buttons, or log in with a fingerprint. I think 90% of the people in the market today don’t resonate with the tech ideology. They are in it for token appreciation or yields, not the ideology.

This leads to a mismatch. If you are building foundational DeFi primitives—things others can build upon—they need to be immutable. You can’t let someone build a company based on your primitive and then change it, causing their system to break. For example, 90% of DeFi is still built on Uniswap V2 because it is predictable and immutable. If Uniswap allowed V2 to support proxy upgrades and changed the LP logic overnight, DeFi would collapse.

But today, projects are more isolated. Everyone is building their own AMM or lending market instead of using third-party primitives because those third-party systems are often upgradable. If you build an immutable product that relies on an upgradable system, when they upgrade, your product may break. Thus, composability and reliance on third parties are deprioritized.

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 immutability there is in the infrastructure to build upon, leading to more projects following this trend. In 2019, I wrote about how we vote with our money. Where we put our money determines what we get. At the beginning of 2021, everyone was pouring money into forks of Uniswap and Compound because they were "safe."

New primitives carry higher risks—there’s a high risk of being hacked or exploited—so innovation has stagnated. This is also why memecoins are so popular now. Since 2022, DeFi innovation has come to a standstill. We’ve developed better products like Hyperliquid, but they are not new primitives—just iterations of existing ones.

The DCo Podcast: You mentioned earlier that DeFi innovation has stagnated, and composability—building on top of other products—has also gradually faded. Due to the lack of shared liquidity, operations like using one asset as collateral across protocols have become difficult. Are there enough incentives to break this isolation, and how can we achieve that?

Andre Cronje: This may sound a bit arrogant, but the issue is that you need a rare skill set: the ability to program, propose innovative ideas and primitives, and not require funding. That intersection is very small. I can consider myself an example, but that’s rare. Most builders need funding, but fundraising and building are entirely different skills.

I’ve tried fundraising—it’s not my strong suit, so I choose not to rely on funding to build. Others have great ideas but struggle with pitching or social aspects. Meanwhile, you see the 99th fork of the same project raising $50 million overnight because they know the right people.

True builders find it hard to get the funding they need. Most people can’t afford to go six months without income to pay their bills. Hyperliquid is an exception—they didn’t raise funds because their team had a successful market-making business before and had the resources to build and even do large-scale airdrops.

But if you raise funds, you face the pressure of venture capital. Venture capital is about ROI, not because they believe in your vision. That’s their job, which leads to misaligned goals.

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’ve seen some similar situations in crypto—like Aave launching GHO, Lens, or Family—but not enough. The social and reputational risks are too high. If a sub-product gets exploited, even for just $50, the headlines will say the main project was hacked. The risk-reward ratio is disproportionate.

So, it’s a conundrum with no solution in the short term. It’s already crazy that most developers dare to try—dealing with exploits and reputational damage requires a certain masochistic tendency.

The DCo Podcast: Let’s revisit DeFi primitives. You mentioned you are developing new primitives. What stage is DeFi at in terms of its foundational building blocks, and what immediate primitives can we build to drive its development?

Andre Cronje: DeFi is still in its early stages. Even basic primitives like automated market makers (AMMs) are not yet perfected. We are still at the constant product formula like X*Y=K. Curve Finance introduced stable swaps, and I introduced X3Y through Solidly, but innovation has stagnated there.

With the increase in blockchain speed, dynamic liquidity market makers (DLMMs) are emerging, which is a step forward. AMMs still have a lot of work to do—new curves, trading methods, and liquidity provision strategies.

The next major breakthrough is on-chain oracles. DeFi has avoided using them due to concerns about exploitation, but we can make them safe through different implementations. Without oracles, we lack critical data like volatility, implied volatility, or order book data. Once we have robust on-chain oracles, we can build proper pricing models, Black-Scholes calculations, and European or American options. This will unlock on-chain perpetual contracts and delta-neutral strategies, which are currently impossible.

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

Additionally, insurance primitives are still missing. There is a vast untapped area in DeFi. We are still in the early stages, and if we can overcome the fear of innovation, the potential will be enormous.

Balancing Decentralization and User Experience

The DCo Podcast: Do you think user experience (UX) and decentralization are inherently contradictory? Is this part of the problem?

Andre Cronje: Absolutely, 100%. True decentralization means no websites, no third-party browsers—just downloading node software, running a local node, and submitting transactions via a command-line interface (CLI) to interact with immutable smart contracts. This requires deep technical knowledge—syncing software, using 64-bit hash encoding for transactions, not just calling JSON RPC. There may only be about 10,000 people globally who can do this, or even fewer.

On the other hand, excellent user experience means users don’t need private keys or gas fees. Look at successful Solana apps: you download a mobile app, log in with Google or Face ID, and then click a button. This is far from decentralization; it’s a completely different thing.

Successful applications today hide more from users—for example, managing private keys on behalf of users. Hyperliquid is great, but once you deposit funds, it is no longer decentralized. Your funds are stored in wallets they control, with private keys kept on their servers. This is a good user experience, but it is centralized.

My approach is to first build for the ideal of decentralization—raw on-chain contracts that CLI users can interact with on their own nodes. Then I add an abstraction layer on top: an API that simplifies operations, removing the need for users to use wallet passkeys or abstracting gas fees. Ultimately, you get an interface where users just need to click a button, which translates the operation into a transaction for the smart contract via API and signed wallets.

This is the "right" way, but for the few who can use CLI, it requires a lot of additional infrastructure, which may seem futile. Decentralization and user experience are like security and user experience—true 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 the same.

The goal is to make users unaware that 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 functions first-class citizens of the blockchain, allowing users to have an excellent user experience without trusting third parties.

We are currently implementing these centralized solutions manually, but we will compile them into decentralized systems. It’s like when I first started programming: doing things manually first, then automating. We just need time.

The DCo Podcast: Two follow-up questions: First, how do we achieve that decentralized yet user-friendly future? Second, if decentralization and user experience conflict, at what point would you compromise decentralization for better user experience?

Andre Cronje: I’ll answer the second question first. The boundary depends on how much users are willing to tolerate, which varies by application. For a free mobile game, users expect zero friction—they want to install and play. If it requires a username, password, or social account binding, 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 based on the psychological value users assign.

Currently, there aren’t many choices for crypto applications. Whether it’s games or DeFi protocols, users need to download wallets, protect keys, fund them with gas, and sign messages. That’s a high barrier to entry. We saw something similar in cybersecurity in the mid-2010s—websites required 32-character passwords, but users forgot them, and resetting passwords became a hassle. Eventually, applications allowed users to decide their security level while providing some backend protection. The crypto space will evolve similarly.

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

The upcoming PCRA upgrade will make them native features, which is crucial. The roadmap is already there; the key is execution. But few teams are willing or able to do that. Ideas are cheap—execution is everything. I think we will see significant improvements this year, like full on-chain gas and account abstraction, meaning no wallets or gas fees. This will be a massive leap in user experience—users won’t need to know which blockchain they are on or use MetaMask. It’s coming, possibly this year or next, but the roadmap is clear.

Challenges for Ethereum and Advice for Developers

The DCo Podcast: You mentioned Ethereum. How do you view its current state? There are many criticisms that it lacks direction, has no focus on implementation, or that everything is becoming fragmented through layer 2 (L2) scaling.

Andre Cronje: I have always been outspoken that L2 is a waste of time and resources. The resources and funds poured into it are part of the misalignment issue I mentioned earlier—we vote with our money. When only known application forks get funding, that’s all we see. Now, L2 is absorbing capital, but they are becoming more centralized while claiming to stay aligned with Ethereum.

My issue isn’t that L2 exists—I think they will ultimately be necessary for scaling. But Ethereum is far from its scalability limits. It may have only used 2% of its maximum capacity. The base layer has plenty of room. Blockchains like Sonic, Avalanche, and Solana demonstrate that high throughput can be achieved at the base layer without L2. The focus on L2 is premature and has fragmented the ecosystem, harming composability and user experience.

L2 should have been composable and interactive, but they have turned into a bunch of sidechains with centralized orderers extracting fees for profit. This was not the original vision. The bigger question is why this happened. Ethereum has gone through a typical corporate lifecycle: initially flexible, rapid R&D, quickly building while iterating along the way. As it gained attention and grew, it became cautious—adding compliance, oversight, testing, committees, and boards.

This bureaucracy has slowed it down, and now it has stagnated, too large to act quickly. Companies at this stage either shed excess parts and refocus on their technical roots or get surpassed by faster competitors. Ethereum is at this crossroads. We see internal turmoil—CEO changes, board restructuring, Vitalik trying to make statements. I hope they can refocus because I am loyal to Ethereum; that’s also why I got involved in DeFi. But we can’t wait for them to solve the problems.

Their research, like Ethereum Improvement Proposals, still sets the standard for the next two to five years, especially regarding user experience, account abstraction, and on-chain oracles. But most of that content was written between 2018 and 2020. The ideas are there; the implementation is lagging. In terms of scalability, Ethereum's base layer has only used 2% of its capacity. Even without layer 2 solutions, there is significant room for growth.

My work at Phantom (now Sonic) proved this. When Ethereum was using proof of work, we saw that it limited throughput by setting block time limits. We redesigned the consensus mechanism, adopting an asynchronous Byzantine Fault Tolerance (BFT) system, achieving 50,000 to 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 identified clear points for improvement. The biggest issue is the database—LevelDB, PebbleDB, etc.—which spends most of its time on read/write operations. These databases are overkill for blockchains, designed for general queries rather than the simple address-nonce-data structure of the EVM. We built SonicDB, a flat-file database customized for blockchains, which increased EVM throughput eightfold and reduced storage requirements by 98%. Ethereum could implement this tomorrow and reap huge benefits.

We also made other adjustments—new compilers, supersets, etc.—but the database is the easiest improvement to implement. Why don’t they do it? Because they are risk-averse. Their technology handles billions of dollars in assets, and any change feels scary. The trade-off is losing SQL query capabilities, but in reality, no one uses SQL queries on large-scale blockchain data—tools like Dune or Tenderly handle transactions separately. This isn’t a real loss, but Ethereum’s resistance to change is so strong that even low-risk improvements are shelved.

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

Andre Cronje: My advice has evolved. To be honest, developing in the crypto space isn’t the smartest choice—other fields are simpler, more secure, and have less negative impact. But if you decide to do it, build in public. Share your work on Twitter, open-source your GitHub, and let people see and test your code. Build a community of contributors, not just a community that exploits vulnerabilities.

If exploits are bound to happen, it’s better to occur early when the risk is just $50 rather than later when it’s $50 million. Build a social profile, communicate what you are doing and how, and invite testing—hopefully from white hats, not black hats. Small exploits can be recovered from; large ones cannot.

If you can secure funding, prioritize security. Work with teams like TRM, Chainalysis, or Seal Team 6 for audits and red team exercises. Audits from companies like SlowMist are crucial. Learn early how to handle security disclosures and emergencies.

This field isn’t for everyone—some people leave at the first crisis because the pressure is too much. Building in public is a litmus test: you’ll quickly know if you’re cut out for it. Accept it; you either find your place or realize it’s not for you.

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

Andre Cronje: It’s been a pleasure. Let me know, and we’ll do it again.