AC Reveals: About the Stagnation of DeFi, the Crossroads of Ethereum, and the Art of Building a Cryptotechnology

Author: The DCo Podcast, vernacular blockchain

Andre Cronje’s name is undoubtedly important in the rapidly changing and uncertain field of decentralized finance (DeFi). As the behind-the-scenes driver of many projects such as YFI, Solidly, Fantom, and more, he has now led the development of Sonic as a CTO, and AC has left a deep mark on the forefront of crypto finance.

In this issue of The DCo Podcast interview, AC candidly reveal the bottlenecks of DeFi development in his eyes, the challenges facing the Ethereum ecosystem, and the cruel reality that builders must face in this field of idealism and profit-seeking behavior.

From playing with regulators to finding a delicate balance between decentralization and user experience, his insights are both a warning to industry builders and an inspiration for all those who have DeFi dreams.

Respond to regulatory challenges in crypto assets

The DCo Podcast : Welcome to the show, Andre. You are famous for creating Yearn Finance, Solidly, Phantom, and now you are the CTO of Sonic. The crypto space has gone 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 face and how you deal with them? I guess you should focus more on code now than dealing with regulatory issues.

Andre Cronje: Thanks for inviting 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 past four years have been a steep learning curve. I had to deal with things like the Eminence vulnerability, which is a big lesson for public builds. Then in the Solidly project, I realized that the crypto space was changing – people no longer care so much about real decentralization or immutability.

Beyond that, I fought the SEC despite being a South African who developed locally in South Africa, didn’t raise any funds from anyone, and didn’t sell tokens. They sent me a lot of letters and requests, which were exhausting. I learned a lot from it and grew a lot, but the process was very difficult. Do you have any specific topics that you want to explore in depth, or do we keep discussing extensively?

The DCo Podcast : I would love to learn more about how you guys deal with those SEC letters. Do you have any legal help? How did you deal with this process, especially when it sounds so overwhelming at the beginning?

Andre Cronje: At first, I was naive. The initial letter seemed simple—just requesting information, with an implicit threat that would escalate if I didn't cooperate. They asked questions like "Who did you sell your tokens?" The answer is simple: I didn't sell it to anyone. Or, “How do you make money from the agreement?” is equally simple: I don’t.

I thought it would be over. But the second letter is more detailed, and by the fifth or sixth letter, it is clear that they understand DeFi, tokens, and how these systems work. It feels like they are trying to catch me and make mistakes, not really seeking information.

By the time I reached the third letter, I realized I needed help. I didn't raise funds, so I had to rely on my connections. I contacted Gabriel of Lex Node, a prolific crypto lawyer who has worked with many DAOs. He is excellent and provides a lot of support. Through him, I met Steven Palley, another veteran in this field, and I really know it.

Gabe took on most of the work early, while Steven stepped in heavily later. They are very critical because it's not just the information you provide -it's more important how you express it. You need to use specific legal language to protect yourself.

This process evolves over time. At first, they focused on the tokens - whether I sold them, to whom, and so on. When they realized there was no breakthrough in this, they turned to focus on how I earned my income from the agreement. When that didn't work, they argued that the vault itself was a securities, citing Howey Test, claiming that users provided funds to third parties in the hope of a return. It's frustrating because they often ask me to prove something negative - like proving that Santa does not exist. You can't do this explicitly.

The letters stopped because of the upcoming elections. I received my last letter about six to eight months before the election. I was relieved to receive a final letter a month ago that they no longer took further enforcement actions. But the time and energy spent is simply crazy.

For a while, for three weeks, I did nothing but collect data for them—sometimes even materials that I didn’t have at all, like logs of third-party hosting providers that I don’t have. This consumption makes it impossible for me to do anything else.

The evolution and stagnation of DeFi

The DCo Podcast : Sounds very nervous. You mentioned decentralization before and imply that people no longer prioritize it. Do you think there is a contradiction between operating crypto projects as a sustainable business and ensuring they remain decentralized? Is this the reason why we see a decrease in focus on decentralization now?

