ZKsync Security Council - Do we need it?

Hello,

I would like to raise a question regarding the current necessity of maintaining the Security Council at this stage of the project. As I understand, the Security Council is responsible for overseeing the protocol’s security, reviewing and approving proposals, and taking emergency actions when required.

However, I have some concerns about whether this type of service is essential right now:

Centralization of the protocol: At this point, the protocol remains highly centralized, with all updates coming directly from Matter Labs. This raises the question — what exactly is the Security Council reviewing or approving? The need for such oversight would be more evident if there were multiple independent contributors involved.

Response time during incidents: During the recent incident involving airdrop tokens, the Security Council’s response appeared delayed. Despite numerous reports from the community, action was only taken once the issue gained significant attention on Twitter.

Service cost: According to the latest proposals, the service costs approximately $1.5 million for a 15-month period, which is a considerable expense given the current circumstances.

Given these points, I would like to propose pausing the Security Council’s service until there is a clear operational need for it — or at least until ZKsync Era reaches Stage 1.

5 Likes

Unfortunately, such a proposal will never pass because governance is centralized. But the idea is correct: stop burning money on useless things and route it toward BD/marketing. ZKsync needs to grow business, not bureaucracy.

Plus, I personally can’t trust Security Council after that incident with the airdrop tokens. It took them almost 2 days to respond, even though the community notified the ZKsync team within the first couple of hours. “Admin stole our multisig” is also not the best post-mortem. Salaries are inflated and should be cut at least 3x.

3 Likes

Please review the latest security council update to learn more about what the security council has been up to for the past year.

The ZKsync Security Council is a non-negotiable. Their job is to ensure that the entire elastic network (all chains) are running properly and there are no errors. Have you noticed how there has never been an outage where all ZKsync chains have gone down as happens in other ecosystems? Yes, you can thank the security council for that. They review all code, all contracts and all potential security issues prior to them becoming actual issues. If they are doing their job correctly (they are) you should think they’re not doing anything because they flag and take care of all the issues before they become huge breaking issues.

If you believe in ZKsync and want the Elastic Network to grow, you need a strong and legit security council to ensure everything is running smoothly.

Regarding the leftover airdrop tokens compromised admin account, this actually was not under the security council’s purview during that time. It has since been added, with 24/7 continuous monitoring. That unfortunate situation was not due to the security council. Also, it was thankfully resolved with more than the tokens lost being recovered. Part of those recovered funds are now being used in the community program that is currently running.

Hey, I appreciate you laying out the defense for the Security Council, and I agree that a security function is non-negotiable. However, your argument relies on several logical fallacies and ignores the core issue: the staggering cost relative to the actual work performed.

Let’s break down your points using the Council’s own report:

1. On “No Outages” and “You Should Think They’re Not Doing Anything”:
This is the “nothing bad happened, so they must be working” fallacy. The network’s stability is a result of many factors, primarily the strength of the core protocol code. The Security Council is a last-line governance defense.

The report itself quantifies their emergency work: only three genuine emergency upgrades in 14 months. This does not describe a team constantly fighting fires. It describes a group that is occasionally and critically important. The question is whether that occasional work justifies a $1.1M/year price tag. We can have security without gold-plating it.

2. On “Reviewing All Code and Contracts”:
This is a misrepresentation of their duties. The report is clear: they reviewed thirteen (13) ZIPs in over a year. This is not a continuous, full-time audit of “all code.” It’s a part-time governance and multisig signing process for pre-vetted upgrades. Describing it as a relentless, all-encompassing task is simply not supported by the facts in their own report.

3. On the Airdrop Exploit:
You’re correct that the initial breach wasn’t their fault. But you can’t have it both ways. The Council’s report proudly uses the successful recovery of the funds as a major justification for their existence and value. If they get to claim that win, then the community gets to question the budget that win is used to justify. It’s all part of the same financial picture.

No one is arguing to eliminate the Security Council. We are arguing for fiscal responsibility .

The report shows a council with a manageable workload, yet its budget allocates 80% ($886,400) directly to member compensation , averaging over $6,100 per member per month. For the work described, this is excessive.

We can and should have a robust security council funded at a level that is sustainable and proportional to its actual, demonstrated workload. Defending the current budget as “non-negotiable” is to ignore the data in the very report you’re telling us to read. Security is essential; wasting community funds is not. We can have the former without the latter.

Hello Golem
Thank you for taking the time to respond and share your perspective. I’d like to add a few comments and clarifications from my side:

  1. “The ZKsync Security Council is a non-negotiable.”The Security Council is funded through the Token Assembly, which means its existence and financing are ultimately determined by token holders. Given that, it seems inaccurate to describe it as non-negotiable.

  2. “Have you noticed how there has never been an outage where all ZKsync chains have gone down as happens in other ecosystems?”The stability of the ZKsync networks has primarily been the result of Matter Labs’ thorough engineering practices rather than the Security Council’s oversight. Since 2021, I’ve personally observed how the team rigorously tests and audits code before any deployment. ZKsync Era, for example, ran for over a year on testnet and underwent multiple audits before mainnet launch. The network operated stably long before the Security Council was even established.

  3. “If you believe in ZKsync and want the Elastic Network to grow, you need a strong and legitimate Security Council.”I completely agree that a Security Council is vital for the network’s long-term resilience and decentralization. My concern is more about timing and efficiency. Currently, all protocol upgrades and audits are managed by Matter Labs, which remains the sole core developer. In this context, funding an additional organization to review Matter Labs’ work may not be cost-effective until there is a broader contributor base or until ZKsync Era reaches Stage 1 decentralization. A comparable example could be the Ignite program, which was temporarily paused when it no longer aligned with the current stage of development. The same logic could apply here — to resume or scale funding once there’s a tangible operational need.

  4. “They review all code, all contracts, and all potential security issues.”If the Security Council indeed reviews all code and contracts, it raises a question about the purpose of the separate audit expenditures, which reportedly amounted to millions of dollars. If the Council performs such comprehensive reviews, the costs and scope of external audits should logically be reconsidered.

  5. “Regarding the leftover airdrop tokens and the compromised admin account…”While I understand that incident initially fell outside of the Security Council’s official scope, the fact that they later participated in the recovery process suggests some overlap in responsibilities. This creates a bit of confusion — if the Council is tasked with ensuring protocol security, should they not be responsive to major security concerns regardless of predefined boundaries?

In summary, I’m not questioning the importance of having a Security Council — only the necessity of maintaining and funding it at this particular stage. It might be more pragmatic to revisit its role and budget allocation once the ecosystem has matured and multiple development teams are contributing to the protocol.

2 Likes

As of now I didn’t hear any proper reasons why SC should be financed now

2 Likes