Detect an early constructor exit that loses EraVM immutables
A Solidity constructor compiled for native EraVM returns compiler-generated immutable data to the deployment machinery. A hand-written assembly exit can bypass that completion path.
Test the deployed getter
The fragment illustrates a constructor that assigns an immutable and then executes an explicit STOP. Deploy an equivalent fixture with the native compiler and inspect the resulting getter. Compare with a second fixture that lets the constructor finish normally.
constructor() {
threshold = 45; // immutable
assembly { stop() }
}
Native deployment passes immutable assignments back for installation by the system contracts. An assembly STOP or RETURN can leave them uninitialized. A successful creation receipt alone does not verify the immutable’s value.
Review assembly in inherited constructors
Inspect shared base constructors and assembly blocks that terminate the entire execution. Keep the compiler-generated completion path intact and test the deployed artifact on the intended VM mode. Ordinary Solidity function returns outside a constructor pose a different question. docs.zksync.io ZKsync documentation