DeFi Crossroads: Acacia Road Cautions "L2 is a Disaster," Ethereum Bureaucracy is Killing Innovation

Original Title: "AC Unveiled: The Stagnation of DeFi, Ethereum's Crossroads, and the Art of Building in Crypto"

Original Author: The DCo Podcast, Plain English Blockchain

In the rapidly changing and highly uncertain world of decentralized finance (DeFi), Andre Cronje undoubtedly holds a significant position. As the mastermind behind projects like YFI, SushiSwap, Fantom, and more, he now leads Sonic as its CTO, leaving a profound impact on the forefront of crypto finance.

In this episode of The DCo Podcast, AC candidly reveals his perspective on the development bottlenecks of DeFi, the challenges facing the Ethereum ecosystem, and the harsh realities that builders must confront in this space where idealism and profit-driven behavior coexist.

From negotiating with regulatory bodies to seeking delicate balances between decentralization and user experience, his insights serve as a wake-up call to industry builders and an inspiration to all who hold the dream of DeFi.

Below is the main content:

Addressing the Regulatory Challenges of Crypto Assets

The DCo Podcast: Welcome to the show, Andre. You are known for creating Yearn Finance, SushiSwap, Phantom, and now you are the CTO of Sonic. The past few years have been a wild ride in the crypto space. Could you share what the last three years have been like for you, especially the challenges you faced and how you tackled them? I assume you are now more focused on code rather than dealing with regulatory issues.

Andre Cronje: Thank you for having me. To be honest, I wish I could say I am focused on code, but regulatory and legal issues still take up a significant 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 crucial lesson in building in public. Then in the SushiSwap project, I realized the crypto space was evolving—people are no longer as concerned about true decentralization or immutability.

Additionally, despite being a South African developer working locally, not raising funds from anyone, and not selling tokens as a South African, I still found myself in battles with the SEC. They sent me a ton of letters and requests, which was exhausting. I learned a lot and grew through it, but it was a tough process. Is there a specific topic you'd like to dive deeper into, or should we keep the discussion broad?

The DCo Podcast: I'm very interested in learning more about how you handled those SEC letters. Did you have legal help? How did you navigate this process, especially when it sounded very overwhelming at first?

Andre Cronje: Initially, I was very naive. The first letter seemed straightforward — just a request for information with implicit threats of escalation if I didn't cooperate. They asked questions like, "To whom did you sell the Token?" The answer was simple: I didn't sell it to anyone. Or, "How do you make money from the protocol?" Equally simple: 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 letter, it was clear they understood DeFi, Tokens, and how these systems function. It felt like they were trying to catch me making a mistake rather than genuinely seeking information.

By the time the third letter arrived, I realized I needed help. I didn't have the funds to hire someone, so I had to rely on my network. I reached out to Gabriel of Lex Node, a prolific crypto lawyer who has worked with many DAOs. He was exceptional and provided a lot of support. Through him, I met Steven Palley, another seasoned individual in this field who really knows his stuff.

Gabe did most of the heavy lifting in the early stages, with Steven heavily involved later on. They were instrumental because it's not just about the information you provide — it's more about how you frame it. You need to use specific legal language to protect yourself.

This process evolved over time. Initially, they focused on the Token — whether I sold it, to whom, etc. When they realized that wasn't yielding results, they shifted to how I generated income from the protocol. When that didn't stick either, they argued that the treasury itself was a security, citing the Howey Test, claiming users were providing funds to a third party in the hope of returns. 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 reason the letters stopped was the upcoming election. About six to eight months before the election, I received the final letter. A month before that, I got a penultimate letter stating they would not take any further enforcement action, which was a relief. But the time and energy spent were insane.

For a period, for three consecutive weeks, all I did was collect data for them — sometimes even data I didn't have, like logs from a third-party custodian for my protocol. This drain made it nearly impossible for me to do anything else.

The Evolution and Stagnation of DeFi

The DCo Podcast: Sounds very intense. You mentioned earlier the decentralization and hinted that people are no longer prioritizing it. Do you think there is a contradiction between running a cryptocurrency project as a sustainable business and ensuring its decentralization? Is this why we are seeing a reduced focus on decentralization today?

