I wrote the first version of this article in December 2025 and repeated a few numbers I had not checked. Rewriting it in September 2026, two of them turned out to be wrong and two more could not be reproduced at all.
So this time I compiled the same contract with both languages and measured what came out.
The short version: for one minimal ERC-20, Vyper produces about a third less deployed bytecode than Solidity and costs roughly 12% less to deploy. Per-call gas is within 2.5%, because storage dominates and neither compiler can do anything about storage. The choice of pipeline inside Solidity moves runtime gas about as much as the choice of language does.
The more consequential change since December has nothing to do with codegen. Solidity's compiler team left the Ethereum Foundation, incorporated as an independent collective, and secured five years of runway. Vyper is maintained by a handful of people on annual protocol grants; the largest I could find is $100,000 from Lido.
What the first version of this article got wrong
Four things, stated plainly.
"Starting in Vyper 0.4.2, functions are non-reentrant unless explicitly marked." They are not. Vyper 0.4.2 added a file-level pragma, #pragma nonreentrancy on, which turns on the lock for every external function and public getter in that file. The documentation is explicit that "the default is #pragma nonreentrancy off" and that this is "to prepare for a future release, probably in the 0.5.x series, where nonreentrant locks will be enabled by default language-wide." The pull request that added it says the same thing. It is opt-in today.
"The via-IR pipeline can reduce deployment costs by 20-30% in complex contracts." I had no source for that, and for the contract I measured it is backwards: --via-ir made the deployment 0.9% more expensive and the deployed bytecode 19 bytes larger, while cutting runtime gas by between 0.9% and 6.6% depending on the call. My test contract is small, so this does not disprove the claim for large ones — but I am not going to keep repeating a number I cannot produce.
"Scraping 977k GitHub repositories… Solidity powers 16,363 projects (98.7%) compared to Vyper's 215." I could not reproduce that scrape, so the figure and its chart are gone, along with the "90% of developers use Solidity, 5-10% use Vyper" survey claim, which cited no survey.
The "Community perspectives" section. It quoted anonymous opinions from X. Those are not evidence and the section has been deleted rather than rewritten.
Two smaller corrections to the compiler landscape section, which this rewrite folds into the Solidity section below. Huff's compiler repository has been archived since October 2024, so listing it as a live option was misleading. And solx is no longer a ZKsync project — the compiler team moved to Nomic Foundation, where it was released as slang-solx in September 2026 with the explicit warning that "it is not safe for mainnet deployments."
One contract, six compilers
The measurement is deliberately narrow: a minimal ERC-20 with transfer, approve, and transferFrom, written twice with matching semantics and an identical external ABI, no libraries on either side.
Here is transfer in each, verbatim from the files that were compiled:
function transfer(address receiver, uint256 amount) external returns (bool) {
balanceOf[msg.sender] -= amount;
balanceOf[receiver] += amount;
emit Transfer(msg.sender, receiver, amount);
return true;
}
@external
def transfer(receiver: address, amount: uint256) -> bool:
self.balanceOf[msg.sender] -= amount
self.balanceOf[receiver] += amount
log Transfer(sender=msg.sender, receiver=receiver, value=amount)
return True
Same checked arithmetic, same event, same revert on underflow. The visible differences are cosmetic; the differences that show up in the bytecode are not.
Both versions were compiled, deployed from raw creation bytecode into the same EVM, and checked against each other before anything was timed. All six deployments return the same name, symbol, decimals, supply, balances, and allowances, and all six revert on an overspend rather than wrapping.
The variants:
| Key | Compiler | Settings |
|---|---|---|
sol-legacy |
solc 0.8.36 | optimizer on, 200 runs, default codegen |
sol-via-ir |
solc 0.8.36 | optimizer on, 200 runs, --via-ir |
vy-0.4.3 |
vyper 0.4.3 | default codegen |
vy-0.4.3-venom |
vyper 0.4.3 | --experimental-codegen (Venom) |
vy-0.5.0b1 |
vyper 0.5.0b1 | default codegen |
vy-0.5.0b1-venom |
vyper 0.5.0b1 | --experimental-codegen (Venom) |
Solidity 0.8.36 is the current release, published 9 July 2026. Vyper 0.4.3 is the current stable release, published 19 June 2025; 0.5.0b1 is the beta published 1 September 2026 and is included to show where Vyper is heading, not as a production recommendation.
Both sides target EVM version prague and have their compiler metadata trailer disabled, so the size comparison is codegen against codegen. Gas was measured with gasleft() around each call from a Forge test on an Apple M3 Pro, using Foundry 1.5.1. The complete project is in the repository under examples/articles/solidity-vs-vyper.
What the numbers actually say
The full table, in gas except where noted:
| solc, default | solc, --via-ir |
vyper 0.4.3 | vyper 0.4.3, Venom | |
|---|---|---|---|---|
| Deployed bytecode (bytes) | 1,390 | 1,409 | 927 | 875 |
| Deployment | 402,519 | 406,176 | 352,434 | 341,995 |
approve, zero to non-zero |
24,984 | 24,764 | 24,654 | 24,650 |
transfer to a new holder |
30,237 | 30,005 | 29,753 | 29,735 |
transfer to an existing holder |
3,537 | 3,305 | 3,053 | 3,035 |
transferFrom |
26,031 | 25,604 | 25,376 | 25,311 |
balanceOf (view call) |
949 | 916 | 741 | 738 |
Three things stand out.
Vyper's output is much smaller. 927 bytes of deployed code against Solidity's 1,390, a third less, and 875 with Venom enabled. That is not a rounding difference. Contracts are capped at 24,576 bytes by EIP-170, and bytecode size limits were reported as a recurring problem by 33% of respondents to the Solidity Developer Survey 2025. Vyper's restrictions — no inheritance, no function overloading, no inline assembly — mean there is simply less machinery to emit.
Deployment is meaningfully cheaper. 352,434 gas against 402,519, about 12% less, and 15% less with Venom. Deployment happens once, so this matters most to factory patterns and to anyone deploying the same contract across many chains.
Per-call gas is nearly identical. transferFrom costs 26,031 under default solc and 25,376 under Vyper. That is 655 gas, 2.5%, on a call where two SSTOREs to already-dirty slots account for the bulk of the cost. The compiler cannot optimize away a storage write.
The pure-execution differences are only visible where storage is not in the way. A transfer to a holder who already has a balance costs 3,537 gas under default solc and 3,053 under Vyper — 13.7% less. A balanceOf view call costs 949 against 741 — 22% less. Real, and irrelevant to almost any user-facing fee.
The comparison that surprised me most is not between the languages at all. Going from solc's default pipeline to --via-ir closes most of the runtime gap on its own: transfer to an existing holder drops from 3,537 to 3,305, and transferFrom from 26,031 to 25,604. Meanwhile the Solidity survey found that only 43% of respondents use the IR pipeline at all, and 35% "don't know what the IR pipeline is."
A lot of the gas people attribute to their language is really attributable to a compiler flag they have not turned on.
What this does not prove
One small contract on one machine. A real protocol has inheritance, libraries, proxies, complex storage, and hot paths that this one does not exercise, and any of those could move the ratio in either direction. Fifty lines of token is not a protocol.
I also did not compare the two languages on anything except output. Compile time, error quality, debuggability, and how easy each is to audit are not in these numbers, and for most teams they matter more than 655 gas.
Solidity's compiler now belongs to someone else
This is the change I most underestimated in December.
The Solidity team left the Ethereum Foundation. In October 2024 they announced the Argot Collective, formed from "around 25 current Ethereum Foundation employees, specializing as compiler engineers, verification experts, and programming language theorists," with a flat salary structure and consent-based governance. The compiler repository moved with them: github.com/ethereum/solidity now redirects to github.com/argotorg/solidity.
The funding is unusually concrete for open-source infrastructure. Argot was seeded with an Ethereum Foundation grant specified as five years of operational runway at an ETH price of $2,592. The first three years were paid out in 2025; on 30 June 2026 the remaining two years — approximately 4,938 stETH — were placed in contracts behind a 2-of-3 multisig held by Argot, the Ethereum Foundation, and a five-member independent Fail-Safe Committee, unlocking in July 2026 and July 2027.
Argot's project list is Solidity, Fe, hevm, act, Sourcify, and ethdebug. Vyper is not on it.
The compiler itself has kept moving. Solidity 0.8.36 shipped on 9 July 2026 with two medium-severity fixes and support for the "Amsterdam" EVM version. It also removed the experimental EOF backend, which had been built in anticipation of the Fusaka upgrade and became obsolete when EOF was "ultimately rejected from that upgrade late in the process."
The interesting work is the SSA-form control-flow-graph code generator introduced in 0.8.35 and extended in 0.8.36 with stack-to-memory spilling. This is aimed squarely at stack-too-deep, the survey's number one pain point at 47% overall and 65% among experts. It is still behind --experimental --via-ssa-cfg and is not the default for --via-ir, and Argot's roadmap names "stabilizing the SSA-CFG pipeline and moving it out of --experimental" as the team's main objective for the rest of 2026.
Core Solidity — the redesign with algebraic data types and pattern matching, generics, traits, type inference, first-class functions, and compile-time evaluation — has reached the point where contracts compile end to end, with production implementation planned to start after the foundational work lands. Only 30% of surveyed developers had heard of it. It is a multi-year project, not something to plan around this year.
Vyper is alive, small, and slower to ship
Vyper is genuinely maintained. The repository took 161 commits in the six months to 8 September 2026, and the last push was the day I checked. But it is a small team: in the most recent 90 days, three people wrote 56 of the 77 human commits.
But the release cadence tells a different story from Solidity's. The current stable release, 0.4.3, came out on 19 June 2025 — fifteen months ago. Since then there have been three 0.5.0 alphas and, on 1 September 2026, 0.5.0b1. Solidity shipped six releases in that window.
Venom, the LLVM-inspired IR the first version of this article described as delivering "automatic gas optimizations," is still experimental. You get it with --experimental-codegen or --venom-experimental, and the standard JSON input's experimentalCodegen defaults to false. It is not what you compile with unless you ask for it. Turning it on shrank the deployed bytecode by 5.6% in my test, which is the same order as the project's own claim — the 0.4.2 release notes describe its Venom work as making "benchmark contracts… typically 5% smaller." It changed runtime gas by at most 0.6% on any call I measured.
Funding is the structural difference. Vyper's development has been carried by protocol grants — Lido approved $100,000 for 2024-2025, the third consecutive annual grant of that size, with Curve and Optimism contributing to the security budget as well. Vyper was also added to the Ethereum Foundation's bug bounty programme for compiler bugs in September 2024, with bounties up to $250,000.
That is real support, and it is not nothing. It is also a $100,000-a-year grant cycle against a five-year runway for twenty-five people, for a language whose contracts hold billions of dollars.
The security record, stated fairly
The first version of this article said Vyper 0.4.2's nonreentrancy work "directly address[ed] the vulnerability class that caused the 2023 Curve hack." That is imprecise in a way worth fixing, because the 2023 bug was not a missing lock.
Vyper's own advisory GHSA-5824-cm3x-3c38, published 5 August 2023, describes it as "incorrectly allocated named re-entrancy locks" in versions 0.2.15, 0.2.16, and 0.3.0, fixed in 0.3.1. Different functions that were supposed to share one lock were assigned different storage slots. The guard was written, compiled, and deployed — it just did not guard. Several Curve pools were drained as a result.
Making locks the default protects contracts whose authors forgot to add one. It would not have prevented a compiler that mis-allocated the locks it was told to add.
What did change after 2023 is process. Vyper's September 2024 security review records 12 audits, two security experts on retainer, two bug bounty programmes, a CodeHawks competition with $160,000 in prizes, and Snakepit — a monitoring system built with ChainSecurity that indexes "over 30,000 contracts" across 23 chains so the team can find at-risk deployments when a new bug surfaces. The project publishes its advisories, and every one filed against 0.4.x has been low or medium severity.
The symmetry matters here, because Solidity's compiler has bugs too, and they are not all historical. Solidity's own bug list records TransientStorageClearingHelperCollision, high severity, introduced in 0.8.28 and fixed in an emergency 0.8.34 release in February 2026, shipped within a week. 0.8.36 fixed two more, one of which could silently reverse a contract's inheritance linearization and change the order in which state variables initialize and constructors run.
Neither compiler is a safe assumption. Both publish their failures, which is the part that actually helps you.
Tooling: the gap is narrower than it was
The old complaint about Vyper was that you had to build your own workflow. That is much less true now.
Foundry compiles .vy files natively. Drop one in src/ with vyper on your PATH and forge build picks it up:
$ forge build
Compiling 1 files with Vyper 0.4.3
Vyper 0.4.3 finished in 175.57ms
Compiler run successful!
No plugin, no FFI deployer contract, no template repository. The community VyperDeployer workarounds that most tutorials still show are no longer necessary.
Hardhat is the opposite story, and it is the sharpest tooling constraint on Vyper today. @nomiclabs/hardhat-vyper still exists, but the version that works is @nomiclabs/hardhat-vyper@hh2 — 3.1.2, which peer-depends on hardhat@^2.26.0. The package published as 4.0.0 in February 2026 is a stub whose own README says it "does not work with Hardhat 2 nor 3." There is no hardhat-vyper package in the Hardhat 3 monorepo at all.
So Vyper support in Hardhat runs on Hardhat 2, which Nomic Foundation announced in June 2026 is being retired: no Hegota support, and end of life at Hegota activation or 1 June 2027, whichever comes first. If your workflow is built on Hardhat 3, Vyper is not currently an option, and Foundry — which I have benchmarked against Hardhat 3 — is the practical path.
The real remaining gap is libraries. Solidity has OpenZeppelin Contracts under MIT and Solady for the gas-sensitive paths. Vyper's equivalent is snekmate, which is well regarded and used by Curve — but it is licensed AGPL-3.0, not MIT. That is a licensing decision worth making deliberately rather than discovering during an audit.
Which one should you use
Nothing in the measurement changes the default. Solidity is where the libraries, the auditors, the tutorials, and the hiring pool are. As of 8 September 2026, GitHub reports 294,880 repositories whose primary language is Solidity against 635 for Vyper — a number to treat as directional rather than precise, because most Vyper contracts live in repositories GitHub classifies as Python.
There is no trustworthy measure of language share. The Solidity Developer Survey is answered by Solidity developers, so it cannot tell you anything about Vyper. DefiLlama's language breakdown gives Solidity 87.9% of tracked TVL and Vyper 0.88% on 8 September 2026, but it attributes exactly two protocols to Vyper — Curve DEX and Yearn Finance — and none of the mixed codebases, so treat it as a floor rather than a share. Anyone quoting you a clean percentage made it up, and so did I in December.
Reach for Vyper when the contract is small, self-contained, holds a lot of value, and will be read carefully by people who are not you. Vaults, AMM math, staking logic. The restrictions that make it a poor fit for a large system are the same restrictions that make it a good fit for a contract you want an auditor to hold in their head. The smaller bytecode and cheaper deployment are a genuine bonus, and Vyper's design principles — bounded loops, no recursion, "decidable gas consumption: every function call has a calculable upper bound" — are exactly the properties that make a contract cheap to reason about.
Stay on Solidity when the project is a system rather than a contract: multiple contracts, inheritance, proxies, an existing library dependency, or a team you need to hire for. That covers most projects, and it is the honest answer.
And if you are on Solidity, turn on --via-ir and measure. For my contract it recovered most of the runtime gas gap with Vyper, and 57% of survey respondents either do not use it or have not heard of it. That is a cheaper win than changing languages.
The conclusion from December still holds: the EVM is better off with both. But the reason has shifted. It is no longer that Solidity is flexible and Vyper is safe — Solidity's compiler is being rebuilt around exactly the correctness and stack-depth problems that motivated Vyper, and Vyper's biggest constraint is now funding rather than design.
What Vyper still provides is a second implementation with different assumptions. When solc ships a high-severity codegen bug, and it did in February, the value of a contract compiled by something else is not academic.