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

Token Mechanics Active TPPs
1

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

Proposal Type TPP
One Sentence Summary An annual program valued at $5m USD (89,285,714 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 2025-05-06
Version v1
Summary of Action This proposal establishes a ZIP Audit Reimbursement Program valued at $5m USD in ZK (89,285,714 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.
Total ZK Requested 89,285,714 ZK
Link to Forum Post [TPP-3] ZIP Audit Reimbursement Program (ZARP)
Link to Contracts ZarpMain: 0x51E818785dEa065D392ac21F04E9cac5B601Cfd8, ZarpRetro: 0x70F6998FC0c492d9DD08b1105259252329be9Db6

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. The total value of the two capped minters is 89,285,714 ZK, which is the ZK token value of $5m USD based on the 30-day average from 27 April 2025. An overview of the two capped minters is set out below:

  1. ZarpMain – A general-purpose capped minter for ZIPs executed between May 1 and December 31, 2025. A total of 49,810,714 ZK may be minted from ZarpMain. Each ZIP will request its own allocation from this minter.
  2. ZarpRetro – A capped minter to reimburse audit costs for ZIPs approved by the Token Assembly between January 1 and April 30, 2025. A total of 39,475,000 ZK may be minted from ZarpRetro.

updated-overview
updated-overview2670Ă—716 140 KB

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

ZarpMain is a capped minter that will fund audit reimbursements for any developer who submits a successfully executed ZIP on ZKsync between May 1, 2025 and December 31, 2025. Any ZIP author is eligible to claim audit reimbursements by following the outlined process, supporting the decentralization of protocol development. Developers will deploy a nested “child” capped minter to be able to draw from this main capped minter with successful protocol upgrade execution.

ZarpMain Capped Minter Parameters

Parameter Value
Name ZarpMain
Contract Address 0x51E818785dEa065D392ac21F04E9cac5B601Cfd8
Admin Protocol Governor Timelock
Target ZK Token
Cap 49,810,714 ZK
Start Time 19 May 2025
End Time 31 January 2026
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 May 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):
Parameter Value
Admin Protocol Governor Timelock
Target ZarpMain
Cap Amount of ZK matching the reimbursement request calculated using the 30-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

Please reach out to Gov Team for support creating child capped minters.

  1. 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 on ZKsync Era (0xfFB6126FF8401665081b771bB11cCD0e09f95D5A)

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)

ZarpRetro is a capped minter used to reimburse audit costs for ZIPs approved by the Token Assembly prior to April 30, 2025. Any ZIP author is eligible for retroactive reimbursement. Matter Labs has been the only developer to submit protocol upgrades to date. As a result, Matter Labs is the sole claimant under the ZarpRetro capped minter.

ZarpRetro Capped Minter Parameters

Parameter Value
Name ZarpRetro
Contract Address 0x70F6998FC0c492d9DD08b1105259252329be9Db6
Admin Matter Labs Multisig (0xb84cFd9EBA97d991afa2E7B76b900804eE911Ab7)
Target ZK Token
Cap 39,475,000 ZK
Start Time 19 May 2025
End Time 31 January 2026
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.

The total value of the ZarpRetro Capped Minter is $2,210,600 USD. Using the 30-day average price of ZK from 27 April 2025, this amounts to 39,475,000 ZK tokens, which is the cap of the ZarpRetro Capped Minter.

Summary of Retro Audit Reimbursements

ZIP Amount Claimed (USD)
ZIP-3 Protocol Defense $91,440
ZIP-6 Gateway Prep $1,490,540
ZIP-9 EVM Emulator $628,620
Total USD $2,210,600
Total ZK at 0.056 (30-day average) 39,475,000

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.

Details of audit reimbursements being claimed by Matter Labs are set out in the tables below.

