Security, like every other aspect of the ZKsync ecosystem, is important. However, the way this process has been handled is not how it should be approached in the future. We are open to supporting this proposal and updating our vote, but the payments should be calculated based on the token price at the time of transfer.
Also moving froward, the structure for any type of services, like audits, should be approved prior hand with more transparency with the community.
Thanks for raising this point @lex_node, itâs a good opportunity to clarify the process around ZIP origination: ZIPs are fundamentally permissionless and can originate from anyone within the community.
But itâs true that to date, Matter Labs has developed the ZIPs submitted to the Token Assembly. Given their extensive involvement as the largest core maintainer of ZKsync, it makes sense that they would be the primary contributor to ZIPs.
A key intention behind this proposal is precisely to encourage and enable long-term ZIP contributions from a broader community. For dev teams or individual developers, the high cost and significant effort associated with audits might otherwise create insurmountable barriers to protocol development. Thus, reimbursing audit costs reduces one of the main hurdles for participation, eventually leading to a more resilient ecosystem.
Iâd also like to correct a misconception that has come up a few times so far: this proposed allocation isnât designed to be an extra revenue stream for DeCos or a âtoken allocation to Matter Labsâ. It is designed to fund critical security audits; Matter Labs (and any other DevCo which will submit ZIPs in the future) only acts as admin by paying for audit in advance and collecting the tokens as refund, and only if a protocol upgrade is passed.
This is similar to how VAT is handled: itâs collected by merchants but does not remain with them long-term; instead, itâs passed on to the Government. In fact, unlike VAT, this arrangement represents an additional cost and burden to the DevCos since a) they initially front the costs and b) assume the risks that the ZIP might not pass or might prove unfeasible.
How do we as the TA know that the âVATâ = cost for the audit is really what Matter Labs (or any ZIP developer) is requesting?
Also how is this set up really improving the situation for ZIP contributors if they only get paid if the ZIP is implemented in the protocol but they would have to eat the cost if the TA votes against the upgrade? I understand itâs more assuring, but itâs still far from taking any risk off the table?
How do we as the TA know that the âVATâ = cost for the audit is really what Matter Labs (or any ZIP developer) is requesting?
In the âEligibility Criteriaâ of the proposal, we included a requirement to make sure costs are accurate. Development organizations submitting a ZIP must provide invoices to the Security Council, which is composed of leading security firms and experts. The Security Council verifies that the amounts are real, accurate, and in-line with industry standards. The Proposal Review call from April 9th also has a discussion around this point (find notes & recording here).
Also how is this set up really improving the situation for ZIP contributors if they only get paid if the ZIP is implemented in the protocol but they would have to eat the cost if the TA votes against the upgrade?
Regarding your second point, this design minimizes the potential for gaming and spurious costs by ensuring that proposers have genuine skin in the game, sustain the costs initially and assume the risk if the ZIP does not pass. This is a first step in the broader journey to create a sustainable path to contributions to ZKsync protocol development but, as you pointed out, it may not be enough.
Thinking about the broader roadmap, we should work on additional pieces, including programs that provide targeted support for research and development efforts related to protocol upgrades. One of the questions that we outlined in the proposal pipeline from March is: âHow should the Token Assembly support ongoing protocol R&D and the companies which are working on its development?â. This is going to be key, in my opinion, in solving for both near term as well as long term.
Firstly, thank you for this proposal. As ITU Blockchain, we believe the ZIP Audit Reimbursement Program (ZARP) represents a much needed step in fostering a more reliable ZKSync ecosystem.
Security audit costs often cause hassle for the developers. This proposalâs structure underlines the importance of this issue quite well. It provides two programs with their respective conditions, one being ZARP Retro and one being ZARP Main.
In our opinion, the community oversight system was explained in enough detail âespecially since it is important to ensure reliability and accountability in times like this.
Mentioned measures are crucial to sustain the ZKSync ecosystem, even more now given the recent security issue witnessed.
We find the programâs scope and budget reasonable for the impact it aims to achieve, and affirm our trust in the betterment of ZKSyncâs future by such proposals.
A point we would ask for more clarity is the reason behind the ZARP Retro having more, and not the same budget as the ZARP Main while there is not a large time gap in between.
Thanks for sharing your thoughts @itublockchain. To answer your question:
A point we would ask for more clarity is the reason behind the ZARP Retro having more, and not the same budget as the ZARP Main while there is not a large time gap in between.
The difference between the amount of tokens assigned to ZARP Retro compared to ZARP Main is based on the fact that ZARP Retro costs are known, as they have been incurred. As such, the total cost of audits for ZIPs submitted between 1 January and 30 April 2025 (2,210,600 USD) is subtracted from the total value of the program ($5m USD). The amount left over was assigned to the ZARP Main capped minter.