Andre Cronje: It's all up to the market participants. Back when I launched Yearn, decentralization, self-hosting, and immutability were very important. The market was filled with techno-anarchists—purists, who were involved for ideas rather than millions of dollars. That old joke "I participated for technology" was a real reality without irony at the time.

But the participant base has changed. The liquidity mining, NFT boom, and Meme coins have lowered the entry threshold. You no longer need to know technology—just install a wallet, click a few times, or log in to an app with your fingerprint. I think 90% of people in the market today do not agree with the technical philosophy. They are for the appreciation or gain of tokens, not ideas.

This can lead to mismatch. If you are building the basic DeFi primitives—things that others can build on them—they need to be immutable. You can't have someone build a company based on your primitives and you change it, causing their system to crash. For example, 90% of DeFi is still built on Uniswap V2 because it is predictable and immutable. If Uniswap makes V2 support proxy upgrades and changes LP logic overnight, DeFi will crash.

But nowadays, projects are more isolated. Everyone is building their own AMM or lending marketplace instead of using third-party primitives, because those third-party systems are usually upgradeable. If you build an immutable product that relies on an upgradeable system, your product may crash when they upgrade. Therefore, composability and dependence on third parties are placed at a secondary level.

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 of the infrastructure is available to build, 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 was putting their money into Uniswap and Compound fork projects because they were "safe".

New primitives are at a higher risk—there is a high risk of being hacked or exploited—and therefore innovation stagnates. This is why memecoin is so popular now. Since 2022, DeFi innovation has stagnated. We have developed better products like Hyperliquid, but they are not new primitives—just iterations of existing primitives.

The DCo Podcast : You mentioned earlier that DeFi innovation has stagnated, and compositionality – built on other products – has gradually faded. Because liquidity is not shared, operations such as using one asset as collateral across protocols become difficult. Is there enough incentives to break this isolation, and how can we achieve it?

Andre Cronje: This may sound a bit conceited, but the problem is that you need a rare skill set: both programmatically and come up with innovative ideas and primitives, and don’t need financial support. Such intersections are very small. I could take myself as an example, but this is rare. Most builders need funds, but financing and building are completely different skills.

I've tried raising funds – it's not my strong point, so I chose not to rely on funds for construction. Others have great ideas but have difficulties in pitching or socializing. Meanwhile, you'll see the 99th branch of the same project raise $50 million overnight because they know the right people.

It's hard for real builders to get the funds they need. Most people can’t afford to have no income for six months to pay their bills. Hyperliquid is an exception – they didn’t raise funds because their team had a successful market maker before, with the resources to build and even conduct large-scale airdrops.

But if you raise funds, you have to face the pressure of venture capital. Venture capital is for ROI, not because they believe in your vision. This is their responsibility and it also leads to inconsistencies in goals.

Historically, in traditional finance or Web 1/Web 2, companies have established stable businesses and spun off small R&D teams to test new ideas. We've seen some similar situations in the crypto space - like Aave launches GHO, Lens or Family - but not enough. Social and reputational risks are too high. If a sub-product is utilized, even if it is only $50, the headlines will say that the main project has been hacked. Risk is disproportionate to reward.

So, this is a difficult problem and there is no solution in the short term. It’s already crazy that most developers dare to try – it takes a masochistic tendency to deal with exploits and reputational damage.

The DCo Podcast : Let's revisit the DeFi primitives. You mentioned that new primitives are being developed. What stage is DeFi in its basic building blocks, and what real-time primitives can we build to drive it?

Andre Cronje: DeFi is still in its early stages. Even basic primitives like automatic market makers (AMMs) are not yet perfect. We stay at a constant product formula like X*Y=K. Curve Finance introduced stable exchanges, and I introduced X3Y through Solidly, but innovation stalled there.

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

The next major breakthrough is the on-chain oracle. DeFi avoids using them because they are worried about being exploited, but we can make them safe with different implementation methods. Without oracles, we lack key data such as volatility, implicit volatility, or order book data. Once we have a powerful on-chain oracle, we can build the right pricing model, Black-Scholes calculations, and European or American options. This will enable on-chain perpetual contracts and Delta neutral strategies, which are now impossible.

