Hi! We’ll be posting our voting rationales within this thread.
[GAP-1] ZKsync Token Program Priorities 2025 Endorsement
Vote: For
Rationale: To focus the Token Program priorities on the three areas mentioned in the proposal makes perfect sense to us. While the purpose of this proposal aligns with the goal of expanding zkSync’s ecosystem, a core idea behind the Token Program, the GAP-1 should be complemented with concrete objectives, end goals, or milestones for each of the three areas in order to bring more clarity about what can be achieved by approving it. Having metrics to easily monitor the progress on these areas would increase the accountability of those receiving the incentives.
We support this proposal, looking forward to have more details about how the ZK tokens will be allocated and the goals for each of the areas of focus mentioned in the proposal.
[ZIP-4] Reduce the execution delay from 21 hours to 3 hours
Vote: Against
Rationale: From our point of view, this proposal raises some concerns, since it touches critical points of the ecosystem. While we understand that it takes zkSync one step closer to one of its end goals, reduce the execution delay to zero, and we are aware of the reputation that precedes the members of the Security Council, we would suggest a more cautious approach.
First, we consider that the new delay period of three hours seems a bit short compared to the previous 21-hour window. As we have proposed in other governances, when talking about Security Councils, it is prudent that their members reside in different time zones. Then, three hours can seem enough theoretically or under controlled environments, but given time zone differences, it may complicate gathering the necessary signatures to act against a potential threat. That being said, there is one last concerning matter about this proposal, related to the problems encountered while testing it. Even though they were overcome and the test ended up being successful, there is still a question mark about whether these problems could reappear in the future. From our point of view, the way to erase these doubts is by conducting more testing events. An interesting approach to Security Councils, adopted by other networks, is to carry out unannounced testing events through a third party. Then, the results of these events are shared with the governance to understand how the Security Council performs in case of emergencies.
Therefore, we vote against this proposal, as we consider it more appropriate to decrease the execution delay gradually (something between 6 and 10 hours) while conducting additional tests on how the Security Council performs under unexpected conditions are carried out.
[GAP-2] Adopt The SEAL Safe Harbor Agreement
Vote: For
Rationale: This proposal is in line with what we, as delegates, expect for the future of zkSync. Implementing the SEAL Whitehat Safe Harbor Agreement to establish the proper conditions for whitehats to try to recover users’ funds from an ongoing exploit will definitely increase user’s trust while using zkSync. The fact that whitehats are compensated after recovering the funds will incentivise them to behave accordingly. Besides these points, implementing this agreement is in line with what other top-tier protocols have previously done, such as Uniswap and Balancer. On the other hand, the $1,000,000 bounty cap can be seen as a deterrent to go the extra mile and recover more than $10,000,000. Also, the fact that the funds have to be manually returned adds a layer of trust to the whole process that perhaps could be solved in the future by introducing some form of automation or by involving zkSync´s governance in the refunding process.
Despite these minor concerns, we fully support this proposal.