ZK Token Fee Flow System v1.0 Overview

keating · May 6, 2026, 1:15pm

The forum post “From Governance to utility: $ZK Token Proposal, Part I” laid out a direction for ZK: a token that can be integrated into new protocol fee mechanisms. Part II extended that direction with ZIP-14, which incorporated the burn function into the token contract.

The Fee Flow system, outlined below in detail, is the next building block in that sequence. It is a set of ancillary governance-administered contracts complementing the core protocol and governance system, that allows ZKsync Governance to route protocol fees through an onchain mechanism it controls.

The design draws on prior work in the space, particularly Uniswap’s Protocol Fees contracts, adapted for ZKsync’s architecture, including ZK’s capped-minter design and ZIP-14 burn functions. The Token Assembly, via ZKsync governance can now decide how to activate token burns and distributions via the standard ZIP and GAP processes.

ZK Token Fee Flow System Design Overview

The Fee Flow system gives ZKsync Governance two onchain mechanisms for handling protocol fees: a permissionless auction that converts non-ZK fee assets into ZK, and a splitter that routes the resulting ZK according to parameters governance sets, such as burn or other destinations.

At launch, the burn percentage is set to 100% and there are no other distribution recipients. Governance can adjust either parameter through the standard process. The system is designed to be configurable, not opinionated about which configuration is correct.

ZK Token Fee Flow Auction Mechanism Design

Please note this is the v1.0 implementation. New contracts may be deployed based on future protocol upgrades and protocol fee design changes.

The Fee Flow auction mechanism is a fixed-price auction in which fees are sent to the auction contract, which we will now refer to as the Fee Flow contract. These fees are pooled in the Fee Flow contract and can be claimed by anyone as long as they provide a fixed amount of ZK. The amount of ZK a claimer needs to provide is determined by the admin of the contract.

As approved fee assets accumulate in the Fee Flow contract, a participant may choose to submit a claim by transferring a fixed amount of ZK determined by the Fee Flow contract. Claims are permissionless, and the ZK received by the system is forwarded to the Splitter contract

The Splitter contract routes the ZK received from each claim according to governance-set parameters. At launch, the burn percentage is configured at 100%, meaning all ZK received under current parameters is burned. Governance can adjust this through standard process. The system also only supports claiming an approved set of ERC20 fees to prevent spam or malicious tokens from being included in the auction. The contract also excludes ZK from the auction and instead forwards those fees directly to the Splitter contract. To make the system more concrete, let’s walk through an example:

Imagine the Fee Flow contract has accrued 20,000 USDC, and governance has set the claim threshold at 1,000,000 ZK. A claimer can choose to submit a claim by transferring 1,000,000 ZK to the Fee Flow Auction contract. In return, the claimer receives the approved fee assets available for claim.

The 1,000,000 ZK is forwarded to the Splitter contract. Under the current parameters (100% burn, no distributors), 1,000,000 ZK is burned.

Claimers decide for themselves when a claim is worth making based on the assets available in the contract and the fixed ZK claim threshold. The system does not set a market price or execute trades on the open market. It applies the threshold set by governance.

ZK Token Fee Flow System Design Visual

ZK Token Fee Flow System Admin Overview

The Fee Flow System is governance-controlled. ZKsync Governance, acting through the ZK Token Governor Timelock, holds admin authority over its parameters.

A separate Emergency Admin role exists for time-sensitive operational situations, subject to the permissions and constraints in the deployed contracts. The role is intended to support operational continuity and risk mitigation, including pausing claims, updating approved tokens, and recovering certain misdirected assets

For the ZK Token Fee Flow System, governance or the emergency admin can:

Add and remove tokens from an approved list of claimable assets.
Assign the fixed ZK claim threshold, i.e., the amount of ZK a claimant must transfer to sweep the token inventory.
Assign the destination address (currently ZK Token Fee Flow Splitter contract) where paid ZK is forwarded.
Add/remove recipient address from the Fee Flow Splitter contract and the % split between each recipient. This has been initially set at 100%.

Future changes to burn percentages or distribution recipients would require the applicable governance process and should be reflected in the applicable public disclosures before activation.

ZK Token Fee Flow System Safeguards

On the safety and operational side, either the admin and the emergency admin can update the system in the following ways:

Pause claiming: Prevents claims while still allowing fees to accumulate, with a distinct pause role that can act quickly when needed.
Can update ownership/control addresses should the governance contracts ever need to be updated.
Change the token approved list. In other words, which ERC‑20s are eligible for auction claims, preventing bidders from claiming non-approved tokens.
In case of emergencies, the emergency Admin has the ability to move funds in the contract to a recovery address.

ZK Token Fee Flow Deployment Addresses (ZKsync Era, L2)

ZK Token Fee Flow Auction Implementation Contract: 0x5e55E69bD8bCdB6beF66e456C73a9ed20Ffe0f0C
ZK Token Fee Flow Auction Proxy: 0xF135fCd17733689462027bA7AfB210c2cB3C9803
ZK Token Fee Splitter Implementation: 0x79b6c98dCb0498216B939330fC93F7EaE66F7547
ZK Token Fee Splitter Proxy: 0x17a78994EfC487577Cd372c966D5b3D1cD67A933

ZK Token Fee Flow System Parameters and Methods

ZK Token Fee Flow Auction Configuration

