ZK Stack deployment model
Separate ecosystem initialization, runtime services, proving, and wallet custody when operating a ZK Stack environment.
ZK Stack environments require a durable chain definition, a runtime service set, a proving pipeline, and funded L1 authorities. ZK-sync uses a containerized initialization and runtime model: initialize shared configuration and state first, then start runtime services from those artifacts.
Initialization is a security boundary
Initialization determines the ecosystem configuration and writes state that runtime services consume. Treat it as an infrequent, reviewed deployment operation. Keep generated configuration durable, versioned, and tied to the intended chain. Starting a fresh initializer because a runtime process failed can create a different environment rather than repair the original one.
Wallet material has separate roles, such as deployment, operator, blob submission, fee recipient, and governance. Do not put private keys in images or checked-in configuration. Give each role only the funding and authority it requires, and record which operational procedure may use it.
Proving and settlement path
The useful health path is: transaction admission, sequencing, execution, witness or proof work, proof aggregation where configured, L1 submission, and settlement confirmation. Monitor the age and depth of each queue, not only the final RPC response. Proving capacity, circuit or version compatibility, L1 funding, and delayed blob or proof submission can all block user-visible finality.
Release and recovery checks
| Check | Evidence to retain |
|---|---|
| Environment identity | Ecosystem and chain configuration, deployment artifacts, and contract addresses. |
| Runtime compatibility | Image digests, database migrations, runtime configuration, and service health. |
| Proof path | A known transaction traced through proof production and L1 verification. |
| Key custody | Role inventory, funding policy, access control, and emergency rotation procedure. |
| Recovery | A rehearsed restore that starts the same chain state rather than a newly initialized environment. |
For the shared operations model, see Zero-knowledge rollups, Monitoring, and Upgrading rollups.