[ZIP-14] Upgrade ZK Token with Permissionless Burn Function

[ZIP-14] Upgrade ZK Token with Permissionless Burn Function

| Proposal Title | Upgrade ZK Token with Permissionless Burn Function | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Proposal Type | ZIP | | One Sentence Summary: | ZIP-14 proposes upgrading the ZK Token contract to ZKTokenV3, introducing token burn mechanisms to support protocol-aligned supply management under ZKnomics. | | Proposal Author | ZKsync Foundation | | Proposal Sponsor: | ScopeLift | | Date Created: | 2025-11-7 | | Version | v1 | | Summary of Action | Upgrade ZK Token to ZKTokenV3, adding public and role-gated burn functionality. | | Link to contracts | ZKTokenV3.sol (GitHub) | | Link to forum | ZKsync forum post |

Abstract

ZIP-14 proposes the upgrade of the ZK token contract to ZKTokenV3, a minimal extension of ZKTokenV2 that introduces two burn functions and a public max supply function:

1. Public burn – any token holder may permanently destroy their own tokens.
2. Role-gated burnFrom – addresses with the BURNER_ROLE can burn tokens from designated accounts.
3. Public max supply – allows any program to read the max supply of 21 billion ZK on the contract and the max supply is now enforced when minting new tokens.

This upgrade lays the foundation for the ZKnomics vision by enabling supply management through programmable token burning.

Motivation

The ZKnomics framework proposes usage-driven revenue distribution via two mechanisms: protocol staking and token burning. Token burn functionality is a prerequisite for implementing supply management and usage-based fee distribution at the protocol layer.

This proposal is the second step of the ZKnomics roadmap:

1. Enable permissionless staking (TPP)
2. Upgrade token with burn mechanism (this ZIP)
3. Activate sequencer and interop fee switches (ZIP)
4. Finalize programatic rules via governance proposal (ZIP)

By enabling burn functionality, the protocol establishes the supply-side mechanism necessary for usage-driven revenue distribution and long-term alignment between network activity and token value.

The upgrade delivers two benefits:

• Security & Recovery: Token holders, and any other smart-contract, can permissionlessly burn unused minted tokens and return compromised funds to the Token Assembly unminted ZK token supply.
• Forward Compatibility: Burn functions open up the design space for protocol fee switch designs (e.g. sequencer and interop fees).

This aligns the token with long-term protocol sustainability, while introducing minimal surface area of change.

Specification

The ZKTokenV3 contract extends ZKTokenV2 with two functions:

• burn(uint256 amount): allows any account to burn their own tokens.
• burnFrom(address account, uint256 amount): allows addresses with the BURNER_ROLE to burn tokens from another account.

Burning tokens decreases the ZK token’s totalSupply , which denotes the total minted supply.

This upgrade also introduces an onchain parameter maxSupply which is set at ZK’s maximum mintable supply of 21 billion. While token burns do not affect this value, ZKsync Governance can pass a protocol upgrade to adjust this value.

Rationale

Public burn

• Provides token holders autonomy in burning tokens.
• Enables voluntary supply reduction, supporting deflationary tokenomics if ZKsync Governance activates such a mechanism in the future.

Role-gated burnFrom

• Currently, the BURNER_ROLE is unassigned and can only be assigned via a proposal from the Protocol Governor.
• Allows the protocol to align token supply with fee-based burn mechanisms in the future.

This dual design balances user empowerment with governance-controlled flexibility, while maintaining minimal code complexity.

Implementation & Backwards Compatibility

• ZKTokenV3 is a direct extension of ZKTokenV2, with only 19 SLOC added.
• Existing balances and permissions remain unaffected.
• The previous burn function still exists on the implementation and has the same functionality of burnFrom
• All tooling compatible with ERC20 remains functional.

Breaking Changes

• No breaking changes for standard ERC20 usage.

Security Considerations

• Irreversibility: Burned tokens are not recoverable by the burner, they must be minted via ZKsync Governance.

Audit Summary

Auditor: Richie Humphrey (Offbeat Security) Date: July 11, 2025 Link: Audit Report (HackMD)

https://tally.xyz/gov/zksync/proposal/56697539346434504259886089137844919991955896472242107434527974192173343556352