Look at traditional finance: Futures and options dominate, but they are hardly on the chain. The roadmap is clear – you need data first, but everyone is afraid to build it. You can implement strong security solutions entirely on-chain, or use off-chain oracles with zero-knowledge proof or decentralized approaches to avoid trusting intermediaries.

In addition, the insurance primitive is missing. DeFi has a huge unexplored area. This is still early stages, and if we can overcome our fear of innovation, the potential will be huge.

Balanced decentralization with user experience

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

Andre Cronje: Absolutely, 100%. True decentralization means no website, no third-party browsers - just download node software, run local nodes, and submit transactions through the command line interface (CLI) to interact with immutable smart contracts. This requires deep technical knowledge -synchronization software, using 64 hash coding transactions, not just calling JSON RPC. There may be only 10,000 people worldwide that can do it, or even fewer.

On the other hand, an excellent user experience means that users do not need private keys or gas fees. Check out the successful Solana app: You download a mobile app, log in with Google or Face ID, and then click a button. This is far from decentralization and is completely different.

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

My approach is to first build a decentralized ideal—the original on-chain contract that CLI users can interact with on their nodes. Then I added an abstraction layer on it: an API that simplifies operations, eliminating users' pass keys to use the wallet, or gas fee abstraction. Ultimately, you'll get an interface where users just click on the button, which converts operations into transactions for smart contracts via API and signature wallet.

This is the "right" way, but for a few who can use the CLI, it requires a lot of extra infrastructure and can seem futile. Decentralization and user experience are just like security and user experience – true security requires complex passwords, isolation systems and key rotations, but users won’t do this for a free gaming app. Historically, when security and availability conflict, availability always wins. The same will be true for decentralization.

The goal is to make users unaware that they are using blockchain—no wallets, no gas fees. This is now implemented through centralized workarounds, such as APIs or backend servers. But I believe we can make these features first-class citizens of blockchain so that users can get an excellent user experience without trusting third parties.

We now implement them manually with these centralized solutions, but we will codify them into decentralized systems. It's like when I first started programming: first manually, then automate. We only need time.

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

Andre Cronje: I'll answer the second question first. The boundaries depend on how much the user is willing to tolerate, which varies by application. For free mobile games, users expect zero friction - it can be played with it after installation. If you need a username, password or social account binding, they won't bother because of the low perceived value.

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

Currently, there are not many options for encryption applications. Whether it is a game or a DeFi protocol, you need to download the wallet, protect the key, top up the gas for it and sign the message. This is a very high threshold. We've seen a similar situation in cybersecurity in the mid-2010s -the website requires a 32-bit signed password, but the user forgets the password and resetting it becomes troublesome. Ultimately, the application allows the user to decide the level of security at his own discretion, while providing some backend protection. The field of encryption will develop similarly.

For the first question—how we get there—we need builders willing to execute. Ethereum has long been a leader, and their research, such as Ethereum Improvement Proposals (EIPs), has laid out a blueprint for the next five years. Features like operational 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 upgrades will make them native features, which is very important. The roadmap already exists; the key is execution. But few teams are willing or able to do this. The idea is cheap – execution is everything. I think we'll see major improvements this year, like full on-chain gas and account abstraction, meaning no wallet or gas is needed. This is a huge user experience leap—users don’t need to know which blockchain they are on, nor do they need to use MetaMask. It is coming, maybe this year or next, but the roadmap is clear.

Ethereum's Challenges and Suggestions to Developers

The DCo Podcast : You mentioned Ethereum. How do you view its current status? There are a lot of criticisms that it has no direction, lacks implementation focus, or simply expands on layer two (L2) that makes everything fragmented.

Andre Cronje: I've always been outspoken about L2 being a waste of time and energy. The resources and funds invested in it are part of the misalignment problem I mentioned before - we vote with money. That's all we see when only the forks of known applications get funding. Now, L2 is absorbing capital, but they are becoming more centralized while claiming to be consistent with Ethereum.

