SEEDGov - Delegate Communication Thread

Delegates
1

Delegate Introduction

Name: @SEEDGov

Delegate Profile:

RRSS:

We are excited about the opportunity to join ZK Nation, where we hope to contribute significantly to one of the most promising projects in the ecosystem. We have a dedicated team of SEEDGov members, passionate about ZK and committed to governance activities.

The main objective of this delegation will be to maintain active and meaningful participation, contributing to the growth and evolution of ZKsync Governance as an entity that deeply resonate with our values and principles.

What is SEEDGov?

SEEDGov is a dynamic and evolving vertical within the SEED Org Ecosystem, focused on shaping the future of decentralized governance in Web3 through active participation, community engagement and experimentation. Our approach emphasizes for minimizing governance where appropriate and professionalizing it where necessary.

As an active delegate platform, SEEDGov engages in governance across multiple projects. With roots in community values, we’ve evolved from education-based initiatives to a participatory approach that drives collaboration, coordination, and decision-making in the ever-changing Web3 landscape.

Our work embrace various protocols, from AMMs to Layer 2, where we design and implement governance infrastructures, manage grants and allocation programs, oversee incentives and onboard the right builders to meet each protocol needs. Seed’s diverse and multidisciplinary team brings the right flexibility and adaptability to strengthen the resilience of ZK Nation.

SEEDOrg>SEEDGov>ZK

Our perspective on the ZK Credo is deeply aligned with SEEDGov’s mission and values. The ZK Credo’s emphasis on freedom, progress, and prosperity resonates strongly with our commitment to promoting secure, accessible, and inclusive technologies like zero-knowledge proofs. Our approach emphasizes collaboration and the sovereignty/protection of user interests, core principles echoed in the ZK Credo.

Our delegation will do its utmost to represent and embody our values and follow ZK Credo principles to potentiate ZK Nation:

  • Decentralization: We will collaborate in the creation, iteration, and improvement of governance processes to ensure broader participation and that the system remains secure.
  • Community Led Growth & Sustainability: We will promote and support all initiatives that enable the growth, adoption, scalability and innovation for ZKsync ecosystem. Our focus will be placed on ensuring that all growth initiatives are reliable, secure, and sustainable over time.
  • Security: We will always make sure that no DAO decisions will jeopardize the security of the protocol and thus harm users.
  • Ethos and Accessibility: We will actively contribute to the governance of the protocol and its ecosystem worldwide, looking forward to working with other interested delegates to promote the ZK Nation mission and encourage others to actively participate in DAO governance.

Disclosure:

SEEDGov operates globally with multiple team members actively involved in governance systems such as Arbitrum, Optimism, Uniswap, Gnosis, Scroll, Lido, and Uniswap, among others. It is worth clarifying that our team members are specifically aligned with the protocol in which they contribute. Should any conflict of interest arise, it will be transparently communicated in this thread.

2

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.

1 Like
3

AAVE DAO Airdrop Claim Extension Request

Vote: For

Rationale: We fully support this proposal since the tokens were already allocated to the Aave DAO through the airdrop campaign, and the method to claim and distribute them won’t create any extra cost for zkSync. Also, we welcome that the tokens will be used to incentivise the use of Aave on zkSync.

4

Prepare ZKsync for ZK Gateway

Vote: For

Rationale: We support this proposal since it lays the foundation for the ZK Gateway upgrade. This upgrade is a big change for ZK Chains, because of how it improves the security of the bridging system. Also, the changes have been audited and look ready for deployment.

That being said, we also have some questions about how these changes will be communicated to ZK users and those developing ZK Chains. Given the importance of this proposal and the fact that we are voting on changes to the bridge system, its relevance is high. We suggest to provide some public communications with guidelines on:

  • What’s going to be implemented.

  • How to prepare for the implementation.

  • What to do after this proposal is implemented.

This should be communicated via X and through a blog article. This way, no one is caught by surprise by these modifications.

Upgrade Governance Contracts

Vote: For

Rationale: We support the ZkProtocolGovernor Timelock upgrade, as it seems the logical next step to speed up governance processes. The new quorum extension looks reasonable and we also have the right measures in place (like the Council veto period) to intervene if any issue arises.

We also back the redeployment of the ProtocolUpgradeHandler since making it upgradeable will make future modifications easier.

However, for future proposals, we think that implementing two modifications that don’t necessarily go hand in hand, like upgrading the ZkProtocolGovernor Timelock and the ProtocolUpgradeHandler, should be treated separately because they involve different risks and considerations.

5

[ZIP-7] Lens Chain inclusion on Elastic Network

Vote: For

We support this proposal since Lens becoming an Elastic Chain is a huge win for zkSync. We really value the efforts to have a smooth transition for Lens users, allowing them to use the platform without any annoying migration steps. That being said, we’ve some concerns, which is why we dropped those questions in our comment on the forum post. To say the least, this huge migration is uncharted territory, so understanding the potential risks and trade-offs is important.

That’s why we mentioned that understanding what happens if things go sideways and how Matter Labs plans to support Lens throughout the process is important. Therefore, we thought that having someone from Matter Labs or Lens to explain the trade-offs (if any) or potential risks in a governance call would be really valuable. Nevertheless, we are happy with this proposal and looking forward to welcoming Lens and its users to the Elastic Network.

6

[ZIP-8] Upgrade Chain Creation Params

Vote: For

Rationale: We support this proposal as it fixes critical chain creation parameters that would block new ZK Chains after the ZIP-6 upgrade, especially important given that Lens should be deployed soon. Additionally, we appreciate Matter Labs quick response in tackling this issue.