Ask
Every repo that deploys needs a per-release snapshot of its deployment record — at minimum the Zoltu address, creation bytecode, runtime bytecode and codehash — generated (not hand-written) and frozen under src/generated/<tag>/, one dir per published release.
This repo deploys and carries hardcoded deploy constants today, with no per-release record.
Why hardcoded pins are not enough
A hand-maintained address/codehash/creation-code literal is a second source of truth: nothing generates it, so nothing enforces that it still matches the code. The usual guard — a testDeployAddress / testExpectedCodeHash / testExpectedCreationCode trio — proves only that today's build agrees with today's constants. It says nothing about the releases already published, which is the thing consumers actually pin against.
Without a frozen per-release record:
- No published release can be reproduced or independently verified once the current build diverges.
- A consumer of an older release has no way to get that release's addresses.
- The single "current" pin collides with every bytecode-changing PR — the prod-deploy test goes red until a redeploy (the premerge chicken-and-egg).
Zoltu addresses are a pure function of creation code, so the whole record is computable offline — this needs no network, no registry, and no skips.
How
Use the shared LibSnapshot from rain-sol-codegen (published in 0.1.1) — do NOT hand-roll a copy (that is how the canon ended up copy-pasted across four repos with the safety guard in only half):
LibSnapshot.deployTag(vm) — [package].version with dots→underscores.LibSnapshot.freezeSnapshot(vm, contractNames) — freezes the generated pointers into src/generated/<tag>/, reverting rather than rewriting a frozen record without a version bump.- Add
{ access = "read", path = "foundry.toml" } to fs_permissions (needed by deployTag).
- Verify with a deterministic, offline test that re-derives the record and asserts no drift.
Reference implementation: rainlanguage/rain.math.float#253 — same migration end to end (generate the record via a locally etched Zoltu factory, freeze per tag, retire the hand-pinned literals into their snapshot, keep the public constant names as aliases so consumers do not break).
Related
This repo specifically
It already has script/BuildPointers.sol, so this is the smaller shape of the migration: extend it to generate the deployment record (Zoltu address + codehash + creation + runtime bytecode) alongside whatever it generates today, then call LibSnapshot.freezeSnapshot. No new codegen machinery is needed — just the record plus the freeze.
Ask
Every repo that deploys needs a per-release snapshot of its deployment record — at minimum the Zoltu address, creation bytecode, runtime bytecode and codehash — generated (not hand-written) and frozen under
src/generated/<tag>/, one dir per published release.This repo deploys and carries hardcoded deploy constants today, with no per-release record.
Why hardcoded pins are not enough
A hand-maintained address/codehash/creation-code literal is a second source of truth: nothing generates it, so nothing enforces that it still matches the code. The usual guard — a
testDeployAddress/testExpectedCodeHash/testExpectedCreationCodetrio — proves only that today's build agrees with today's constants. It says nothing about the releases already published, which is the thing consumers actually pin against.Without a frozen per-release record:
Zoltu addresses are a pure function of creation code, so the whole record is computable offline — this needs no network, no registry, and no skips.
How
Use the shared
LibSnapshotfromrain-sol-codegen(published in 0.1.1) — do NOT hand-roll a copy (that is how the canon ended up copy-pasted across four repos with the safety guard in only half):LibSnapshot.deployTag(vm)—[package].versionwith dots→underscores.LibSnapshot.freezeSnapshot(vm, contractNames)— freezes the generated pointers intosrc/generated/<tag>/, reverting rather than rewriting a frozen record without a version bump.{ access = "read", path = "foundry.toml" }tofs_permissions(needed bydeployTag).Reference implementation: rainlanguage/rain.math.float#253 — same migration end to end (generate the record via a locally etched Zoltu factory, freeze per tag, retire the hand-pinned literals into their snapshot, keep the public constant names as aliases so consumers do not break).
Related
LibSnapshotupstreamed.This repo specifically
It already has
script/BuildPointers.sol, so this is the smaller shape of the migration: extend it to generate the deployment record (Zoltu address + codehash + creation + runtime bytecode) alongside whatever it generates today, then callLibSnapshot.freezeSnapshot. No new codegen machinery is needed — just the record plus the freeze.