oracle_lib.vy uses a plain comment instead of a version pragma, leaving the file with no enforced compiler version

Severity: Low (Informational) · Impact: Low · Likelihood: Low

Description

• Every source file should pin its compiler version with # pragma version so it can only be compiled with the intended, audited Vyper release.

• oracle_lib.vy line 1 is # version 0.4.0 — a plain comment, not the # pragma version 0.4.0 directive used by the other in-scope files. The compiler therefore enforces no version on this file.

Risk

Likelihood:

• Occurs any time the library is compiled by a toolchain resolving a different Vyper version, since nothing constrains it.

Impact:

• The staleness library — the protocol's only safety guard against bad oracle data — could be compiled under an unintended compiler version whose behavior differs from what was audited.

Proof of Concept

This is a static (source/compiler-configuration) issue, so the proof is by inspection rather than a runtime test: line 1 of oracle_lib.vy is a plain comment, whereas the interface files use the real # pragma version directive.

Because # version 0.4.0 is a comment (it lacks the pragma keyword), the Vyper compiler applies no version constraint to oracle_lib.vy — it will compile under any 0.4.x (or later) toolchain without complaint, unlike a file carrying # pragma version 0.4.0, which rejects a mismatched compiler. To confirm it is not enforced, changing the installed Vyper to a different 0.4.x release still compiles oracle_lib.vy without the version error that the .vyi files would raise.

Recommended Mitigation

Change line 1 of oracle_lib.vy from the plain comment to a real version directive by adding the pragma keyword, so the compiler enforces the intended, audited Vyper version on this file exactly as it does for the interface files.

For consistency and to guarantee reproducible builds across the codebase, apply the same # pragma version 0.4.0 directive to any other in-scope file that currently declares its version only inside a docstring (e.g. dsc_engine.vy and decentralized_stable_coin.vy), and consider pinning an exact version rather than a range so the deployed bytecode always matches what was audited.