ZIP Auditor $USD Claimed Audit Report(s)
ZIP-3 OpenZeppelin $91,440 Protocol Defense Report
ZIP-6 OpenZeppelin $510,540 ZKsync Custom Asset Bridge Audit + ZKChain Upgrades and Libraries Diff Audit + ZKChain & Gateway Upgrade Audit + ZKChain Release Candidate Audit
ZIP-6 Audittens $380,000 Gateway Security Competition
ZIP-6 Audittens $100,000 Hyperchains Security Competition
ZIP-6 Cyfrin $500,000 CodeHawks Security Competition
ZIP-9 OpenZeppelin $628,620 EVM Equivalence Audit + FFLONK Verifier Audit + FFLONK & EVM Emulator Diff Audit

All reimbursements claimed from the ZarpRetro capped have been reviewed and approved by the Security Council.

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).
3 Likes
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!

1 Like
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.

2 Likes
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.

4 Likes
5

While I appreciate the intention behind this proposal and fully support improving security standards for the ZKsync protocol, I must voice concern over the current structure of the proposed minting mechanism.

Minting a large amount of ZK tokens—100 million ZK—within a relatively short time frame poses a significant risk of introducing sell pressure on the token, which could negatively impact the market price and broader community sentiment. Even if reimbursement claims are staggered, the full cap being minted or allocated upfront can create uncertainty in the market and raises concerns about inflationary impact.

I recommend adjusting the proposal to incorporate a monthly minting schedule, wherein a capped amount of ZK is minted each month based on the actual reimbursement claims submitted and approved during that period. This would achieve the following:

  • Align disbursements more closely with real-time audit demand and ZIP implementation.
  • Increase transparency and predictability for the community and token holders.
  • Reduce unnecessary minting and thereby limit potential downward price pressure on ZK.

Alternatively, if upfront minting is necessary from a technical perspective, I propose establishing stricter monthly disbursement limits and a dynamic burn mechanism for any unused tokens at year-end.

In conclusion, while the goals of ZARP are commendable, I urge the authors and governance participants to consider a more conservative and price-conscious approach to implementation.

1 Like
6

Hey @cobinus - providing some context for your comments below.

Minting for this program is expected to be distributed over a 9-month period. (May 2025 - Jan 2026). For context, the Ignite Program that was approved by the Token Assembly allocated 325M ZK to be minted and distributed over 9 months.

Aside from the ZarpRetro capped minter, which would be available for minting upon the proposal passing, other audit reimbursements will only be granted/become mintable as the corresponding ZIPs are passed over time. These are expected to be spread out over the coming months as it takes time to prepare the upgrades and submit the proposals.

Additionally, audit reimbursements received through this program do not need to be minted all at once. The developer of each ZIP, who will hold the minter role on the associated capped minter contract, has the discretion to mint at a time that makes sense for the recipient.

There is currently no onchain-enforceable mechanism to enforce a suggested monthly minting schedule. The Governance Team is currently working on developing additional “minter mods” that would enable things like a mint rate limiter, but the timeline for completion is currently unknown.

1 Like
7

EDIT: See below.

We have put this proposal up for voting!

Note: As always, we will conduct a review of the proposal calldata as part of our role on the security council once it reaches that stage.

3 Likes
8

We had the 30-day average as 0.058 instead of 0.056 in a table in TPP-3, so we resubmitted.

Thank you!

1 Like
9

Program carries unclarity and brings risk on selling pressure. Hardly voting aganist on this one.

10

I was wondering, why are you minting new tokens for this when there are clearly tokens left from the airdrop? You even gave 10% of that allocation to the hacker. (It’s a shame you didn’t reward the chads who discovered the exploit 24 hours before you noticed it, especially since it was their warning that alerted you.)

But what I’m really asking is: you’ve got around $5M in ETH and ZK (soon to be all ZK after the buyback). Why not use those funds for this instead?

1 Like
11

I’m always trying to represent the community’s feedback (yes, there is a ZKSync community)

https://x.com/MadMaxx_eth/status/1920780946065768691?t=Dnz65jPbNK3YAk3pRDDYYA&s=19

2 Likes
12

I am a big ZKsync supporter, but being critical helps, it sets a higher bar, moves things forward, helps exploring new solutions.

