Brownie ❤’s Vyper

…and sneks love that chocolatey goodness, too.

Ben Hauser
Feb 5 · 4 min read
Go easy on me, I’m a dev not a designer!

A long winded preamble…

If you’ve ever written a smart contract, you probably have a few strong opinions about Solidity. It’s the language we all —syntax close enough to JavaScript to lull you into a false sense of security, but riddled with bizarre design choices and hidden gotchas. Many a developer has confidently dove in, written what appeared to be quality code, and proceeded to . But over the years we have collectively as we embraced Solidity’s peculiarities. We have constructed financial behemoths from it, placing our trust (and our life savings) in immutable and esoteric gas efficient spaghetti.

I like to think that I can write with the best of them, and a lot of ’s debugging capabilities are a result of my experiences. But I’ve also often wondered if maybe we’re doing it wrong? Solidity can be a powerful tool when wielded by the initiated, but there is an inverse correlation between an efficient smart contract and a readable smart contract. Be clever; but not too clever or you might lose all the funds. And when the majority of smart contracts are ERC20s or crowdsales, with simple logic handling the very real money of many people who lack an ability to read code — should we really be clever at all?

Enter Vyper 🐍

is a smart contract language focused on security, auditability, and simplicity. It is a community-driven project inspired largely by experiences that the developers have had in writing and auditing smart contracts.

The syntax and flow of Vyper is designed to maximize readability and security. To achieve this, Vyper includes features such as overflow checks, strong typing, and fixed point decimals. On the other hand, certain functionality is intentionally limited to prevent opportunities for insecure or hard-to-read code. Modifiers, inheritance, overloading, infinite-loops; these simply aren’t possible in Vyper.

“Vyper does not strive to be a 100% replacement for everything that can be done in Solidity; it will deliberately forbid things or make things harder if it deems fit to do so for the goal of increasing security.”

Ultimately, it’s about having the right tools for the job. Vyper doesn’t allow contracts to be as complex as those written in Solidity so there are some situations where it just won’t fit. But for cases where the job doesn’t require a high degree of complexity (I’m talking to you, ICO tokens), it provides more readable code with significantly less hidden pitfalls.

Love at first bite!

So I’m thrilled to announce that as of , offers full support for Vyper smart contracts. , , , — if Brownie can do it in Solidity, it can do it in Vyper. And I’ve gotta say, I’m definitely biased but it feels pretty damn good using a Python framework on a Pythonesque smart contract language. 🐍 🐍

I’ve also been working with the Vyper team on further developing the language and compiler. Nobody is keeping score and I’m aware that coding isn’t meant to be competitive, but I’m currently #4 in (suck it, Vitalik). We’re getting along so well that they even let me feature Brownie in the for testing contracts.

“…but I heard the Vyper compiler is full of errors!”

The Vyper compiler is still in beta and not without issues. Unfortunately it’s had a run of bad press lately as a few prominent folks in the community decided to distance themselves from it. And while I do agree that we need to be cautious when compiling code that’s destined for immortality on our favorite blockchain, I think a sanity check is in order.

Here’s the thing: building a compiler is a big job! And it’s done by humans, those squishy pink things with a proven track record of getting stuff wrong. Regardless of if you’re using Vyper or Solidity, operating on the assumption that your compiler is bug-free is a flawed stance to take. You should always assume that the compiler might be wrong. And for this reason it is absolutely vital to have multiple layers of verification of your code before the actual deployment.

An audit is not the be-all-end-all golden stamp of error free code. Prior to external review, a well developed project will employ practices such as static analysis, thorough unit testing and fuzz testing. As a good friend of mine says, these techniques “are the holy trifecta of what makes code good enough”.

Which.. oh hey, what do you know? can help you with all of that 😎

Now go write some code!


Coinmonks is a non-profit Crypto educational publication. Follow us on Twitter @coinmonks Our other project —

Ben Hauser

Written by

I like to buidl stuff.



Coinmonks is a non-profit Crypto educational publication. Follow us on Twitter @coinmonks Our other project —

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade