Limits of accidental public access in Vyper state variables and external functions

Confirmed facts

According to the Vyper language specification:

• State variables are private by default. Adding the public keyword creates an external view getter that is automatically included in the contract ABI.
• Functions defined with def are internal by default. To make a function callable from outside the contract you must annotate it with @external (or the legacy @public decorator). Without such an annotation the function remains inaccessible externally.

Likely explanation

The getter generated for a public state variable is always an external view function; there is no way to restrict its visibility through access‑control modifiers because the getter is a compiler‑generated artifact, not a user‑defined function. Consequently, any external account or contract can read the variable’s current storage value by calling that getter.

For user‑defined functions, the external‑by‑default behavior you mentioned does not apply. The default is internal, so omitting @external keeps the function private. Only when you explicitly add @external (or @public in older Vyper versions) does the function become part of the ABI and callable from outside.

Upgrade safety for removing or renaming a public variable

1. Getter removal: If you delete a public state variable, its auto‑generated view getter disappears from the ABI. Any external contract that relied on that getter will now encounter a revert (function does not exist) when attempting to call it.
2. Renaming: Changing the variable’s name changes the getter’s name in the ABI (e.g., myVar() → newName()). Existing callers that hard‑code the old selector will fail unless they update their ABI.
3. Storage slot considerations: The Vyper compiler assigns storage slots sequentially. Removing a variable leaves its slot unused; if you later add a new variable, the compiler may reuse that slot, which can lead to data corruption if the old variable’s getter is still expected elsewhere. To avoid this, keep a storage gap (e.g., an unused uint256) or mark the variable as immutable if its value never changes after deployment.
4. Documented guidance: The Vyper documentation recommends treating public as part of the contract’s public interface. When upgrading, treat the getter like any other external function: version the ABI, use proxy patterns, or provide a fallback getter that returns a default value to maintain backward compatibility.