AC Unveiled: On the Stagnation of DeFi, the Crossroads of Ethereum, and the Art of Building in Crypto

In the rapidly changing and uncertain DeFi field, Andre Cronje's name undoubtedly carries significant weight. As the mastermind behind projects like YFI, Solidly, and Fantom, he is now leading the development of Sonic as CTO, leaving a profound mark at the forefront of crypto finance.

In this episode of The DCo Podcast interview, AC candidly reveals the bottlenecks in DeFi development, the challenges facing the Ethereum ecosystem, and the brutal realities that builders must confront in a field where idealism and profit-seeking coexist.

From gaming with regulatory bodies to seeking a delicate balance between decentralization and user experience, his insights serve as both a wake-up call for industry builders and an enlightenment for all those harboring DeFi dreams.

Following is the main text:

01

Addressing Regulatory Challenges for Crypto Assets

The DCo Podcast: Welcome to the show, Andre. You're known for creating Yearn Finance, Solidly, and Phantom, and now you're the CTO of Sonic. The crypto field 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 faced and how you dealt with them? I guess you're now more focused on code rather than handling regulatory issues.

Andre Cronje: Thank you for inviting me. To be honest, I wish I could say I'm focused on code, but regulatory and legal issues still occupy 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 was an important lesson for public building. Then in the Solidly project, I realized that the crypto field is transforming - people are no longer as concerned about true decentralization or immutability.

Moreover, despite being a local developer in South Africa who hasn't raised funds from anyone or sold Tokens, I still fought with the SEC. They sent me numerous letters and requests, which was exhausting. I learned a lot and grew significantly, but the process was difficult. Do you have specific topics you'd like to delve into, or shall we keep the discussion broad?

Andre Cronje: This might sound a bit arrogant, but the issue is that you need a rare skill combination: being able to program, propose innovative ideas and primitives, and not require funding support. Such an intersection is very small. I can use myself as an example, but this is rare. Most builders need funding, but fundraising and building are completely different skills.

I have tried fundraising—it's not my strength, so I choose to build without relying on funding. Others have great ideas but struggle with pitching or socializing. Meanwhile, you'll see the 99th branch of the same project raising $50 million overnight because they know the right people.

True builders find it hard to obtain the necessary funding. Most people cannot afford to pay bills without income for six months. Hyperliquid is an exception—they didn't raise funds because their team previously had a successful market-making business with resources to build and even conduct a large-scale airdrop.

But if you raise funds, you face venture capital pressure. Venture capitalists invest for returns, not because they believe in your vision. This is their duty and leads to misaligned objectives.

Historically, in traditional finance or Web 1/Web 2, companies established 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 it's not enough. Social and reputation risks are too high. If a sub-product is exploited, even for just $50, headlines will claim the main project was hacked. The risk is disproportionate to the reward.

So, this is a puzzle with no solution in the short term. Most developers are already crazy for daring to try—dealing with exploit vulnerabilities and reputation damage requires a masochistic tendency.

The DCo Podcast: Let's revisit DeFi primitives. You mentioned developing new primitives. What stage are DeFi's foundational building blocks at, and what instant 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're stuck with constant product formulas like X*Y=K. Curve Finance introduced stable exchanges, and I introduced X3Y through Solidly, but innovation stalled there.

With increasing blockchain speeds, dynamic liquidity market makers (DLMMs) are emerging, which is progress. AMMs still have much work to do—new curves, trading methods, and liquidity provision strategies.

The next major breakthrough is on-chain oracles. DeFi has avoided them due to exploit fears, 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're barely on-chain. The roadmap is clear—you first need data, but everyone is afraid to build it. You can implement fully secure on-chain solutions or use off-chain oracles with zero-knowledge proofs or decentralized methods to avoid trust intermediaries.

Beyond that, insurance primitives are missing. DeFi has a vast undeveloped landscape. This is still early stage, and if we can overcome the fear of innovation, the potential is enormous.

The DCo Podcast: You mentioned Ethereum. How do you view its current state? There are many criticisms that it lacks direction, lacks implementation focus, or has become fragmented solely through Layer 2 (L2) expansion.

Andre Cronje: I have always been outspoken that L2 is a waste of time and effort. The resources and funds invested are part of the misalignment I previously mentioned - we vote with money. When only forks of known applications receive funding, that's all we see. Now, L2 is absorbing capital, but while claiming to be aligned with Ethereum, they are becoming more centralized.

My issue is not the existence of L2 - I believe they are ultimately necessary for scaling. But Ethereum is far from its scalability limit. It may have only used 2% of its maximum capacity. The base layer still has a lot of space. Blockchains like Sonic, Avalanche, and Solana have demonstrated high throughput at the base layer without L2. The focus on L2 is premature and fragments the ecosystem, harming composability and user experience.

L2 was supposed to be composable and interactive, but they have become a bunch of sidechains with centralized sequencers extracting fees for profit. This was not the original vision. The bigger question is why this happened. Ethereum went through a typical company lifecycle: initially flexible, rapid R&D, quick building, constantly iterating. 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 is stagnant, too large to move quickly. Companies at this stage either shed excess parts and refocus on their technological foundations, or are overtaken by faster competitors. Ethereum is at this crossroads. We see internal turbulence - CEO replacements, board restructuring, Vitalik trying to make statements. I hope they can refocus because I am loyal to Ethereum; this is why I got involved in DeFi. But we cannot wait for them to solve the problems.

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 most of this was written between 2018 and 2020. The ideas exist; implementation is lagging. In terms of scalability, Ethereum's base layer is using only 2% of its capacity. There is significant room for growth even without Layer 2 solutions.

My work at Phantom (now Sonic) proved this. When Ethereum was using proof of work, we saw how it limited throughput by setting block time limits. We redesigned the consensus mechanism using an asynchronous Byzantine Fault Tolerant (BFT) system, achieving 50,000 to 60,000 transactions per second. But the Ethereum Virtual Machine (EVM) became the bottleneck, restricting us to 200 transactions per second.

We analyzed the EVM and found obvious improvement points. The biggest issue was the database - LevelDB, PebbleDB, etc. - which spent most of their time on read and write operations. These databases are overkill for blockchain, designed for general queries rather than the simple address-nonce-data structure of 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 could implement this tomorrow and gain huge benefits.

We made other adjustments - new compilers, supersets, etc. - but the database was the easiest improvement to implement. Why don't they do it? Because they are risk-averse. They are handling assets worth billions of dollars, and any change feels scary. The trade-off is losing SQL query functionality, but in reality, no one uses SQL queries in large-scale blockchain data - tools like Dune or Tenderly handle transactions separately. It's not 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 delve into next time. But lastly, what is the most important advice for new builders in this field?

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

If vulnerabilities are inevitable, it's better early when the risk is only $50, not $50 million when you later open it up. Build a social profile, communicate what you're doing and how, invite testing - hopefully by white hats, not black hats. Small vulnerabilities can be recovered; large ones cannot.

If you can get funding, prioritize security. Collaborate 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 is not for everyone - some leave after the first crisis because the stress is too high. Public building is a litmus test: you'll quickly know if you're suited for it. Accept it - you'll 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 was an honor. Let me know, and we'll do it again.

Article link: https://www.hellobtc.com/kp/du/04/5749.html

Source: https://mp.weixin.qq.com/s/cdO8p3YcJ83QMpmWnkYl_g