In the ever-changing and uncertain decentralized finance (DeFi) space, the name of Andre Cronje is undoubtedly significant. As the driving force behind multiple projects such as YFI, Solidly, and Fantom, he now leads the development of Sonic as CTO, leaving a deep imprint on the forefront of crypto finance.

Addressing Regulatory Challenges for Cryptocurrency Assets

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

Andre Cronje: Thank you for having me. Honestly, I wish I could say I'm 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 was an important lesson for public building. Then, in the Solidly project, I realized the crypto space was changing - people were no longer so concerned about true decentralization or immutability.

In addition, despite being a South African developer who didn't raise funds from anyone or sell 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 and grew a lot, but it was a tough process. Do you have a specific topic you'd like to explore further, or would you prefer to keep it broad?

The DCo Podcast: I'd love to learn more about how you handled those SEC letters. Did you have legal help? How did you deal with the process, especially when it initially seemed overwhelming?

Andre Cronje: At first, I was naive. The initial letters looked simple - just requests for information, with implied threats that they would escalate if I didn't comply. They asked questions like "Who did you sell the tokens to?" The answer was simple: I didn't sell them to anyone. Or, "How do you make money from the protocol?" Similarly simple: I don't.

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

By the third letter, I realized I needed help. I didn't raise funds, so I had to rely on my network. I contacted Gabriel from Lex Node, a prolific crypto lawyer who had worked with many DAOs. He was excellent and provided a lot of support. Through him, I met Steven Palley, another seasoned professional in the field, who really knew his stuff.

Gabe took most of the work in the early stages, and Steven got heavily involved later. They were crucial because it wasn't just about the information you provided - it was more about how you expressed it. You needed to use specific legal language to protect yourself.

This process evolved over time. Initially, they focused on tokens - whether I sold them, to whom, etc. When they realized there was no breakthrough there, they turned their attention to how I made money from the protocol. When that also didn't work, they argued that the treasury itself was a security, citing the Howey Test, claiming users provided funds to third parties expecting a return. This was frustrating because they often asked me to prove negatives - like proving Santa Claus doesn't exist. You can't do that definitively.

The letters stopped because of the upcoming election. About six to eight months before the election, I received the last letter. A month before, I received a final letter stating they would no longer take further enforcement actions, which relieved me. But the time and energy spent were insane.

For a period, I spent three weeks doing nothing but collecting data for them - sometimes even data I didn't have, like logs from third-party custodians of my protocol. This drain made it almost impossible for me 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 are no longer prioritizing it. Do you think there's a contradiction between operating a crypto project as a sustainable business and ensuring its continued decentralization? Is that why we're seeing less focus on decentralization today?

Andre Cronje: It completely depends on market participants. When I launched Yearn, decentralization, self-custody, and immutability were crucial. At that time, the market was full of technological anarchists - purists who participated for the ideology, not for millions of dollars. That old joke "I participate for the tech" was genuinely without irony back then.

But the participant base has changed. Liquidity mining, NFT mania, and now Meme coins have lowered the entry barrier. You no longer need to understand technology - just install a wallet, click a few times, or log in with your fingerprint to an app. I think 90% of the market today does not align with the technological ideology. They are here for token appreciation or yield, not for the ideology.

This leads to a mismatch. If you're 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 crash. For example, 90% of DeFi still relies on Uniswap V2 because it's predictable and immutable. If Uniswap allowed V2 to support proxy upgrades and changed the LP logic overnight, DeFi would collapse.

But nowadays, 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 usually upgradable. If you build an immutable product that relies on an upgradable system, your product might crash when they upgrade. Thus, composability and reliance on third parties are put on the back burner.

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 is available for building infrastructure, thus more projects follow this trend. In 2019, I wrote that we vote with money. Where we invest determines what we get. In early 2021, everyone poured money into forked projects of Uniswap and Compound because they were "safe."