Admin Address: 0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d (ZK Token Governor Timelock)
Emergency Admin: 0x9BdC9Ff6b5E33914b84C1fb7D695c67fF9E7c8B7
Bid Token: 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E (ZK Token)
Claim Threshold: 1_000_000e18
Minimum Bid Threshold: 100_000e18
Approved Tokens for Claim
- USDC Claim token: 0x1d17cbcf0d6d143135ae902365d2e5e2a16538d4
- USDC.e Claim token: 0x3355df6D4c9C3035724Fd0e3914dE96A5a83aaf4
- WETH Claim token: 0x5AEa5775959fBC2557Cc8789bC1bf90A239D9a91
Destination address for ZK upon claim: Splitter contract: 0x17a78994EfC487577Cd372c966D5b3D1cD67A933 (proxy address)

ZK Token Fee Flow Splitter Configuration

Admin Address: 0xe5d21A9179CA2E1F0F327d598D464CcF60d89c3d (ZK Token Governor Timelock)
Emergency Admin: 0x9BdC9Ff6b5E33914b84C1fb7D695c67fF9E7c8B7 (Multisig with 2/4 signing threshold, composed of two (2) ZKGPS signers and two (2) ZKsync Security Council signers)
Split Token: 0x5A7d6b2F92C77FAD6CCaBd7EE0624E64907Eaf3E (ZK Token)
Distributors: None at deployment. Governance can add recipient addresses and assign weights through the standard process.
Burn Amount: 10_000 (100%)

ZK Token Fee Flow Auction Key Methods

claim: Caller pays bidThreshold of bidToken to destination, triggers Splitter(destination).split(), then receives the full balances of requested claimable fee tokens. May be executed by anyone.
setBidThreshold: Updates fixed bid price. Must be >= minBidThreshold. May be executed by admin or emergency admin.
setClaimPaused: Pauses/unpauses claim(). May be executed by admin or emergency admin.
setClaimableToken: Adds/removes a fee token from the claim approved list. May be executed by admin or emergency admin.
setDestination: Updates where bid tokens are sent. Must not be zero. Expected to be a Splitter-compatible contract. May be executed by admin or emergency admin.
upgradeToAndCall: Upgrade to a new implementation, optionally calling setup data. May be executed by admin.

ZK Token Fee Flow Splitter Key Methods

setBurnPercentage: Updates burn percentage, 0–10000 basis points. If no distributors exist, must be 10000. May be executed by admin or emergency admin.
setDistributors: Replaces the distributor list. Empty list is allowed and forces 100% burn. May be executed by admin or emergency admin.
split: Takes the contract’s full splitToken balance, burns burnBps, distributes the rest by distributor weights, and burns rounding dust. May be executed by anyone.
upgradeToAndCall: Upgrade to a new implementation, optionally calling setup data. May be executed by admin. May be executed by admin.

Key Dates:

May 1: Version 1.0 of ZK Token Fee Flow Auction and Splitter Deployed

Github Repository:

https://github.com/zksync-association/zk-token-fee-flow/

SEEDGov · May 14, 2026, 8:26pm

Hi @keating and everyone!

Thanks for the post and the presentation, it’s nice to see prior proposals coming together into the Fee Flow System. Sharing some thoughts in order to keep the conversation going:

The price auction is indeed a reasonable model since it heavily reduces the complexity associated of converting fees into ZK for burning or distributing. The fixed-price is also fair in terms of simplicity regarding this first iteration.
Baseline burn parameters seem aligned with the ZK Flywheel while leaving open the possibility of including other distribution recipients or changing the parameter itself which is of course desirable.
As mentioned on the call, and given the inherent relationship with V31, a set path for ZK should be probably incorporated as it wouldn’t make sense to have it directed to the auction contract.

On roles and governance

First of all, the existance of an emergency admin is a necessary safeguard given the sensitive nature of the contract. The listed actions very well reflect the expected faculties that his role should have in order to perform precisely an emergency action, to which some seem more pressing than others. On who should hold the question remains open although it reasonably falls into the Security Council given that 1) Its an already existing structure 2) Emergency actions fall within their scope (as long as the emergency corresponds to precisely a security breach).

On the admin role, Foundation and ML play a key role within the Fee Flow System given that new ZK Chains deployments are stewarded and implemented by them. This naturally gives high context on the fee designs and mechanisms that eventually end up in the Fee Flow System. In order to streamline this role further, an internal Committee or structure could be set in place to monitor and execute the required actions, something that Lido has done vastly i.e.

Moreso, the possibility of engaging with service providers such as risk managers could also be contemplated within the responsabilities of this Committee. The DSC experience during Ignite can be leveraged when thinking of this approach.

On the admin role and it’s functions:

Add and remove tokens from an approved list of claimable assets.

If we are thinking on these based off ZK Chains fees, it would make sense to provide some sort of fast track in order to execute presumably operational decisions. Several protocols have experimented on this with different applications such as UNIfication (simplified process for fee parameters), AAVE (Direct-to-AIP framework) or Lido (Easy Tracks - stVaults example).

Assign the fixed ZK claim threshold, i.e., the amount of ZK a claimant must transfer to sweep the token inventory

Again, this would be closely related to the burn parameter and the distribution contracts if any, making it dependent to the outcome of another ZIP or TPP as well as the available listed tokens. In the same spirit, destination adresses management follow the same principle.

Final thoughts

The Fee Flow system gives the chance to decouple governance from operations and think of governance surfaces areas. As per V31, fixed-fees can only be modified by protocol upgrades, therefore giving the ZK Association direct ownership, something that the burn parameter modification and creation of new distribution contracts likely should follow. For the derived operations, having a MVS to monitor and execute should be optimal alongside a separate process for standar procedures.

Again, this are some early thoughts to keep the conversation going, feel free to call out any misinterpretation.

Thanks!