Andre Cronje: It all depends on market participants. Back when I launched Yearn, decentralization, self-custody, and immutability were crucial. At that time, the market was filled with techno-anarchists — purists who participated for the idea rather than for millions of dollars. The old joke "I'm here for the tech" was unironically true then.

But the participant base has changed. Liquidity mining, the NFT craze, and now even meme coins have lowered the entry barrier. You no longer need to understand the tech — just install a wallet, click a few times, or log in with a fingerprint to an app. I believe that 90% of people in today's market do not resonate with the tech idea. They are in it for token appreciation or yield, not for the concept.

This can lead to misalignments. If you are building foundational DeFi primitives — things that others can build on — they need to be immutable. You can't have someone build a company on your primitive, then change it, causing their system to collapse. For example, 90% of DeFi is still built on Uniswap V2 because it is predictable and immutable. If Uniswap were to make V2 support a proxy upgrade and change LP logic overnight, DeFi would collapse.

But today, projects are more siloed. Everyone is building their own AMM or lending market rather than using third-party primitives because those third-party systems are usually upgradeable. If you build an immutable product relying on upgradeable systems, when they upgrade, your product could break. Therefore, composability and reliance on third parties have taken a back seat.

The market has shifted from building immutable and composable primitives to building companies focused on revenue or token value. This is a snowball effect: the more projects prioritize revenue, the less immutability of the infrastructure there is to build upon, so more projects follow this trend. In 2019, I wrote that we vote with money. Where we put our money determines what we get. In early 2021, everyone put their money into Uniswap and Compound forks because they were "safe."

The new primitive carries a higher risk — the risk of being hacked or exploited — hence innovation has stagnated. This is also why memecoins are so popular now. Since 2022, DeFi innovation has stalled. We have developed better products, like Hyperliquid, but they are not new primitives — just iterations of existing primitives.

The DCo Podcast: You previously mentioned that DeFi innovation has stalled, composability — building on top of other products — has also been waning. Due to siloed liquidity, operations like cross-protocol asset usage as collateral have become challenging. Is there enough incentive to break out of this isolated way, and how can we achieve that?

Andre Cronje: It might sound a bit self-conceited, but the issue is you need a rare skill set: being able to code, come up with innovative ideas and primitives, and not require funding. The intersection of these skills is very small. I can consider myself as an example, but it's rare. Most builders need funding, but fundraising and building are entirely different skills.

I tried raising funds — that's not my strong suit, so I chose not to rely on funding for building. Others have great ideas but struggle with promotion or socializing. Meanwhile, you will 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 necessary funding. Most can't afford six months with no income to pay bills. Hyperliquid is an exception — they didn't fundraise because their team had a successful market-making business before, possessing the resources to build and even conduct a large-scale airdrop.

But if you raise funds, you are subject to venture capital pressure. Venture capital is for investment returns, not because they believe in your vision. That's their job and also leads to goal misalignment.

Historically, in traditional finance or Web 1/Web 2, companies built a stable business and spun off small R&D teams to test new ideas. We have seen some similar cases in the crypto space — like Aave launching GHO, Lens, or Family — but not enough yet. The social and reputational risk is too high. If a subproduct gets exploited, even if it's just $50, it becomes headline news that the main project was hacked. The risk outweighs the reward.

So, it's a tough nut to crack with no immediate solution. Most developers daring to try are already quite crazy — to deal with exploits and reputation damage, you need a masochistic tendency.

The DCo Podcast: Let's Reexamine DeFi Primitives. You mentioned that new primitives are being developed. In terms of its foundational building blocks, what stage is DeFi at, and what immediate primitives can we build to further 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 stuck on formulas like X*Y=K. Curve Finance introduced stable exchanges, and I introduced X3Y through Solidly, but innovation halted there.

With the increase in blockchain speed, Dynamic Liquidity Automated Market Makers (DLMMs) are emerging, which is a step forward. AMMs still have a lot of work to do—new curves, trading methodologies, and liquidity provisioning strategies.

