[TPP-3] ZIP Audit Reimbursement Program (ZARP)

Token Mechanics Draft TPPs
1

[TPP-3] ZIP Audit Reimbursement Program (ZARP)

Proposal Type TPP
One Sentence Summary An annual program valued at $5m USD (100m ZK) to reimburse security audit costs for successfully executed ZKsync Improvement Proposals (ZIPs) in 2025, ensuring high security standards for ZKsync protocol development.
Proposal Author ZKsync Foundation
Proposal Sponsor Cyfrin
Submitted Onchain TBC April 2025
Version v1
Summary of Action This proposal establishes a ZIP Audit Reimbursement Program valued at $5m USD in ZK (100m ZK) to reimburse developers for audit costs associated with successfully implemented ZIPs. The program will be funded through the ZK token minter and payments will be distributed autonomously upon the successful execution of a given ZIP.
Link to Forum Post TBC
Link to Contracts TBC

Abstract

The ZIP Audit Reimbursement Program (ZARP) allocates $5m USD in ZK over the 2025 calendar year to increase security standards across the ZKsync protocol by reimbursing the costs associated with third-party audits of successful ZIPs. This program will ensure that ZIP developers strive for exceptional security audit standards, resulting in secure and robust contributions to the ZKsync protocol.

Motivation

This proposal aligns with GAP 001: ZKsync Token Program Priorities 2025, which emphasizes the importance of accelerating ZKsync protocol development. As security is a foundational pillar of protocol integrity, this program directly supports the “Secure the Protocol” priority within GAP 001.

Impact

This program directly contributes to securing the ZKsync protocol, aligning with the ZKsync Governance North Star metric of protecting assets, builders, and the community from adversarial actors. By ensuring that all ZIPs undergo thorough security audits, the program mitigates vulnerabilities and strengthens the resilience of the protocol, removing the financial burden of security audits.

Primary Goals & Metrics

Goal Metric Target
Secure the Protocol % of successfully implemented ZIPs that receive audits 100% of eligible ZIPs audited
Secure the Protocol Number of security incidents related to newly implemented ZIPs that require an emergency upgrade to resolve 0 incidents
Public Accountability Number of reimbursements publicly documented 100% of reimbursements tracked

Token Mechanic

This Token Program Proposal (TPP) approves the creation of two capped minters to fund audit reimbursements for ZIPs executed in 2025:

  1. ZARPMain – A general-purpose capped minter for ZIPs executed between May 1 and December 31, 2025. Each ZIP will request its own allocation from this minter.
  2. ZARPRetro – A capped minter to reimburse audit costs for ZIPs posted on the governance forum and/or executed between January 1 and April 30, 2025.

zarp-overview
zarp-overview2622Ă—918 248 KB

1. ZarpMain: Future Audit Reimbursements (Q2 - Q4, 2025)

This capped minter will fund audit reimbursements for ZIPs executed on ZKsync between May 1, 2025 and December 31, 2025. ZIP authors will deploy a nested “child” capped minter to draw funds from this main capped minter upon successful protocol upgrade execution.

ZarpMain Capped Minter Parameters

Name: ZarpMain
Admin: Protocol Governor
Target: ZK Token
Cap: 68.4M ZK
Start Time: 25 April 2025
End Time: 31 January 2026
Contract Address: [TBC]
Minter Role: N/A (child minters who assume the MINTER role are deployed per ZIP)

Eligibility Criteria

To be eligible for reimbursement:

  • The ZIP must be successfully executed on ZKsync between April 1 and December 31, 2025.
  • The ZIP must include a third-party audit from a recognized security firm.
  • Audit invoice(s) must be submitted for verification to the ZKsync Security Council via direct message on the governance forum, before the ZIP is submitted onchain.

Reimbursements cover audit fees, formal verification costs, and code competitions. They do not cover ZIP development labor, travel, or other indirect expenses. A given audit may only be reimbursed once.

Claim Process