IMO this proposal needs fixes. and future ones should go smoother.

  1. audit costs feel overpriced. gov should see rate sheets. whitelist audit firms, check refs + pricing, then decide. transparency kills corrupt behavior. clean and simple.

2.avg token price is hard, i get it. but using random avg isn’t fair. token moves fast.
ex: protocol defense = $0.226 / gateway prep = $0.098 /evm emulator = $0.048
Price should match when work was done. or avg between draft + exec date.

Challenge to the community + token assembly: let’s find a clear method. we’ll need it for future proposal too

3 Likes
13

Hey everyone,

We’d like to share why we’re voting against this proposal in its current form, not out of disrespect for the work done, but because of serious concerns around process, fairness, and precedent.

1. No prior governance approval
The audit work was completed before any governance budget was approved. This opens the door for contributors to act independently and submit reimbursement proposals after the fact, which we believe is risky and unsustainable.

2. No transparent selection process
Auditors were selected without community input. Even if the firm is trusted, like OZ, governance should approve a shortlist or validate the budget and scope before work begins. Without this, there’s no accountability or quality control mechanism on behalf of the DAO.

3. Token price volatility introduces budget distortions
Retroactive reimbursement based on current token prices can lead to significant overpayment, especially in volatile markets. This creates an unpredictable and potentially dangerous financial precedent for the DAO treasury.

4. Ecosystem contributors like Zyfi were never retro-paid
We’ve contributed infrastructure like gasless transactions and pushed adoption of native account abstraction, all without requesting retroactive compensation. We’ve supported dozens of projects and scaled user acquisition at our own cost because we believe in the mission. Starting to selectively retro-pay contributors without a consistent structure is unfair to others who have done the same.

Constructive suggestion
If the goal is to fairly acknowledge the work already done, we propose that 50 percent of the requested dollar amount be paid as a one-time reimbursement so the auditor at least breaks even. This should be calculated based on the ZK token price at the time of the token transfer. This would be a one-time exception. Otherwise, Matter Labs should cover the full amount, and governance should focus on designing a better process.

Looking ahead, we believe the DAO should introduce a clear framework for future audits and similar work:

  • Budgets approved in advance
  • Auditor selection either pre-whitelisted or openly discussed
  • Payments structured around milestones
    .- Payouts denominated in USD, using the ZK token price at the time of disbursement

This would protect the DAO’s credibility, maintain financial discipline, and create a fair environment for all contributors, whether they’re protocol developers or ecosystem builders like us.

We’re happy to contribute to shaping a more transparent and sustainable process moving forward.

2 Likes
14

Hi Gauthier,

Thank you for your feedback. I’ve provided a response to each of your concerns below. Overall, the proposal addresses your main issues, as these were taken under consideration in the design of the program:

1. No prior governance approval: The audit work was completed before any governance budget was approved. This opens the door for contributors to act independently and submit reimbursement proposals after the fact, which we believe is risky and unsustainable.

  • Retroactive payments can often lower risk: “it’s easier to agree on what was useful than what will be useful.” In this case, the program only reimburses the audits which were useful (as confirmed by an approved protocol upgrade) instead of arbitrary future audits that may not become valuable to ZKsync.
  • The development work completed to date and included in this proposal for reimbursements was shared and published as part of the roadmap, which is available on the blog here. The auditors are industry leading organizations, as expected and necessary for complex protocol code development. The audits also include competitions, which is industry standard for best-in-class security.
  • Audit reimbursements are provided after the fact. As a result, developer teams have aligned incentives: if a protocol upgrade is not valuable or successful, then no audit reimbursement to the developer team is provided. The developers take on the risk of protocol development. If an audit is overly costly or not from an industry-leading organization, the Token Assembly can also vote to reject the protocol upgrade and it’s attached reimbursement.

2. No transparent selection process: Auditors were selected without community input. Even if the firm is trusted, like OZ, governance should approve a shortlist or validate the budget and scope before work begins. Without this, there’s no accountability or quality control mechanism on behalf of the DAO.

  • The development team who proposes a protocol upgrade takes all the risk, if the proposal is not passed they pay the auditor from their pocket. Hence they also have the right to choose the auditor.
  • Furthermore, the Token Assembly is validating the selection of the auditor via the approval of the protocol upgrade. If the auditor is not of the appropriate standard, the protocol upgrade should not be approved by the Token Assembly.

