When I first started creating Curve Finance in 2019, I had a choice to make. I could have followed the popular trend and used Solidity, which is arguably the most popular language for Ethereum smart contracts. But instead, I decided to pick a different route, going with Vyper instead.
The language was created by Vitalik Buterin to make smart contract development as readable and concise as possible. It reminded me of Python’s philosophy but tailored for Ethereum smart contracts. And seeing as I had already been a big fan of Python since around 2005, the decision felt obvious.
Admittedly, it did not go unchallenged — there had been quite a few investors that suggested I should rewrite everything in Solidity in order to gain their support. But I refused and stood by my choice. The safety and clarity of my code were more important than short-term investments.
Why Not Solidity, Then?
At this point, it’s probably appropriate for many of the readers to ask: so what was wrong with Solidity that I didn’t want to go with it?
My answer to that — it’s already showing cracks.
It’s true that Solidity’s sheer popularity can’t be ignored — today, it controls
Speaking practically, Solidity’s compiler is often plagued by various bugs, and they seem to get only worse with each new update. For example, Solidity’s bytecode optimizer often leads to unexpected errors. And while there are attempts to fix these issues, the solutions offered so far seem like temporary fixes more than anything. And they risk complicating the Ethereum Virtual Machine (EVM) even further, pushing it towards more technical debt.
The Problem of Technical Debt
The accumulation of “technical debt” is a significant issue in large projects. To put it simply, it’s about taking shortcuts — when code is written quickly but ineffectively to meet short-term goals. It often means skipping proper structure and testing, and, over time, these shortcuts build up.
Layers of poorly organized, overly complex code make the system harder to maintain and more prone to breaking. At the same time, the cost of actually fixing the code becomes massive — and that’s when technical debt starts dragging the entire project down.
One of the best-known examples of how technical debt can suffocate even a large-scale project is Yahoo. Despite its initial success, over the years, Yahoo’s infrastructure became overloaded with legacy systems and quick fixes. Eventually, the company couldn’t keep up with competitors who were building cleaner and more agile codebases. Even the developers who worked there cited technical debt and poor code management among the reasons Yahoo lost its competitive edge.
Solidity is at risk of following a similar path, since this debt has been growing steadily, especially within the compiler itself. Rather than refactoring the codebase and improving the core logic, some fixes — like the Ethereum Object Format (EOF) proposal — aim to patch issues like the “stack too deep” error by increasing complexity at the EVM level (or, if anything, fixing “stack too deep” is not the best way to advocate for a very complex upgrade of whole EVM). But this only adds more layers to an already complex system, only increasing the risk of future bugs.
Vyper, by comparison, has managed to keep technical debt to a minimum. There had been some, but it was gradually solved between versions 0.3.1 and 0.4.0. And from version 0.3.7 onwards, the language has undergone significant improvements, including complete internal refactoring and numerous security audits.
The Ethereum Foundation (EF) is also actively
Designed to be Clear
What makes Vyper stand out is its focus on clarity. Unlike Solidity, which often requires developers to jump between different parts of the code to understand the full picture, Vyper keeps related code together in a logical and easy-to-follow structure. This approach makes it easier to understand and audit. This structural clarity reduces the risk of errors, making the code more secure.
As Vyper continues to improve, the language is gaining more attention. With EF’s support and more funding injected into its development, Vyper is now a much stronger contender in the smart contract world. I wouldn’t be surprised if we saw the creation of a formally verified compiler sometime soon down the line — if that happens, it could set a new standard for security in the Ethereum ecosystem.
And it’s not just developers who see Vyper’s value. From what I can tell, many auditors who work with the language prefer its design and clear structure, since it makes it easier for them to spot issues and design flaws. Those would be harder to identify in a more convoluted code.
Vyper also has robust tooling support. There are test frameworks like Titanoboa, Ape, Mox, and Brownie that make it easy to write and test Vyper code, using Python libraries to streamline the process.
That is not to say that Vyper has no more challenges to overcome. It’s not as widely used as Solidity, and fewer developers are writing in it. But this isn’t the first time a minority language has faced this kind of struggle. Back in 2005, Python was a relatively niche language, while Java and PHP dominated. But over time, Python’s simplicity and power won over the development community, especially with the rise of AI and data science. I believe Vyper could follow a similar trajectory, especially as more people begin to recognize its benefits.
Final Thoughts
If I were launching a new company today, I’d make the same choice. I’d still choose Vyper because it gives me confidence that my code is secure and readable. It may not be the most popular option right now, but Vyper is built for the future. If we want to move the Ethereum ecosystem towards clearer, safer smart contract development, then Vyper is a great tool to get us there.
