Vyper `constant` removal creates 0.2.x to 0.3.0 compatibility boundary

Bottom line

No. Replacing a Vyper 0.2.x `constant` with a Vyper 0.3.0+ `immutable` does not preserve storage slot offsets. In 0.2.x, `constant` is storage-backed and occupies a slot; in 0.3.0+, `immutable` is fixed at deployment and embedded in bytecode, consuming no storage slot. Recompiling removes that slot and shifts later state variables, so off-chain indexers reading hardcoded offsets break even if a same-named getter returns the same value.

Explanation versus confirmed facts

The likely explanation is a semantic change, not a syntax rename: storage-backed constants were replaced by deployment-time constants baked into bytecode. Within the stated version assumption of Vyper 0.2.x versus Vyper 0.3.0+, confirmed facts are that `constant` is no longer recognized in 0.3.0, identical source cannot compile under both compilers, and `immutable` values must be assigned in `__init__` and cannot change after deployment. Exact annotation syntax and getter generation for 0.3.0 should be confirmed against the Vyper release notes for your target version; I treat that detail as pending verification.

Gas and access-pattern differences

• Storage-backed `constant` reads use SLOAD; `immutable` reads come from embedded bytecode and usually cost less gas.
• `immutable` consumes no storage slot, so it cannot be read by querying a raw storage offset.
• Many or large immutables increase deployed code size and deployment gas, potentially approaching contract size limits.

Steps for this case

1. Pin the compiler per deployment: keep existing deployed contracts on their 0.2.x artifacts and do not recompile them with 0.3.0.
2. For new 0.3.0+ contracts, use `immutable` only for values fixed at deployment that never need upgrades.
3. For values that must keep their storage slot or remain upgradeable, keep a normal storage variable with a getter instead of `immutable`.
4. Update off-chain indexers to call public getters rather than reading raw storage slots, and confirm getter selectors match the old ABI.
5. Compile under both pinned versions locally and compare ABI selectors, storage-layout maps, bytecode, and getter traces for SLOAD usage before any mainnet change.

Missing diagnostic detail

Do your off-chain indexers read storage slots directly, or only call public getters? Direct slot reads require a storage-backed variable; getter-only reads can tolerate `immutable` if selectors match. This detail determines whether `immutable` is acceptable or whether you must preserve a storage slot.

Verification

Confirm the pinned compiler version before compiling. Deploy both builds to a local fork or testnet, call the getter, and query the old storage slot directly to confirm whether reads hit storage or bytecode-backed data. Check the Vyper changelog and docs for the target version to confirm `constant` removal and `immutable` semantics before adopting this migration.