3. Token price volatility introduces budget distortions: Retroactive reimbursement based on current token prices can lead to significant overpayment, especially in volatile markets. This creates an unpredictable and potentially dangerous financial precedent for the DAO treasury.

  • Because token price is unpredictable, which is why the value of the ZARP program is intentionally denominated in USD. Audit costs are incurred by developers in USD, which is why ZARP is denominated in USD.
  • Taking the 30-day average prior to the submission of the proposal on the onchain is industry standard practice, and in this instance accurately represented the volatility the ZK token price has experienced in 2025. In saying that, different calculation methods should be employed for different circumstances at the discretion of the proposal author.
  • Developers who have proposed successful ZIPs can’t go back in time and sell the amount claimed at the token price in January, for example. All calculations for this proposal make the best effort to reimburse developers the audit costs, not intentionally penalize developers for successful upgrades during market volatility.

4. Ecosystem contributors like Zyfi were never retro-paid: We’ve contributed infrastructure like gasless transactions and pushed adoption of native account abstraction, all without requesting retroactive compensation. We’ve supported dozens of projects and scaled user acquisition at our own cost because we believe in the mission. Starting to selectively retro-pay contributors without a consistent structure is unfair to others who have done the same.

  • We appreciate the feedback. That being said, votes should reflect the merits of the proposal itself, not be used as a response to situations which are outside the scope of the proposal. This program is strictly scoped to include audit costs for protocol upgrades that are approved and executed by the Token Assembly.
  • At the Foundation, we’re currently exploring other paths to grow the ecosystem. In line with our proposal roadmap and GAP-1, these come second to protocol reliability that ensures ZKsync has the foundational technology live needed to become a category leader.

Constructive suggestion: If the goal is to fairly acknowledge the work already done, we propose that 50 percent of the requested dollar amount be paid as a one-time reimbursement so the auditor at least breaks even. This should be calculated based on the ZK token price at the time of the token transfer. This would be a one-time exception. Otherwise, Matter Labs should cover the full amount, and governance should focus on designing a better process.

  • This proposal already focuses only on reimbursing audit costs. It does not cover research, development, and deployment costs related to protocol upgrades. As you’ve suggested, and part of the design already, the reimbursements are at-cost. There is no additional ZK token allocation. In other words, the developers “break-even” on the audit itself and no other part of the cost.
  • Please note that the auditors are not receiving the ZK tokens. The tokens go to the developers who created a successful and beneficial protocol upgrade for ZKsync, since the developers have already incurred the USD audit costs when protocol upgrades are submitted.
4 Likes
15

Security is essential to the thriving potential of ZK. We’ve seen too many such examples where a team or DAO under-indexes on security, and then has a catastrophic demise due to it. (Poly Network toppled completely because it couldn’t recover from their security breach).

The way auditors was selected was quick, efficient, and the list includes auditors that I highly respect, even where we are potential competitors with them. I’ve seen DAOs look to make massive amounts of red tape (I saw a DAO make “A framework to make frameworks to select security partners”), which essentially forced them to get nothing done.

The process here where the development team carries the risk is a wonderfully efficient one.

We will be voting in favor of this.

3 Likes
16

Thank you for the detailed response and for addressing the concerns raised. It’s clear that this proposal was carefully considered and scoped. I appreciate the focus on reimbursing only those audits tied to successfully executed protocol upgrades.

That said, I’d like to clarify and reinforce a few key points to help strengthen the governance process going forward and to make sure the rest of community aligns on it correctly.

1. Governance Approval Must Precede Auditor Engagement

While the logic of reimbursing “useful” audits retroactively is understandable, I believe the current model introduces governance and financial risk.

If an auditor is formally engaged, governance should approve the budget and scope beforehand.

