Use Cases
Match the rollup architecture to user needs, settlement requirements, and operational capacity.
Rollups are useful when an application needs a distinct execution environment, predictable fees, domain-specific transaction handling, or a controlled path to settlement. The architecture should follow the product and security requirements rather than a preference for a particular stack.
| Need | Design question |
|---|---|
| Application-specific execution | Which transactions, precompiles, or fee rules require a dedicated environment? |
| High transaction volume | Where is the actual bottleneck: execution, proving, data publication, or settlement? |
| Privacy or validity guarantees | Which proofs are required, and can the team operate the proving system? |
| Interoperability | Which assets and messages must move across chains, and what bridge trust model is acceptable? |
| Controlled participation | How are sequencing, access, governance, and recovery handled without misleading users about the trust model? |
The best deployment is one whose security assumptions can be explained to users and operated by the available team. If a bridge, prover, DA provider, or governance process cannot be monitored and recovered, it is not yet a production-ready dependency. ZKsync's chain-customization overview is a useful reminder that sequencing and data-availability choices are explicit trust and operational choices, not only performance settings.
Questions to answer before selecting a stack
- What must users be able to do if the sequencer is unavailable?
- How long can transactions, batches, proofs, and withdrawals wait before the product is degraded?
- What data must remain retrievable for users, auditors, and recovery tooling?
- Which actions require governance approval, and which require an immediate operator response?
- Does the team have the hardware, funding, and on-call capability for the selected proof, settlement, and bridge model?
Use the answers to define the initial operating model. A smaller system with clear recovery and ownership is usually a better launch than an ambitious architecture whose critical dependencies are not yet operable.