The next major breakthrough is on-chain oracles. DeFi has avoided using them due to concerns of manipulation, but we can make them secure through different implementation methods. Without oracles, we lack critical data like volatility, implied volatility, or order book data. Once we have robust on-chain oracles, we can build appropriate pricing models, Black-Scholes calculations, and European or American options. This will enable 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 need the data first, but everyone is scared to build it. You can achieve a fully on-chain high-security solution, or use off-chain oracles with zero-knowledge proofs or decentralized approaches to avoid trust in intermediaries.

Furthermore, insurance primitives are also missing. DeFi has a vast undeveloped area. This is still the early stage, and if we can overcome the fear of innovation, the potential will be enormous.

Balancing Decentralization with User Experience

The DCo Podcast: Do you believe User Experience (UX) and decentralization are fundamentally at odds? Is this part of the issue?

Andre Cronje: Absolutely, 100%. True decentralization means no website, no third-party explorer—just downloading node software, running a local node, and interacting with immutable smart contracts through a Command Line Interface (CLI). This requires deep technical knowledge—syncing software, using 64-hex encoding for transactions, not just calling JSON RPC. Perhaps only 10,000 people worldwide can do this, or even fewer.

On the other hand, excellent user experience means users don't need a private key or gas fees. Look at a successful Solana application: you download a mobile app, log in with Google or Face ID, and then click a button. This is far from decentralized and is a completely different story.

Today, successful applications hide more from users—such as managing the private key on behalf of the user. While Hyperliquid is great, once you deposit funds, it is no longer decentralized. Your funds are held in a wallet they control, and the private key is stored on their server. This provides a good user experience but is centralized.

My approach is to first build for the decentralized ideal—an original on-chain contract that CLI users can interact with on their own node. Then, I build on top of it an abstraction layer: an API that simplifies operations, bypassing the need for users to handle wallet passphrases or gas fees. In the end, you get an interface where a user only needs to click a button, which converts the operation into a transaction via the API and a signing wallet to a smart contract.

This is the "right" way, but for the few who can use the CLI, it requires a lot of extra infrastructure and may seem futile. Decentralization and user experience are like security and user experience—real security requires complex passwords, isolated systems, and key rotation, but users won't do this for a free gaming app. Historically, when security clashed with usability, usability always won. Decentralization will too.

The goal is to make users unaware that they are using blockchain—no wallet, no gas fees. Now, this is achieved through centralized workarounds, such as APIs or backend servers. But I believe we can make these features first-class citizens of the blockchain so users can have an excellent user experience without trusting a third party.

We are currently manually implementing these centralized solutions, but we will compile them into decentralized systems. It's like when I started programming: manual operation first, then automation. 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 a better user experience?

Andre Cronje: I'll answer the second question first. The limit depends on the level of friction users are willing to tolerate, which varies by application. For a free mobile game, users expect zero friction—install and play. If they need a username, password, or social account binding, they won't bother because they perceive the value as low.

However, for a banking app with $100,000, the user can accept two-factor authentication or additional steps due to the high value involved. Each app must find that balance point based on the psychological value assigned by the user.

Currently, there are not many options for crypto applications. Whether it's a game or a DeFi protocol, you need to download a wallet, protect your keys, recharge it with gas, and sign messages. This is a high barrier to entry. We have seen a similar situation in mid-2010s in network security—websites demanding 32-character passwords with symbols, but users forgetting them and password resets becoming cumbersome. Eventually, applications allowed users to decide on their own security level while providing some backend protection. The crypto space will evolve similarly.

Regarding the first question—how do we get there—we need builders willing to execute. Ethereum has long been a frontrunner, with their research such as Ethereum Improvement Proposals (EIPs) laying out a blueprint for the next five years. Features like state bundle and account abstraction are steps 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 crucial. The roadmap already exists; the key is in execution. However, few teams are willing or able to do so. Ideas are cheap—execution is everything. I believe we will see significant improvements this year, like full on-chain gas and account abstraction, meaning no need for wallets or gas. This is a massive leap in user experience—users won't need to know which blockchain they are on or use MetaMask. It is coming, maybe this year or the next, but the roadmap is clear.

Ethereum's Challenges and Advice for Developers

The DCo Podcast: You mentioned Ethereum. How do you view its current state? There is a lot of criticism claiming it lacks direction, misses implementation focus, or that everything is becoming fragmented only through layer 2 (L2) scaling.

