With the upcoming release of interop fees and under the purview of the GovInfra program, we, with the ZKSync Association’s support, conducted a research sprint on other potential protocol-level fee mechanics. The three mechanics we focused on were operator transaction fees, i.e., taking a fee on every transaction settled through the ZKSync gateway, stake for ZK Chain operators to create a chain or to have their proofs included in the Gateway, and fees for different proof types. These proposals are suggestions, and we hope to begin the discussion within the ZKSync community on mechanics that can be added to the protocol.
Potential new protocol fee mechanics
There are three stages in the protocol lifecycle where we can add protocol fee mechanics: the commit stage, the prove stage, and the execute stage. The commit stage is the earliest point in the lifecycle, and it is where the operator says, “Here is the batch I claim was executed, here is the resulting state, and here is the public data and metadata needed to verify later and finalize it.” The prove stage is where the operator submits a cryptographic proof that their committed data is valid. Once the committed batch is proven, it can be finalized, which is how we can think of the execution stage. In the context of Gateway an executed batch can be aggregated with other batches and anchored onto L1. Each of these stages provides an opportunity to hook in a fee mechanic. The three mechanics we will focus on are operator fees, operator staking, and custom proofs.
Operator Fees
At the most basic level, an operator fee is a per-transaction fee assessed to each transaction the operator wants to include in Gateway. The simplest implementation and the one we would lean towards is a fixed fee per transaction. We can assess fees on a subset of transactions rather than all of them, and implement a more complex fee mechanism. Still, we prefer simplicity for operator legibility of a fixed fee on all transactions. From a technical perspective, the simple approach can take inspiration from existing infrastructure.
From a technical perspective, the simple approach would extend ZKsync’s existing Gateway fee model beyond interop-specific activity. Today, interop fees are collected during batch execution: the operator submits a batch with a settlement fee payer, the Executor decodes the batch, and the ZK fee is pulled from the approved payer. A similar pattern can be used for ordinary transaction fees, but the key difference is where the fee is pulled. The number of ordinary transactions is currently unavailable at either the execute or prove stage. This means we must track the number of transactions at the commit stage and pass them through to the execution stage. At that point, we assess a fixed per-transaction operator fee unless the OS Server is modified to persist or forward that count into the execute stage.
A potential protocol fee could be a fixed transaction fee applied to all transactions, with the implementation hooking into the protocol’s execute stage.
Notes
- The Diagram above visualizes the flow from ZKSync chains through Gateway, where the transaction fee will be taken.
Staking for operators
Operator staking gives Gateway a participation eligibility requirement for chain operators. Instead of allowing any operator to keep submitting batches indefinitely, the protocol can require the operator to lock a minimum amount of ZK before using Gateway settlement. The purpose is to ensure that operators have meaningful alignment while relying on shared ZKsync infrastructure. If an operator falls below the required stake threshold, the chain should no longer be able to continue settling new activity through Gateway.
The simplest version is a fixed minimum stake per operator or per chain. More complex models are possible, such as stake requirements that scale with transaction volume, chain risk, historical usage, or the type of settlement service being used. However, for a first implementation, simplicity is probably best. The operator should be able to understand the requirement in plain terms.
From a technical perspective, staking can be treated as a Gateway-side policy check. The operator, settlement fee payer, or delegated operator identity would be associated with a staking manager, and Gateway would check that the relevant party has enough stake before allowing settlement to proceed. This check could happen during onboarding or migration to Gateway, and it could also be enforced continuously during the batch lifecycle. For example, Gateway could check stake during commit to prevent an unstaked operator from entering new work into the settlement pipeline, or during execution to prevent an unstaked operator from finalizing batches. The main design question is whether staking should be a one-time eligibility requirement, an ongoing settlement requirement, or both.
Notes
- The diagram displays how the operator staking would be checked against a manager in order to settle on Gateway.
Custom proving fees
Custom proving is the most nebulous of our proposals, it will require more research and has a larger surface of the protocol it could touch. The lightweight version we will present here is a proof-tag or proof-based fee, where the normal ZKsync batch proof remains unchanged, but the protocol recognizes additional proof-related activity. For example, a transaction could be marked with a protocol-recognized tag such as “verified,” or “proof-backed,” and the operator would pay an additional fee when including that tagged transaction. In this model, the custom proof does not replace Gateway’s normal validity proof; it is an extra piece of metadata or policy logic attached to a specific activity.
This proof-tag model is the version we would lean toward first. It is simpler for operators to understand because it does not change the core settlement model. Operators are still committing, proving, and executing batches in the normal way, but certain labeled transactions or proof-related services may carry an additional protocol fee. More complicated designs are possible, including different fee rates for different proof labels or fees that depend on proof complexity, but the first version should probably prioritize a small number of clearly defined proof categories.
From a technical perspective, proof-based fees should be enforced wherever the relevant metadata is visible. If the tag is tied to proof submission, it may fit at the prove stage. If it is emitted through logs or messages, it may fit at execute stage, similar to the current interop fee flow. The important principle is that Gateway should only charge for proof-related activity at a point where it can reliably see and validate the activity.
Notes
- The diagram displays how custom proof fees would be taken on a tag during the execution phase.
Conclusion
We covered a few different approaches to protocol fee mechanics in our research. These approaches are not exhaustive and are purely proposed ideas. Our aim with this post was to begin the discussion on where fee mechanics can be added to the protocol, and we would welcome the community’s guidance and input on new directions.