To claim reimbursement through ZarpMain, ZIP authors must complete the following steps before onchain submission of the relevant ZIP:

  1. Deploy a child capped minter with the following parameters (see Capped Minter V2 for deployment instructions):

    Admin: Protocol Governor
    Target: ZarpMain
    Cap: Amount of ZK matching the reimbursement request calculated using either the 7-day, 30-day, or 60-day average of the price from the date the child capped minter is deployed.
    Start Time: 30 days after the expected protocol upgrade approval date
    End Time: 31 January 2026

  2. In the ZIP draft posted on the governance forum, include:

  • Link to the audit report
  • Link to the deployed child capped minter contract
  1. In the onchain ZIP submission, include calldata to:
  • Grant MINTER role:
    1. on the parent capped minter (ZarpMain) to the child capped minter; and
    2. on the child capped minter to the ZIP developer
  • Grant PAUSER role on the child capped minter to the ZKsync Security Council

2012Ă—812 116 KB

If the ZIP passes the Token Assembly vote, the child minter’s MINTER role will become active after a 30-day buffer. During this time, the Security Council will verify the audit details if it has not already done so. If necessary, the Security Council may pause the minter using their PAUSER role, preventing misuse of funds.

2. ZarpRetro: Past Audit Reimbursement (Q1, 2025)

This capped minter will be used to reimburse audit costs associated with ZIPs approved by the Token Assembly prior to 30 April 2025.

ZarpRetro Capped Minter Parameters

Name: ZarpRetro
Admin: Matter Labs
Target: ZK Token
Cap: 31.6M ZK
Start Time: 1 May 2025
End Time: 31 January 2026
Contract Address: [TBC]
Minter Role: [Admin to confirm post-execution]

The ZKsync Security Council has reviewed (or will review) the audit invoices and reports for ZIPs approved prior to 30 April 2025 to confirm eligibility.

Eligibility

All ZIPs approved by the Token Assembly prior to 30 April 2025 were developed by Matter Labs. As such, Matter Labs will define the MINTER address for the ZARPRetro capped minter.

Claim Process

As the admin of the ZarpRetro capped minter, Matter Labs will be able to assign the minter role at their discretion that will be able to mint tokens in the ZarpRetro capped minter. The tokens are available to mint at any time until 31 January 2026.

Plan

Measurement & Reporting

  • On-chain tracking: The ZarpMain Capped Minter will record all disbursements, ensuring transparency.
  • Quarterly governance updates: The Security Council will publish status reports tracking disbursements and participation.
  • End-of-year report: A detailed impact analysis will be presented to the community.

Accountability Framework

  • The Security Council will review all reimbursement requests.
  • Conflicts of interest will be managed via a recusal policy.
  • All reimbursements are publicly documented for transparency.
  • Program impact is evaluated annually with Token Assembly input.

Participants

  • Security Council (responsible for oversight and pausing ineligible distributions).
  • ZIP developers and/or contributors (subject to KYC/KYB as per ZKsync Association policy).
1 Like
2

TPP-3 was discussed on the bi-weekly Proposal Review call that took place on Wednesday this week.

:link: Find call notes, links and the recording here!

3

We’re happy to see this proposal here since audits are logically an integral part of having a secure ecosystem and providing clarity on how they will be financed should encourage more quality contributions to the ecosystem. Also, this proposal is a good example of the utility of capped minters when distributing ZK tokens.

Our only question is related to market volatility: whilst the proposal works well if ZK’s price goes up, as fewer tokens would be needed for audit reimbursements, how will the programme handle a significant decrease in ZK price? We understand and agree with the idea of having a fixed ZK amount for the ZARPMain capped minter, however if the price goes down, the amount of audits to be covered can be limited.

1 Like
4

Hey @SEEDGov great question!

If the current token cap is not sufficient to achieve the programs objectives, the Token Assembly can approve expand the token allocation via a new capped minter.

On the other hand, if the token supply for the program exceeds the program requirements significantly, in most cases it’s OK to wait until the program ends and simply leave the excess tokens unminted. However, the Token Assembly could choose to cancel the current capped minter, and deploy a new one with fewer tokens based on the program needs.

3 Likes