Andre Cronje: I have always been outspoken about L2 being a waste of time and effort. The resources and funds poured into it are part of the misalignment issue I mentioned earlier—we vote with money. When only forks of known apps get funding, that's all we see. Now, L2s are absorbing capital, but as they claim to stay in line with Ethereum, they are becoming more centralized.

My issue isn't with L2s existing—I believe they will eventually be necessary for scaling. But Ethereum is far from its scalability limit. It may have only used 2% of its maximum capacity. There is a lot of room at the base layer. Blockchains like Sonic, Avalanche, and Solana show that high throughput can be achieved at the base layer without L2. The early focus on L2 is premature and has fragmented the ecosystem, damaging composability and user experience.

L2 was supposed to be composable and interactive, but they have turned into a set of sidechains with a centralized sequencer extracting fees for profit. This was not the original vision. The bigger question is why this happened. Ethereum has gone through a typical corporate life cycle: initially nimble, rapid development, fast iteration, and continuous trial and error. As it gained attention and growth, it became cautious—adding compliance, oversight, testing, committees, and a board of directors.

This bureaucratic nature has made it slow, and it is now stagnant, too big to move quickly. Companies at this stage either shed the excess, refocus on the technical foundations, or get surpassed by faster competitors. Ethereum is at this crossroads. We see internal turmoil—a CEO change, a board reshuffle, Vitalik attempting to make a stance. I hope they can refocus because I am loyal to Ethereum; that's also why I engage in DeFi. But we can't wait for them to solve the issues.

Their research, like Ethereum Improvement Proposals, still sets standards for the next two to five years, especially in user experience, account abstraction, and on-chain oracles. But much of this was written between 2018 and 2020. The ideas exist; the implementation lags. In terms of scalability, Ethereum's base layer is only utilizing 2% of its capacity. Even without layer-two solutions, there is significant room for growth.

My work at Phantom (now Sonic) has proven this. When Ethereum used proof of work, we saw its throughput limited by setting block time constraints. We redesigned the consensus mechanism, using an asynchronous Byzantine Fault Tolerance (BFT) system, achieving 50,000 to 60,000 transactions per second. However, the Ethereum Virtual Machine (EVM) became a bottleneck, restricting us to 200 transactions per second.

We analyzed the EVM and found significant areas for improvement. The biggest issue was the database—LevelDB, PebbleDB, etc.—they spend most of their time on read-write operations. These databases are overkill for a blockchain, designed for general queries rather than the simple address-nonce-data structure of the EVM. We built SonicDB, a flat-file database customized for the blockchain, increasing EVM throughput by eight times, and reducing storage requirements by 98%. Ethereum could achieve this tomorrow and reap huge benefits.

We made other adjustments as well—a new compiler, supersets, etc.—but the database was the easiest improvement to implement. Why don't they do it? Because they are risk-averse. Their tech deals with billions of dollars in assets, making any change scary. The trade-off is losing SQL query capabilities, but in reality, no one uses SQL queries in large-scale blockchain data—tools like Dune or Tenderly handle transactions separately. This is not a real loss, but Ethereum's aversion to change is so strong that even low-risk improvements are put on hold.

The DCo Podcast: You mentioned ideas such as on-chain credit scoring, which we can delve deeper into next time. But finally, may I ask, what is your most important advice for newcomers in this field?

Andre Cronje: My advice has evolved. To be honest, getting into development in the crypto space is not the wisest choice—other fields are simpler, more secure, and have less negative impact. But if you decide to proceed, do so openly. Share your work on Twitter, open-source your GitHub, let people see and test your code. Build a contributing community, not just an exploiting one.

If a vulnerability is inevitable, it's better to face it early on when the risk is only $50, rather than when it's $50 million later on. Build a social profile, communicate what you are doing and how, invite testing—hopefully from white hats, not black hats. Small vulnerabilities can be recovered from; large ones cannot.

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

This field is not for everyone—some walk away at the first crisis because the pressure is too intense. Open development is a litmus test: you'll quickly discover if you're a fit. Embrace it, either find your place or realize it's not for you.

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

Andre Cronje: The pleasure was mine. Just let me know, and we'll do it again.

Original Article Link