Original author: The DCo Podcast, Blockchain in Plain Language
In the ever-changing and uncertain decentralized finance (DeFi) space, Andre Cronje’s name is undoubtedly important. As the driving force behind multiple projects such as YFI, Solidly, and Fantom, and now leading the development of Sonic as CTO, AC has left a deep mark on the forefront of crypto finance.
In this episode of The DCo Podcast, AC candidly reveals his views on the bottlenecks in DeFi development, the challenges facing the Ethereum ecosystem, and the harsh reality that builders must face in this field where idealism and profit-seeking coexist.
From wrestling with regulators to seeking a delicate balance between decentralization and user experience, his insights are both a warning to industry builders and an inspiration to all those who dream of DeFi.
Addressing the regulatory challenges of crypto assets
The DCo Podcast: Welcome to the show, Andre. You are known for founding Yearn Finance, Solidly, Phantom, and now you are the CTO of Sonic. It has been a crazy journey in the crypto space over the past few years. Can you share what the past three years have been like for you, especially the challenges you have faced and how you have dealt with them? I guess you should focus more on code now instead of dealing with regulatory issues.
Andre Cronje: Thanks for having 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 last four years have been a steep learning curve. I had to deal with things like the Eminence vulnerability, which was an important lesson about building in the open. Then with the Solidly project, I realized that the crypto space was shifting — people weren’t caring that much about true decentralization or immutability anymore.
On top of that, I battled the SEC despite being a South African who developed locally in South Africa, didn’t raise money from anyone, and didn’t sell tokens. They sent me a lot of letters and requests, and it was exhausting. I learned a lot and grew a lot from it, but it was hard. Do you have a specific topic you want to go into more, or should we keep it broad?
The DCo Podcast: I’d love to hear more about how you handled those SEC letters. Did you have legal help? How did you navigate the process, especially since it sounds like it was very overwhelming at first?
Andre Cronje: At first, I was naive. The initial letters seemed simple enough — just requests for information, with implicit threats of escalation if I didn’t cooperate. They asked questions like, “Who did you sell your tokens to?” The answer was simple: I didn’t sell them to anyone. Or, “How do you make money from the protocol?” Just as simple: I didn’t.
I thought that was the end of 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 work. It felt like they were trying to catch me making a mistake, rather than truly seeking information.
By the third letter, I realized I needed help. I hadn’t raised money, so I had to rely on my connections. I reached out to Gabriel at Lex Node, a prolific crypto lawyer who has worked with many DAOs. He was fantastic and provided a ton of support. Through him, I met Steven Palley, another veteran in the space who really knows his stuff.
Gabe did the bulk of the work early on, and Steven was heavily involved later on. They were critical because it’s not just about the information you provide — it’s how you present it. There are specific legal language you need to use to protect yourself.
This process evolved over time. At first, they focused on the tokens — did I sell them, who did I sell them to, etc. When they realized there was no way around that, they switched to focusing on how I could earn income from the protocol. When that didn’t work either, they argued that the vaults themselves were securities, citing the Howey Test, claiming that users give money to third parties with the expectation of a return. This was frustrating because they often asked me to prove the negative — like proving that Santa Claus doesn’t exist. You can’t do that definitively.
The reason the letters stopped was because of the upcoming election. I got the last letter about six to eight months before the election. I got a final letter a month ago saying they were not taking any further enforcement action, which was a relief. But the time and effort it took was crazy.
At one point, for three weeks straight, I did nothing but collect data for them—sometimes data I didn’t even own, like logs from a third-party hosting provider I didn’t have an agreement with. The consumption made it nearly impossible to do anything else.
The evolution and stagnation of DeFi
The DCo Podcast: Sounds pretty intense. You mentioned decentralization earlier and suggested that people are no longer prioritizing it. Do you think there is a tension between running a crypto project as a sustainable business and ensuring it remains decentralized? Is this why we are seeing a reduced focus on decentralization today?
Andre Cronje: It all depends on the market participants. Back when I launched Yearn, decentralization, self-custody, and immutability were very important. The market was full of tech anarchists—purists who were in it for the idea, not the millions of dollars. The old meme “I’m in it for the tech” was unironically true at the time.
But the player base has changed. Liquidity mining, the NFT craze, and now Meme coins have lowered the barrier to entry. You no longer need to be tech savvy — just install a wallet, click a few times, or log into an app with your fingerprint. I think 90% of the people in the market today don’t buy into the idea of technology. They’re in it for token appreciation or revenue, not the idea.
This creates a mismatch. If you’re building foundational DeFi primitives — things that other people can build on top of — they need to be immutable. You can’t have someone build a company on your primitives and then you change it and cause their system to break. For example, 90% of DeFi is still built on Uniswap V2 because it’s predictable and immutable. If Uniswap made V2 support proxy upgrades and changed the LP logic overnight, DeFi would break.
But today, projects are more siloed. Everyone is building their own AMM or lending market instead of using third-party primitives because those third-party systems are usually upgradeable. If you build an immutable product that depends on upgradeable systems, when they upgrade, your product may break. So 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. It’s a snowball effect: the more projects prioritize revenue, the less immutable infrastructure there is to build, so more projects follow this trend. In 2019, I wrote that we vote with our money. Where we put our money is what we get. In early 2021, people poured money into forks of Uniswap and Compound because they were “safe.”
New primitives are riskier — there’s a high risk of being hacked or exploited — so innovation stagnates. This is why memecoin is so popular right now. DeFi innovation has stagnated since 2022. We’ve built better products, like Hyperliquid, but they’re not new primitives — just iterations of existing primitives.
The DCo Podcast: You mentioned earlier that DeFi innovation has stagnated and composability — building on other products — has faded. Because liquidity is not shared, it becomes difficult to do things like use one asset as collateral across protocols. Is there enough incentive to break out of this siloed approach, and how can we achieve it?
Andre Cronje: This may sound a bit conceited, but the problem is that you need a rare combination of skills: the ability to program, but also the ability to come up with innovative ideas and primitives, and not need funding. The intersection is very small. I can use myself as an example, but its rare. Most builders need funding, but raising money and building are completely different skills.
I tried raising money — it wasn’t my strong suit, so I chose to build without it. Others had great ideas but struggled to pitch or network. Meanwhile, you’d see the 99th fork of the same project raise $50 million overnight because they knew the right people.
It’s hard for true builders to get the funding they need. Most people can’t afford to go six months without income to pay the bills. Hyperliquid is an exception — they didn’t raise money because their team had a successful market making business before and had the resources to build and even do a massive airdrop.
But if you raise money, you face the pressure of venture capital. VCs are in it for ROI, not because they believe in your vision. That is their responsibility, which leads to misalignment of goals.
Historically, in traditional finance or Web 1/Web 2, companies built stable businesses and spun out small RD teams to test new ideas. We’ve seen some of this in crypto — like Aave launching GHO, Lens, or Family — but not enough. The social and reputational risks are too high. If a sub-product is exploited, even for just $50, the headlines will say the main project was hacked. The risk is not proportional to the reward.
So, it’s a difficult problem with no immediate solution. Most developers would be crazy to even try — it takes a masochistic streak to deal with exploits and reputational damage.
The DCo Podcast: Let’s revisit DeFi primitives. You mentioned that new primitives are being developed. 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 perfect. We are stuck with constant product formulas like X*Y=K. Curve Finance introduced stable swaps, and I introduced X 3 Y through Solidly, but innovation stagnated there.
As blockchain speeds increase, dynamic liquidity market makers (DLMMs) are emerging, which is progress. There is still a lot of work to be done on AMMs - new curves, trading methods, and liquidity provision strategies.
The next big breakthrough is on-chain oracles. DeFi avoids using them due to fear of exploitation, but we can make them safe through different implementation methods. Without oracles, we lack critical data such as volatility, implied volatility or order book data. Once we have powerful on-chain oracles, we can build proper pricing models, Black-Scholes calculations, and European or American options. This will open up on-chain perpetual contracts and delta neutral strategies, which are not possible now.
Look at traditional finance: futures and options dominate, but they are barely on-chain. The roadmap is clear - you need data first, but everyone is afraid to build it. You can implement strong security schemes entirely on-chain, or use off-chain oracles with zero-knowledge proofs or decentralized methods to avoid trusting intermediaries.
On top of that, insurance primitives are missing. There is a huge untapped space in DeFi. It’s still early days, and if we can overcome our fear of innovation, the potential is huge.
Balancing decentralization and user experience
The DCo Podcast: Do you think UX and decentralization are inherently contradictory? Is that part of the problem?
Andre Cronje: Absolutely, 100%. True decentralization means no website, no third-party browser - just downloading the node software, running a local node, and submitting transactions through the command line interface (CLI) to interact with immutable smart contracts. This requires deep technical knowledge - syncing software, encoding transactions with base64 hashes, not just calling JSON RPC. There are probably only 10,000 people in the world who can do this, or even less.
On the other hand, a great user experience means that users don’t need private keys or gas fees. Look at the successful Solana applications: you download a mobile app, log in with Google or Face ID, and click a button. This is far from decentralization and is something else entirely.
Today’s successful apps hide more 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 held in a wallet they control, and the private keys are held on their servers. It’s a great user experience, but it’s centralized.
My approach is to build for the decentralized ideal first - raw on-chain contracts that CLI users can interact with on their own nodes. Then I add abstraction layers on top of that: an API that simplifies operations, saves users from having to use wallet passkeys, or gas fee abstractions. Ultimately, you end up with an interface where users just click buttons, which translates operations into transactions to the smart contract via the API and signing wallets.
This is the right way, but for the few who can use the CLI, it requires a lot of additional infrastructure and may seem futile. Decentralization and UX are like security and UX - real security requires complex passwords, isolated systems, and key rotation, but users wont do that for a free gaming app. Historically, when security conflicts with usability, usability always wins. Decentralization will be no different.
The goal is for users to not know 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 features first-class citizens of the blockchain so that users get a great user experience without having to trust a third party.
We do it manually now with these centralized solutions, but we will codify them into decentralized systems. Its like when I first started programming: manual first, then automated. 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: Let me answer the second question first. The limit depends on what users are willing to tolerate, which varies from app to app. For free mobile games, users expect zero friction - install and play. If a username, password or social account connection is required, they will not bother because the perceived value is low.
But for a banking app with $100,000, the user may accept two-factor authentication or an extra step because the value is high. Every app must find that balance based on the psychological value that the user places on it.
Currently, there aren’t many options for crypto applications. Whether it’s a game or a DeFi protocol, you need to download a wallet, protect your keys, recharge gas for them, and sign messages. This is a high barrier to entry. We saw something similar in cybersecurity in the mid-2010s - websites required 32-bit signed passwords, but users forgot their passwords and resetting them became a hassle. Eventually, applications allowed users to decide their own level of security while providing some backend protection. The crypto space will develop similarly.
For the first question — how do 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), lays out the blueprint for the next five years. Features like action bundling 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 huge. The roadmap is there; it’s all about execution. But few teams are willing or able to do it. Ideas are cheap — execution is everything. I think we’ll see big improvements this year, like full on-chain gas and account abstraction, meaning no wallets or gas required. This is a huge leap in UX — users don’t need to know which blockchain they’re on, or use MetaMask. It’s coming, probably this year or next, but the roadmap is clear.
Ethereum’s Challenges and Suggestions for Developers
The DCo Podcast: You mentioned Ethereum. What do you think of its current state? There has been a lot of criticism that it has no direction, lacks implementation focus, or that everything is fragmented by only scaling through Layer 2 (L2).
Andre Cronje: I have been very vocal about L2 being a waste of time and energy. The resources and money being put into it is part of the misalignment problem I mentioned earlier - we vote with our money. When only forks of known applications get funded, thats all we see. Now, L2 is sucking up capital, but they are becoming more centralized while claiming to be aligned with Ethereum.
My issue isn’t that L2s exist — I think they are ultimately necessary for scaling. But Ethereum is nowhere near its scalability limits. It’s probably only using 2% of its maximum capacity. There’s a lot of room for base layers. Blockchains like Sonic, Avalanche, and Solana have demonstrated that high throughput can be achieved at the base layer without L2s. The focus on L2s is premature and fragments the ecosystem, hurting composability and user experience.
L2s were supposed to be composable and interactive, but they turned into a bunch of sidechains with centralized sorters extracting fees for profit. This was not the original idea. The bigger question is why this happened. Ethereum went through a typical company life cycle: nimble at first, rapid RD, fast builds, trial and error along the way. As it gained traction and grew, it became cautious — adding compliance, oversight, testing, committees, and boards.
This bureaucracy slowed it down, and now it’s stagnant, too big to move fast. Companies at this stage either divest themselves and refocus on their technological roots, or get overtaken by faster competitors. Ethereum is at this crossroads. We’re seeing internal turmoil—CEO changes, board reshuffles, Vitalik trying to take a stand. I hope they can refocus because I’m loyal to Ethereum; that’s why I’m involved in DeFi. But we can’t wait for them to figure it out.
Their research, like Ethereum Improvement Proposals, still sets the standard for the next two to five years, particularly in terms of user experience, account abstraction, and on-chain oracles. But most of it was written between 2018 and 2020. The ideas are there; implementations lag. In terms of scalability, Ethereum’s base layer only uses 2% of its capacity. Even without layer 2 solutions, there’s plenty of room for growth.
My work at Phantom (now Sonic) proved this point. When Ethereum used proof of work, we saw that it limited throughput by setting block time limits. We redesigned the consensus mechanism to use an asynchronous Byzantine Fault Tolerant (BFT) system and achieved 50,000-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 found clear areas for improvement. The biggest problem was databases — LevelDB, PebbleDB, etc. — which spent most of their time in read and write operations. These databases were overkill for blockchains, designed with general-purpose queries in mind, not the simple address-nonce-data structures of the EVM. We built SonicDB, a flat-file database custom built for blockchains, which increased EVM throughput eightfold and reduced storage requirements by 98%. Ethereum could do this tomorrow and reap huge benefits.
We made other tweaks — new compilers, supersets, etc. — but the database was the lowest hanging fruit. Why didn’t they do it? Because they’re risk averse. Their technology handles tens of billions of dollars in assets, and any change is scary. The tradeoff is losing SQL query capabilities, but no one actually uses SQL queries on large-scale blockchain data — tools like Dune or Tenderly process transactions individually. It’s not really a loss, but Ethereum’s resistance to change is so strong that even low-risk improvements are put on hold.
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 space?
Andre Cronje: My advice has evolved. To be honest, developing in crypto is not the smartest choice - other fields are simpler, more secure, and have less negative impact. But if you decide to do it, do it publicly. Share your work on Twitter, open source your GitHub, let people see and test your code. Build a community of contributors, not just exploits.
If a breach is going to happen, it’s better to do it early on, when the risk is only $50, rather than $50 million later when it’s open. Set up a social profile, communicate what you’re doing and how you’re doing it, invite testing — hopefully white hat, not black hat. Small breaches are recoverable; big ones are not.
If you have access to funding, prioritize security. Work with teams like TRM, Chainalysis, or Seal Team 6 to conduct audits and red team exercises. Audits from companies like SlowMist are essential. Learn how to handle security disclosures and emergencies early on.
This field isnt for everyone - some people leave at the first crisis because its too stressful. Public construction is a litmus test: youll know quickly if youre a good fit. Accept it, youll either find your place or realize its not for you.
The DCo Podcast: Thanks for your time, Andre. I enjoyed this conversation and I hope we can do it again soon.
Andre Cronje: Its a pleasure. Let me know and well do it again.