New primitives carry higher risks - high risk of being hacked or exploited - leading to innovation stagnation. This is also why memecoins are so popular. 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 that DeFi innovation has stalled, and the concept of building on top of other products has gradually receded. Due to the lack of shared liquidity, operations such as using an asset as collateral across protocols become difficult. Are there enough incentives to break this isolation, and how can we achieve it?

Andre Cronje: This may sound arrogant, but the issue is that you need a rare combination of skills: both programming and coming up with innovative ideas and primitives, without needing funding. This intersection is very small. I can consider myself 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 strength, so I chose not to build with funding. Others have great ideas but struggle with pitching or socializing. Meanwhile, you see the 99th branch 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 can't afford six months without income to pay bills. 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 large airdrops.

But if you raise funds, you face venture capital pressure. Venture capital is about return on investment, not because they believe in your vision. It's their job, and it 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 similar situations in the crypto space - like Aave launching GHO, Lens, or Family - but it's not enough. The social and reputational risks are too high. If a sub-product is exploited, even just $50, the headlines will say the main project was hacked. The risk and reward are disproportionate.

So, it's a dilemma, with no solution in the short term. Most developers daring to try are already crazy - it takes a masochistic tendency to deal with exploits and reputation damage.

The DCo Podcast: Let's revisit DeFi primitives. You mentioned you're developing new primitives. Where is DeFi 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're still stuck with the X*Y=K constant product formula. Curve Finance introduced stable swaps, and I introduced X3Y through Solidly, but innovation there has stalled.

With increased blockchain speeds, 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 oracle. DeFi avoids them due to concerns about exploitation, but we can make them secure with different implementations. Without oracles, we lack critical data like volatility, implied volatility, or order book data. Once we have strong on-chain oracles, we can build suitable pricing models, Black-Scholes calculations, and European or American options. This will open up on-chain perpetual contracts and Delta neutral strategies, which are currently impossible.

Looking at traditional finance: futures and options dominate, but they are almost nonexistent on chain. The roadmap is clear - you first need data, but everyone is afraid to build it. You can fully implement a secure solution on chain, or use off-chain oracles with zero-knowledge proofs or decentralized methods to avoid trust intermediaries.

In addition, insurance primitives are missing. DeFi has a vast unexplored area. It's still early stage, and the potential is huge if we can overcome the fear of innovation.

Balancing Decentralization and User Experience

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

Andre Cronje: Definitely, 100%. True decentralization means no website, no third-party browser - 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, rather than just calling JSON RPC. Globally, only around 10,000 people can do this, maybe even fewer.

On the other hand, a great 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 click a button. This is far from decentralization, it's a whole different thing.

Successful applications today hide more content 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 stored in wallets controlled by them, with private keys kept on their servers. This is a great user experience, but it's centralized.

My approach is to first build for the decentralization ideal - original on-chain contracts, CLI users can interact with them on their own nodes. Then I add abstraction layers: an API that simplifies operations, eliminating the need for users to use a wallet or gas fees. Eventually, you get a user interface where you just click a button, which uses the API and signed wallet to convert actions into smart contract transactions.

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 game app. Historically, when security and usability conflict, usability always wins. Decentralization will be the same.

The goal is for users to not know they're using a blockchain - no wallet, no gas fees. This is currently achieved through centralized workarounds, like APIs or backend servers. But I believe we can make these features first-class citizens of the blockchain, so users can have a great user experience without trusting third parties.

We manually implement these centralized solutions now, but we'll codify them into decentralized systems. It's like when I first started programming: manual operations 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 are in conflict, at what point would you compromise decentralization for a 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 frictionless - install and play. If they need a username, password, or social account binding, they won't bother, because 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 users assign.

Currently, there are few choices for crypto applications. Whether it's games or DeFi protocols, you need to download a wallet, protect the key, fund gas, and sign messages. This is a high barrier. We saw something similar in cybersecurity in the mid-2000s - websites requiring 32-bit signed passwords, but users forgot passwords, and resetting became cumbersome. Eventually, applications allowed users to decide on their own security level while providing some backend protection. The crypto space will develop similarly.