Even if developers are willing to front the cost, it’s not sustainable to ask the DAO to cover significant expenses after the fact. It sets a precedent where contributors can bypass budget scrutiny, assuming reimbursement will follow a successful outcome.

Going forward, I suggest:

  • A lightweight “intent to audit” post, shared before work begins, outlining the expected scope, cost, and chosen auditor.
  • This gives the DAO visibility and a chance to raise any concerns upfront, without introducing friction to development velocity.

2. Auditor Selection Transparency

While developers should have discretion in choosing trusted audit firms, governance should be involved early enough to ensure quality and fairness.

To improve transparency, I recommend:

  • Publishing a pre-approved list of acceptable audit firms , or
  • Requiring disclosure of selected auditors and estimated costs before any agreement is signed.

This avoids situations where the DAO is effectively forced to ratify decisions after the fact.

3. Token Price Volatility and Treasury Protection

To better protect the DAO treasury and bring more consistency, I suggest the following adjustments for future proposals:

  • Introduce USD-denominated reimbursement caps per proposal to limit exposure during extreme volatility.
  • Most importantly, the conversion price of the ZK token should be locked at the time tokens are sent , not at the time of proposal submission. This ensures that the DAO does not unintentionally overpay or underpay if there’s a sharp increase in token price during the waiting or voting period.
  • Partial vesting or time-based vesting could also be explored for larger reimbursements.

4. Recognizing Other Ecosystem Contributions

I understand this proposal is strictly scoped to audits. But if we are setting a precedent for retroactive reimbursement , we need to recognize other forms of high-impact contributions as well.

Projects like Zyfi:

  • Delivered gasless infrastructure across major dApps
  • Contributed code and technical integration work
  • Helped scale user adoption at our own cost

All of this was done without upfront grants or guaranteed reimbursement.

These contributions are not out of scope if we aim to build a fair and credible ecosystem. If protocol security is funded retroactively, so should foundational infrastructure that enables protocol usability.

I would gladly help design a structured path to recognize and reward these kinds of contributions through a separate track.

5. Final Thoughts

I’m supportive of this proposal and recognize the importance of reimbursing completed audit work. However, to move forward, the proposal needs to be updated to denominate reimbursements in fixed USD amounts, with the equivalent ZK calculated at the time of disbursement. This ensures audit costs are reimbursed fairly and avoids distortions from token price volatility.

If this change is made, I will support the proposal.

In addition, for future cases, we need:

  • Clear budget signaling before auditors are engaged
  • Transparent auditor selection with public disclosure
  • Token price set at the moment of transfer , not earlier
  • A structured approach for retroactively recognizing broader ecosystem contributions, especially when code, infrastructure, or adoption efforts have already delivered clear value

These points should also be implemented, and a better, more consistent process should be proposed for future reimbursement programs.

If these adjustments are taken into account, this proposal can serve as a strong reference point going forward

Thanks again for all the work that went into this.

Best regards,
Gauthier

3 Likes
17

While security is undeniably important, bringing this proposal to governance without prior transparency, approval, or upfront cost disclosure reflects a lack of consideration and respect for the broader ecosystem participants who are actively contributing to ZKsync.

2 Likes
18

Hi Gauthier,

Please find additional clarifications to your response above.

1. Governance Approval Must Precede Auditor Engagement

In my previous response I provided the context for this: Developers take on the audit costs of protocol upgrade submission. The Token Assembly votes to approve the protocol upgrade and auditor quality when a ZIP is submitted for approval. Governance approval is happening at the point of the protocol upgrade evaluation. Adding additional layers of approvals adds complexity and unnecessary burden to protocol upgrades, which has a negative impact for the ecosystem.

Protocol upgrades and audits are posted on the forum most often weeks before the onchain vote begins. This proposal as well was posted on April 8th, allowing ample time for feedback. There is also a 30-day delay built into the granting of minting rights upon approval of a protocol upgrade to any reimbursement recipient to allow time for the Security Council to pause the request, the community can also use this time to voice concerns to the Security Council.