My problem is not that L2 exists - I think they are necessary for extensions in the end. But Ethereum is still far from its scalability limit. It may only use 2% of the maximum capacity. There is still a lot of room in the foundation layer. Blockchains like Sonic, Avalanche, and Solana demonstrate high throughput at the base layer without L2. The focus on L2 is too early and divides the ecosystem, damaging compositionality and user experience.

L2 should be composable and interactive, but they become a bunch of sidechains with centralized sorter extracting fees to make money. This is not the original idea. The bigger question is why this happens. Ethereum has experienced a typical company life cycle: it is flexible at first, rapid research and development, and rapid construction, and constantly trial and error in the process. As it gains attention and grows, it becomes cautious – adding compliance, oversight, testing, committees and boards.

This bureaucracy slowed it down and has now stalled and is too large to move quickly. Companies at this stage either divested the excess and refocused on their technological roots or were surpassed by faster competitors. Ethereum is at this crossroads. We see internal shocks—CEO change, board reorganization, Vitalik attempts to make a statement. I hope they can refocus because I am loyal to Ethereum; that's why I'm involved in DeFi. But we can't wait for them to solve the problem.

Their research, like Ethereum improvement proposals, still sets standards for the next two to five years, especially in terms of user experience, account abstraction and on-chain oracle. But most of it was written between 2018 and 2020. The concept already exists; but implementation lags behind. In terms of scalability, Ethereum's base layer uses only 2% of its capacity. Even without a second-tier solution, there is a lot of room for growth.

My work at Phantom (now Sonic) proves this. When Ethereum uses Proof of Work, we see that it limits throughput by setting block time limits. We have redesigned the consensus mechanism and adopted an asynchronous Byzantine Fault Tolerance (BFT) system to achieve 50,000 to 60,000 transactions per second. But Ethereum Virtual Machine (EVM) becomes a bottleneck, limiting us to 200 transactions per second.

We analyzed EVM and found obvious improvement points. The biggest problem is that databases - LevelDB, PebbleDB, etc. - spend most of their time reading and writing operations. These databases are useless for blockchains, and are designed with general queries, rather than simple address-nonce-data structures like EVM. We built SonicDB, a flat file database customized for blockchain, which increased EVM throughput by eight times and reduced storage requirements by 98%. Ethereum will achieve this tomorrow and make huge gains.

We have made other tweaks – 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 tens of billions of dollars in assets, and any change is scary. The trade-off is the loss of SQL query capabilities, but no one actually 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 resistance to change is so strong that even low-risk improvements have been put on hold.

The DCo Podcast : You mentioned ideas such as on-chain credit scores, which we can discuss in depth next time. But in the end, what are your most important suggestions for new builders in this field?

Andre Cronje: My advice has evolved. To be honest, development in the crypto space is not the smartest choice—other areas are simpler, more secure, and have fewer negative effects. But if you decide to do it, just commit it publicly. Share your work to Twitter, open source your GitHub, and let people see and test your code. Build a community that contributes, not just a community that exploits vulnerabilities.

If the vulnerability is destined to happen, it is best to be early on, when the risk is only $50, not $50 million when it was opened later. Build social profiles, communicate what you are doing and how, invite tests – hopefully white hats, not black hats. Small vulnerabilities can be recovered; large vulnerabilities cannot.

If you can get funds, prioritize security. Work with teams like TRM, Chainalysis or Seal Team 6 for audits and red team drills. Auditing for companies like SlowMist is crucial. Learn how to deal with safety disclosure and emergencies as early as possible.

This field is not for everyone – some people leave when they encounter the first crisis because the pressure is too high. Public construction is a touchstone: you will quickly know if you are suitable. Accept it, you either find your place or realize it is not for you.

The DCo Podcast : Thank you for your time, Andre. I love this exchange very much and hope we can do it again soon.

Andre Cronje: Very honored. Tell me, we will do it again.