For the first question - how we get there - we need builders who are willing to execute. Ethereum has long been a leader, and their research, such as Ethereum Improvement Proposals (EIPs), sets the blueprint for the next five years. Features like operation bundles and account abstraction are steps in the right direction, but they are not 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 very important. The roadmap exists; the key is execution. But few teams are willing or able to do this. Ideas are cheap - execution is everything. I think we will see major improvements this year, such as full on-chain gas and account abstraction, meaning no wallet or gas required. This is a huge user experience leap - users don't need to know which blockchain they're on, nor do they need MetaMask. It's coming, possibly this year or next, but the roadmap is clear.

Challenges of Ethereum and Advice for Developers

The DCo Podcast: You mentioned Ethereum. What's your view on its current state? There are many criticisms that it lacks direction, lacks implementation focus, or only leads to fragmentation through layer-2 (L2) scaling.

Andre Cronje: I've always been outspoken about L2 being a waste of time and effort. The resources and capital invested in it are part of the misalignment I mentioned earlier - we vote with money. When only forks of known applications receive funding, we only see those. Now, L2 is absorbing capital, but they are becoming more centralized while claiming to stay aligned with Ethereum.

My issue isn't with L2 existing - I think they are ultimately necessary for scalability. But Ethereum is far from its scalability limit. It may only be using 2% of its maximum capacity. The base layer still has a lot of room. Blockchains like Sonic, Avalanche, and Solana have shown that high throughput can be achieved on the base layer without L2. Focusing on L2 is premature and splits the ecosystem, harming composability and user experience.

L2 should be composable and interactive, but they have become a bunch of sidechains with centralized sequencer extraction fees to make money. This is not the original intention. The bigger issue is why this happened. Ethereum went through a typical corporate lifecycle: initially flexible, with fast R&D, rapid building, and continuous trial and error. As it gained attention and grew, it became cautious - adding compliance, oversight, testing, committees, and boards.

This bureaucracy has slowed it down, and it's now stagnant, too big to act quickly. Companies in this phase either shed excess parts and refocus on technical fundamentals or get outpaced by faster competitors. Ethereum is at this crossroads. We see internal turbulence - CEO changes, board reorganizations, Vitalik trying to speak out. I hope they refocus, because I'm loyal to Ethereum; that's why I'm involved in DeFi. But we can't wait for them to solve the issues.

Their research, like Ethereum Improvement Proposals, still sets the standard for the next two to five years, especially in user experience, account abstraction, and on-chain oracles. But most of this content was written between 2018 and 2020. The ideas exist; the implementation lags. 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 growth space.

My work on Phantom (now Sonic) proved this. When Ethereum used proof-of-work, we saw its throughput limited by block time restrictions. 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 the bottleneck, limiting us to 200 transactions per second.

We analyzed the EVM and found clear areas for improvement. The biggest issue was the database - LevelDB, PebbleDB, etc. - which spent most of their time on read and write operations. These databases were overkill for blockchain, designed for general queries, not the simple address-nonce-data structure of the EVM. We built SonicDB, a flat-file database tailored for blockchain, which boosted EVM throughput eightfold and reduced storage needs by 98%. Ethereum could achieve this tomorrow and gain massive benefits.

We also made other adjustments - new compilers, supersets, etc. - but the database was the easiest improvement to implement. Why aren't they doing it? Because they're risk-averse. Their technology handles hundreds of billions of dollars in assets, and any change is scary. The trade-off is losing SQL query functionality, but actually, no one uses SQL queries on large 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 sidelined.

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

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

If vulnerabilities are inevitable, better to have them early, when the risk is only $50, rather than later when it's $5 million. Build a social profile, communicate what you're doing and how, invite testing - hoping it's white hats, not black hats. Small vulnerabilities can be recovered from; big ones cannot.

If you can get 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 leave when they face the first crisis because the pressure is too much. Public building is a litmus test: you'll quickly know if you're fit 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 I hope we can do it again soon.

Andre Cronje: It's an honor. Let me know, and we'll do it again.