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

Protocol Development Draft ZIPs
1

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

Proposal Title Upgrade ZK Token with Permissionless Burn Function
Proposal Type ZIP
One Sentence Summary: ZIP-XX proposes upgrading the ZK Token contract to ZKTokenV3, introducing token burn mechanisms to support protocol-aligned supply management under ZKnomics.
Proposal Author ScopeLift
Proposal Sponsor: ScopeLift
Date Created: 2025-09-25
Version v1
Summary of Action Upgrade ZK Token to ZKTokenV3, adding public and role-gated burn functionality. Assign the BURNER_ROLE_ADMIN role to the ZKsync Protocol Governor Timelock.
Link to contracts ZKTokenV3.sol (GitHub)

Abstract

ZIP-XX 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.

Furthermore, this proposal grants the BURNER_ROLE_ADMIN role to the ZKsync Protocol Governor Timelock, which requires participation by the Token Assembly and Security Council.

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’stotalSupply , 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

  • Role admin assigned to the ZKsync Protocol Governor, granted through this proposal.
  • 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
  • This proposal will assign the BURNER_ROLE admin to the ZKsync Protocol Governor Timelock.
  • 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

Audit Report (HackMD)

1 Like
2

The addition of permissionless self burn and max supply are great but why is the addition of burnFrom necessary?

The base ZkTokenV1 already has a burn method with identical logic and the same role gating on it.

The presence of this at all is actually rather disconcerting as it doesn’t have any approval checks, which means that any address with the burner role can burn tokens from any wallet at any time regardless of if they have approved the burn. Ideally the existing burn method would be amended to utilize erc20 allowances like in the [OpenZeppelin ERC20Burnable] (openzeppelin-contracts/contracts/token/ERC20/extensions/ERC20Burnable.sol at 0cb4888ba2d7ca85f3354aa8eb86e60aa5524dd7 · OpenZeppelin/openzeppelin-contracts · GitHub) contract. This is still composable with other smart contracts but prevents a single entity from having the ability to zero someone else’s self custodied funds.

burn method from ZKTokenV1

  /// @notice Destroys tokens held by a given address and removes them from the total supply.
  /// @param _from The address from which tokens will be removed and destroyed.
  /// @param _amount The quantity of tokens, in raw decimals, that will be destroyed.
  /// @dev This method may only be called by an address that has been assigned the burner role by the burner role
  /// admin.
  function burn(address _from, uint256 _amount) external onlyRole(BURNER_ROLE) {
    _burn(_from, _amount);
  }

burnFrom method from ZKTokenV3:

  /// @notice Destroys tokens held by a given address and removes them from the total supply.
  /// @param _from The address from which tokens will be removed and destroyed.
  /// @param _amount The quantity of tokens, in raw decimals, that will be destroyed.
  /// @dev This method may only be called by an address that has been assigned the burner role by the burner role
  /// admin.
  function burnFrom(address _from, uint256 _amount) external onlyRole(BURNER_ROLE) {
    _burn(_from, _amount);
  }
3

The addition of permissionless self burn and max supply are great but why is the addition of burnFrom necessary?

Good question, as you mention, the existing burn function provides the same functionality as the new burnFrom function. We added the burnFrom function to give a clear name to the functionality provided and to disambiguate it from the new burn function. We kept the existing burn function for backwards compatibility and to reduce the surface area of changes within this upgrade.

The presence of this at all is actually rather disconcerting as it doesn’t have any approval checks, which means that any address with the burner role can burn tokens from any wallet at any time regardless of if they have approved the burn.

To be clear, when you mention “approval checks,” you are referring to the ability for an address to approve an allowance to another address to burn tokens, which can also be referred to as a burn allowance, correct? I ask because there are “approval checks” for assigning the BURNER_ROLE. Only the BURNER_ADMIN_ROLE can assign the BURNER_ROLE, and after this proposal, the Protocol Governor Timelock will be the sole possessor of the BURNER_ADMIN_ROLE. By having the Protocol Governor Timelock as the burner admin, we ensure any assignment of the BURNER_ROLE must go through governance without being vetoed by the Security Council, which creates a high bar for any assignment to take place. As you highlight, great care should be taken when deciding to assign this role and the use of the burnFrom function.

Also, it is worth highlighting that this functionality is not added in this upgrade; it already exists in the token contract.