lfglabs-dev / lfglabs-dev/verity

feat(Codegen): true bytecode immutables (constructor-set values embedded in runtime code)

Open
#1,992 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement P2: important
Dominant language
Lean
Stars
148
Forks
20
Avg merge
1d 14h
Merged PRs (30d)
29

Description

Problem

Verity has no support for Solidity immutable variables. Constructor-set values that solc embeds in runtime bytecode must currently be modeled as ordinary storage slots.

Concrete instance from the Morpho Midnight port (Th0rgal/morpho-verity): INITIAL_CHAIN_ID is modeled as storage slot 1024 instead of a bytecode constant (Midnight/Contract.lean:2425), with the mapping doc noting "until immutable support lands".

Why it matters

  • Fidelity: slot-modeled immutables silently change the storage footprint vs the Solidity source, so storage-layout reports and the "source faithfulness" column cannot be exact.
  • Proof interaction: a phantom storage slot participates in frame/footprint reasoning (#1990) and storage non-alias certificates, where the real contract has no such slot.
  • Yul drift: solc emits immutables via setimmutable/loadimmutable in deploy/runtime code; Verity's output cannot shape-match this category.

Scope sketch

  1. EDSL surface: immutable NAME : Type declared in the contract block, assignable only in the constructor.
  2. CompilationModel: a distinct ImmutableRef value kind (not a storage slot), with deploy-time substitution semantics.
  3. Codegen: emit setimmutable / loadimmutable (or the equivalent literal-patching layout solc uses).
  4. Proofs: interpreter semantics treating immutables as deploy-time-fixed constants of the runtime environment; widen SupportedSpec accordingly.
  5. Reports: surface immutables in storage-layout/trust reports as a separate section (zero storage footprint).

Not covered elsewhere

Absent from #1982 (all tiers) and from #1724's open parity scope. Filed as a result of the 2026-06-12 Morpho fidelity analysis.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the immutable example at Midnight/Contract.lean:2425 and the related mapping note, then review the scope against #1990, #1982, and #1724. Done requires coordinated EDSL, compilation, code-generation, proof-semantics, and reporting support for deploy-time-fixed values without a storage footprint; the issue names no tests or implementation entry point.

Written by the indexing model from the issue text.

Assessment

Tech stack
solidity
Domain
blockchain, compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.