In return, developer teams requesting reimbursement have aligned incentives: if a protocol upgrade is not valuable or successful, then no audit reimbursement to the developer team is provided. If an audit is overly costly or not from an industry-leading organization, the Token Assembly can also vote to reject the protocol upgrade and it’s attached reimbursement or the Security Council can pause the capped minter.

2. Auditor Selection Transparency: While developers should have discretion in choosing trusted audit firms, governance should be involved early enough to ensure quality and fairness.

The ZKsync Governance system includes the Security Council for this expertise. In other words, governance is involved per design. The Security Council is assigned the role to review and verify audit costs for protocol upgrades because they have the most context to be able to do so. The Security Council is expected to raise any concerns for audit costs that appear to be out of line with industry standards or the scope of the audit this was conducted.

As noted above, the Token Assembly also has time to review the requested reimbursement amount before a proposal is submitted onchain and raise any concerns there. A reimbursement is also not guaranteed. As stated in our last response, the development team who proposes a protocol upgrade pays the auditor directly. If the proposal is not passed they pay the auditor from their pocket. Hence they also have the right to choose the auditor.

3. Token Price Volatility and Treasury Protection

Reposting from our comment above: Token price is unpredictable, which is why the value of the ZARP program is intentionally denominated in USD. Audit costs are incurred by developers in USD, which is why ZARP is denominated in USD.

Reminder that ZK is not “sent” or “transferred” at any point - minting rights are granted. The receiving party receives minting rights upon approval of a protocol upgrade and following 30 day delay to allow for the Security Council to pause a reimbursement request if they find the submission does not match the audit invoice they have to verify.

The amount of ZK should be calculated using the 30-day average at the time of submission. For ZarpRetro, this was calculated at the time the onchain proposal was submitted, based on the USD amounts listed above.

4. Recognizing Other Ecosystem Contributions

Happy to continue this discussion on the forum, but this sounds like an issue for a separate proposal. Restating here that the retroactive piece of this proposal is not retroactive funding for “contributions from a team,” it is for the specific audit costs (at cost) that enabled quality and secure protocol upgrades for the ZKsync protocol in 2025. There is no additional ZK token allocation. In other words, the developers “break-even” on the audit itself and no other part of the cost.

5. Final Thoughts

I want to reiterate that we are grateful for the feedback and also highlight that this proposal was posted on April 8th (over 5 weeks ago) where none of this issues were raised prior to putting this proposal onchain.

5 Likes
19

Hey,

Thanks for the clarifications.

We don’t follow every proposal from the beginning. We vote when it goes onchain. From a contributor’s perspective, this feels like the cost is being presented late, with the expectation that the community simply accepts it without proper approval.

The flow here is not correct in my opinion. This isn’t retro funding. The audit costs were known in advance and should have been submitted for approval beforehand, whether the proposal passed or not. That’s how it should be handled.

Reimbursement should be USD-denominated, with the ZK amount calculated at the time of disbursement. I don’t know why we are over complicating things. A service is needed, it needs to be approved then payment should just simply be made at the dollar cost of the payment. All of these flows add unecessary complexity. That ensures fairness and transparency for everyone involved.

Best
Gauthier

1 Like
20

The following reflects the views of L2BEAT’s governance team, composed of @kaereste, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

We are voting FOR the proposal.

Protocol security is of paramount importance, and subsidising the cost of security audits is a straightforward step the DAO can take to help with that. The reimbursement aspect, where the DAO only reimburses for an audit after it has been carried out and paid, makes us more comfortable, as it will help mitigate pointless spending with the development team(s) carrying the risk, as pointed out by @bendob.

It also makes sense to introduce a retroactive reimbursement for the audits of previous ZIPs. When our researchers reviewed the proposals on our behalf before we voted for them, especially the gateway one, they made a point about how extensive and complicated the upgrades were. Although we reviewed the code ourselves, we were comfortable knowing they were professionally audited. If there’s anything we shouldn’t be cheap with as a DAO, then that is protocol security.

We have followed the conversation and the points raised by @Gauthier, but we do not see them as reasons to vote against the proposal.

3 Likes