ZK Token Fee Flow System v1.0 Overview

Token Mechanics
1

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

image
image2912×1900 262 KB

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:

3 Likes
Proposal Review Call May 13