Vyper Compiler and EVM Runtime: Can a Failed Upgrade Be Rolled Back Without Recompiling Against the Original Version Pragma?

Short answer

Yes — treat the archived pre-upgrade runtime bytecode as the only trustworthy rollback artifact. Recompiling the pinned 0.3.x source with the original compiler is a useful verification step, not a substitute for the archive. And because Vyper has no delegatecall or proxy support, your external upgrade mechanism owns both the code pointer and the state problem: if the failed 0.4.x implementation wrote storage, rolling back code alone is not a recovery.

Why the archived bytecode wins

Vyper enforces its version pragma strictly, and 0.3.x → 0.4.x is a major-version jump. That means:

• Recompiling old source under a newer compiler may simply fail, or worse, succeed with changed semantics.
• ABI encoding, gas costs, and storage-layout assumptions can change across major versions. Treat them as breaking for your specific contracts until you have checked the release notes for the exact versions and flags involved.
• Even recompiling with the original 0.3.x compiler is not guaranteed to be byte-identical. Compiler metadata, build environment, and flag differences can change the output.

The practical acceptance test is a runtime-bytecode hash comparison, not source identity. If a recompiled artifact's runtime bytecode hash matches the archived deployment, you have evidence of reproducibility for that contract. If it doesn't, the archive is your only ground truth — which is why the archive must exist before any upgrade, captured from the chain or from the deployment pipeline at the time of the original deploy.

The state problem

This is the part most rollback runbooks underweight. A failed 0.4.x implementation may have already run an initializer or mutated storage. Even if slot positions look unchanged, the 0.3.x implementation can silently misinterpret values written under 0.4.x assumptions. Restoring the code pointer without addressing storage leaves you running old logic over foreign data.

The one diagnostic detail that changes the recommendation: does your external proxy keep its own storage separate from the implementation's state, or do they share one contract's storage? If storage is shared, state rollback is mandatory and must be part of the same procedure as the code swap. If state is cleanly separated and the failed implementation never touched shared slots, a code-only rollback may be sufficient — verify this rather than assume it.

Recovery procedure

1. Freeze upgrades and pause entry points that could write further state.
2. Snapshot current state so the failed attempt remains inspectable.
3. Point the proxy back to the archived 0.3.x runtime bytecode (or redeploy it and update the implementation address).
4. Restore storage to the pre-upgrade snapshot, or explicitly erase/migrate slots the 0.4.x implementation touched.
5. Run post-rollback invariants and critical flows before resuming normal operation.

Verify before you need it

Rehearse the whole sequence on a fork: snapshot, upgrade, induce failure, restore archived implementation and state, validate invariants. Also compare recompiled 0.3.x output against the archive now, during calm — that tells you whether reproducible rebuilds are a viable secondary artifact source or whether the archive is truly irreplaceable.

One caveat: exact reproducibility behavior and 0.4.x breaking-change details depend on the specific compiler versions and flags. Confirm against the Vyper release notes for your versions before finalizing the runbook.