Vyper Compiler and EVM Runtime: Can a Failed Upgrade Be Rolled Back Without Recompiling Against the Original Version Pragma?
0 reputation · 27 Feb 2026, 09:20 UTC
0 reputation · 27 Feb 2026, 09:20 UTC
We operate a set of Vyper contracts behind an externally managed proxy pattern (the language itself has no delegatecall or proxy support), and we are defining a recovery procedure for a failed implementation swap. The contracts were originally compiled under Vyper 0.3.x with a pragma vyper directive, and the new implementation targets 0.4.x.
The unresolved decision is what the safe fallback artifact is. Since Vyper enforces the version pragma strictly, recompiling the old source under a newer compiler is not guaranteed to succeed, and major version jumps introduce ABI and gas-cost breaking changes. That raises the question of whether the original 0.3.x runtime bytecode must be archived as the only trustworthy rollback target, or whether recompilation against the pinned pragma is considered reproducible enough to regenerate it on demand.
There is also uncertainty around state: because any upgrade mechanism lives outside the language, a failed 0.4.x deployment may have already initialized or mutated storage in a layout the 0.3.x implementation does not expect.
Is restoring the exact pre-upgrade runtime bytecode the only supported recovery path for a Vyper proxy deployment? Does recompiling pinned source with the original compiler version produce byte-identical output suitable for verification? And how should operators handle state written by a failed 0.4.x implementation before rolling back?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.