You’re spending too much on your security council | A dive into how blockchain security councils work

This article was written to inform L2s and DAOs about security council spending and security strategy overall. Security is often a capital allocation game, and should be played as such.

This is an opinion piece, but you’ll also learn a lot. Thanks to Raza, Michael Lewellen, and Krzysztof Urbanski for reviewing.

SC = “Security Council”

Background

We, the Cyfrin team, were selected to serve on a new security council. After discussing and signing our first proposal, we were approached by another member of the SC, who said:

“I’m so glad you’re here. We finally have someone else actually checking the proposals.”

This is incredibly worrying.

About this post

In this post, I will be diving into the following issues:

1. What security councils do is vastly different from what the public thinks they do
2. The amount of money that goes into funding security councils may be inappropriate, given #1
3. And finally, the current expectations may not be being met, and it is difficult to tell whether they are anyways

The security community is going to lampoon me for this post, but I think it’s something incredibly important for projects to consider when allocating their security budget.

Why you should hear me out

At this time, Cyfrin as an entity (and I as an individual) are involved with several security councils as elected members. Some of the public ones are:

• ZKsync
• Optimism
• Abstract
• Story Protocol
• More

With myself being the signer representing Cyfrin in all of these (and if not me, I’m still making the yes/no final call on signing all transactions). Also, full disclosure: I get paid from security council work, and I’m still telling you to pay me less.

Let’s begin.

Context

Vitalik and the Ethereum community in general have walked back the L2-based roadmap dramatically.

Vitalik’s post about the future of L2s

However, until the L1 is scaled, L2s are still the current scaling solution, and they will still be relevant in the future as one of the types Vitalik defines above. One of the key pieces that he and the Ethereum community at large though hold true is this:

Be stage 1 at the minimum (otherwise you really are just a separate L1 with a bridge, and you should just call yourself that) if you’re doing things with ETH or other ethereum-issued assets — From X

Looking at L2Beat, we can see the criteria for an L2 to move from stage 0 to stage 1:

Image created based on the L2Beat Stages criteria

So essentially, in order for Vitalik and the ETH community at large to consider your product to be a true stage 1 L2, having a security council is the biggest blocker (after completing stage 0 requirements). A security council (for an L2 at least) is in charge of:

• Approving routine or emergency upgrades

So the question I wish to dive into in this article is, “Are you spending the correct amount of money on the security council to do these upgrades?” In going into this, we will also unveil the curtain on what goes on in security councils.

How much are council members getting paid, and for what?

The following is all from public data (forums, proposals, etc), if the data is not public, it is not included.

*OP 2024: Foundation-funded, amount not publicly disclosed

Looking at some of the top spenders, we can see approximately how much they spend per entity on the security council. Each setup has different payments depending on SLA, token vs USDC payouts, roles, etc.

Now, the ZKsync team should be applauded here, as they have refactored the security council based on how it went. You can see a pretty drastic reduction in payments from 2025 -> 2026. This is something that I can speak of from memory, as we’ve been with the ZKsync council for some time now.

Let’s talk about what security councils actually do, and see why this reduction makes sense, and see why more protocols may want to reduce this even more.

What are Security Council members supposed to do?

Most security councils “just sign transactions in a multisig”, and that’s it. However, the responsibilities should be:

Proposal Pre-vote

1. Make sure a proposal makes sense
2. Is it audited? Does it need to be? By whom? Are they reputable?
3. Make sure the proposal ID in Tally (or other UI) is correct
4. Make sure the list of upgrade calldatas reflects what the proposal describes

Proposal Post-vote

1. Make sure the ETH proposal ID is correct, and approve it if so
2. Make sure that when you sign, your signature reflects the proposal ID

Emergency Upgrades

1. Respond in a timely manner to red phone scenarios
2. Propose and enact emergency upgrades

Sometimes, this can include running transaction simulations (Optimism has Tenderly built into their signing pipeline, which is fantastic), or some other custom work, but the summary of these responsibilities is:

1. Check the calldata of the TX to make sure it matches what the org wants to do

Security Council vs Security Advisors

Now, there is a subset of “councils” that work more as “advisors” and may sign off on proposals/upgrades as well. I think this is a very valuable role, and it’s something that the Story Protocol does very well. Their security council is often pinged for advice; we discuss industry hacks and open dialogue on how changes in the security landscape should drive action on the Story team. In this scenario, I think it’s important to separate this from a “Security Council” that has defined on-chain roles they often act on, vs. “Security Advisors” who advise on actions. Most of the discussion in this blog is about “Security Councils” rather than “Security Advisors”.

The Security Council does not do the following

1. Audit the upgrades
2. Check if the upgrades do something outside of what they are supposed to do

This is important because Vitalik’s (and the ETH community at large’s) use of security councils as a “catch-all” for “why an L2 is still decentralized”:

Vitalik’s tweet on security council

Vitalik’s model assumes the 75% threshold works because independent members are actually verifying what they sign. But what if they aren’t? In practice, I just told you that security councils don’t verify that an upgrade won’t steal user funds_;_ they verify that the calldata approximately matches the proposal description. Those are very different levels of diligence.

Hmm.

Now, if we look at the list of proposals that the ZKsync security council needed to act on in 2025, we can also see how often the council needed to do this:

For ZKsync, it’s only the ZIPs that require actions

Each year, between 10 and 40 signing events are held. You can see ZKsync documented 16 total actions (upgrades or emergency upgrades) from Aug. 2024 — Sep. 2025, and Optimism documented 19 “ceremonies” for the first half of 2025 (Jan — Jun. 2025).

Now, in practice, between 10 and 40 times you need to sign a hardware wallet doesn’t sound so bad, and if you’re getting paid $60k a year to sign something 30 times, that’s essentially $2,000 per signature. Each signature should take a few hours to verify the calldata intent, which then maths out to maybe $500/hr, which is still a great deal for most firms.

However, let’s take an especially large improvement proposal. Here is the calldata for ZIP-3 (ZKsync Improvement Proposal 3).

ZIP3 transaction data

That is over 74,000 characters, where if a single character is wrong, that could be the piece of calldata that leads to funds being stolen. And not to mention, there are potential new contracts that have been deployed that this calldata is going to interact with, some of which could be upgradable.

So, as a security council member, there would be a few different ways to approach approving this transaction:

1. Vitalik’s hope: Take several days to make sure this calldata doesn’t have malicious side effects, and drop your hourly margin from $500/hr to $62.5/hour ($2,000 / 4 business days). Which means you’re losing money, because on a security audit, you’d make much more than that. Not a single security council member is doing this on any council, nor is this the expectation of any security council member.
2. Current actual expectations: Take a few hours to make sure the intent of the calldata matches the proposal, and run simulations. This usually comes down to calldata decoding and verifying anything you see in the UI by computing hashes or proposal IDs yourself. This is still valuable in itself, but it’s a shallow review rather than a deep one. Reviewing who conducted a deep audit of a proposal and ensuring the team did a good job is important.
3. What I expect most entities do: Just sign it and move on, keeping a $2,000/hr rate (since you skip due diligence), which is a “very, very good” rate, even for most firms with high security salaries.

There is zero recourse from the DAO for poor security council members. Most security council chats are private (which is a good thing), so it’s hard to keep them accountable. Once the paycheck comes in, there is very little incentive for them to be very good. So long as one other member of the council is actually checking, then they feel safe to sign off themselves. In practice, I often see everyone wait for one person to sign, and then everyone will sign after that one person, because they assume that one person has checked.

Given this data, if we want Vitalik’s mission to actually come to life, then a protocol should essentially spend the equivalent of 12 audits (one audit per security council member) to make sure nothing malicious happens, or **much less (**which we will get to), because the expectations of the security council are drastically lower than originally thought.

What actually happens

It’s very tempting to just take the easy route, and I have no “hard” evidence that other council members are skipping due diligence from the previous paragraph, but I have a lot of circumstantial evidence that some might be. On proposals with 74,000 characters of calldata interacting with newly deployed upgradeable contracts, a security council chat can contain zero technical questions from signers. Additionally, the Cyfrin team and I have created many tools for helping us approve L2 upgrades, signatures, and verifying what we are doing, and there is little to no discussion on those either.

Anecdotal evidence

We have some more anecdotal evidence, like the scenario we presented in the introduction of this article. Having several Security Council chats where no one says anything other than “signed” is quite eerie.

And finally, you may have seen my ERC-8213 proposal:

ERC-8213

This ERC comes directly from me trying to sign transactions in my day-to-day life, but particularly security council upgrades. Many hardware wallets still do not support EIP-712 digests, which means you have to check 300 pages of calldata to sign a security council upgrade on your hardware wallet. Or, everyone on a security council uses a small subset of hardware wallets that have this EIP-712 digest feature, and if one of those hardware wallets has a data breach, then the entire council is at risk.

And if you have to send any kind of transaction as part of your duties on an SC, welp, you’ll just have to go through potentially 100 pages of calldata to make sure it's correct. Have fun.

But Patrick, what about all the success stories?

From what I’ve seen, most “security council success storys” follow this path:

1. The foundation finds something out
2. Tells the security council, “Hey, sign this.”
3. Marketing happens about how the security council did a thing

Arbitrum’s two emergency patches, zkSync’s exploit recovery, Optimism’s fault-proof rollback — in every case, the core team identified the problem, and the SC followed instructions.

However…

The obvious counterargument to this is the fire department analogy: You don’t pay firefighters per fire; you pay them to be ready. But imagine discovering that your firefighters haven’t actually been inspecting buildings, and when the alarm goes off, they just assume someone else has already checked if the fire is real. That’s what I think is happening with security councils today.

Let’s get Mathy

So, how much should an L2 or DAO spend on a security council? $1M/year is a lot of money if it’s going to mindless auto-signers. So let’s get into what I think.

The math on these options assumes 12 SC members with 15 to 40 proposals a year.

1. It’s completely unfeasible to pay for the diligence of having 12 firms do a full audit on calldata. Every upgrade would have to have almost nothing interesting going on, with very little calldata, for this to make sense financially. This could cost maybe $10k-$25k per proposal per SC member, resulting in between $2M a year to $12M a year.
2. Checking calldata and running simulations is much more appropriate. $500/hr is more than plenty, and most proposals are not so complex that they take 4 hours (especially when Cyfrin has built tools to help). This can cost maybe $1k-$2k per proposal, resulting in between $200k a year to $1M a year. However, we lose some of Vitalik’s original vision with this option, and all those options below this.
3. The more minimal path we can take, with 8 SC members instead of 12, with low margins at $300 per proposal ($150/hr), and a promise to send deal flow to those auditors, where they should still be taking the responsibilities of number 2, could result in a cost of between $36k to $100k a year.
4. The most minimal path, and one that I think many projects will start to lean towards, is the “we trust AI, so we are going to use the cost reductions that come with it”. They will still have 8 security council members, but those members will use their AIs and pair them with tools specifically designed to check upgrades, making the time allotment even lower than normal. The AIs can even do minimal audits/reviews of all the codebases that the upgrades take. On this path, an L2 or DAO can run 8 SC members at $150 per proposal, resulting in between $18,000 and $50,000 per year.

With all of these paths, I think it would be good to “test” the councils once a year to make sure they are doing their duties correctly. It is very easy to just assume they are doing their job when they are not. Testing the councils is not something that I have seen, outside of onboarding with a quickstart. A simple test: submit a proposal with a deliberate discrepancy in the calldata and see who catches it before signing.

Of these options, the “just sign and move on” problem is worst in tier 3. If you drop pay too far, members won’t leave (the title looks good on a resume), they’ll just stop checking. “Quiet quitting” on a security council is an existential risk that looks identical to a functioning council until the day it isn’t. Tier 2 is the sweet spot for most protocols in 2026: pay enough that members feel the work is worth doing properly, but not so much that you’re subsidizing inattention. Of course, you can do something in between, reduce headcount, keep salaries, or reduce headcount and reduce salaries.

Now, all this being said, in the age of AI, we may be “ok” with just having our AIs read through transaction data and looking for issues, while actually being able to fulfill the original mission Vitalik’s looking for when it comes to security councils. But that also depends on the degree of decentralization of the AI models being used, and how much you think that is an appropriate substitute for manual checking, etc.

Security Councils are Still Important

What I am not advocating for is the removal of security councils. They are an important piece of the puzzle, but the perception of what they do is grossly different from what they actually do. But again, if we view security as a capital-allocation game, paying a bunch of blind signers is quite a waste.

Additionally, I do not blame security council members for “not doing more”. Many are doing exactly as they are expected to do. Many of them care deeply about the groups they work with and are looking to do their best (I think, in general, 85% of the web3 security community is collaborative and looking to do what’s right). However, the expectations historically have been weak, the community-wide perception is mismatched with reality, and as we proceed through the bear market, I think it’s important to cut spending where it’s not contributing to security.

I think Story Protocol has a better idea of how to use security councils; it has a smaller budget, recurring discussions, and a smaller team, which allows conversations to be more meaningful.

What is a better use of the money?

Off the bat, I think Guardians and audits are a much better use of funds. Aave, for example, has Certora review every proposal that goes through. ZKsync has a combination of Openzeppelin, Cyfrin, and others that do reviews. Having these is absolutely critical and a great use of funds. If anything, I’d like to see every DAO or L2 have every proposal go through such a review. I think having at least one team go deep on an issue/proposal is exponentially more valuable than 12 going very shallow on one. It is too easy to sneak malicious calldata into proposals, so having a group go through every single line I think is going to become increasingly important.

Case in point: the Tornado Cash governance takeover.

Tornado Cash governance takeover

Beyond proposal verification, there’s an even larger threat that security budgets should address:

In 2026, phishing and social engineering are likely to be the biggest threats to organizations, especially in light of the Drift Protocol Hack. Even with a security council, attackers are specifically targeting those with admin access. Many major hacks have come from compromised individuals on multisigs, including the Bybit hack, the Ronin bridge hack, the Wazirx hack, and more.

There are a LOT of ways you can defend against this, and we do a poor job allocating resources towards these threat vectors. As individual entities, you could put the money towards:

• EDR (Endpoint detection and response) devices for your signers.
• Purchase separate signing devices (another computer specifically for signing)
• Mandatory hardware wallet diversity
• Tooling for monitoring opsec setups (do you even know who your signers are?)

I think a much better allocation of those funds could be used to help the systemic issues we see:

• Blind signing (ERC-8213, ERC-7730)
• Private key management/trainings
• Staff trainings on phishing (shameless plug: Cyfrin Updraft)
• Better open-sourced monitoring tools (Defender is dead)
• Formal verification tooling (Kontrol, Halmos, HEVM could use some love…)

What Solana has promised after the Drift hack is exactly the type of things I’d like to see more ecosystems do and spend funding on— attack the systemic issues.

Why point the finger at security, Patrick?

This being said… I’d much rather cut down on other initiatives than security. There are plenty of examples in web3 where a company spends money on probably the dumbest thing that 13-year-old Patrick would have thought was cool. I’d much rather cut down on those. However, I’m going to stay in my lane, where our expertise is, and security initiatives are one of them.

Summary of Issues

Most large L2 protocols are spending too much on security councils, and maybe DeFi protocols are as well. Additionally, many people in the industry don’t realize that the original purpose of security councils is not being fulfilled. As mentioned, it’s against my financial interest to write this article, but it’s more disgusting to me to see projects fork over their money and get very little in return.

The other conclusions of this article are:

1. A lot of SC signers just blindly sign, and therefore, the funds are being wasted
2. The original philosophy of security councils is unfeasible by human means and at current pay levels
3. What people think security councils do differs from what they actually do

Receiving the ability to market yourself as a stage 1 L2, in my opinion, is not worth paying for theatrics.

Summary of Solutions

1. Reduce the security council's costs to match what they are actually doing. Use those funds instead for tooling, proposal audits, and fewer (but more engaged) members. A 5/7 where everyone is engaged and doing full verification is honestly better than a 9/12 where the majority are blindly signing. It also helps that a lower threshold can actually move more quickly in emergencies.
2. Run an annual fire drill with a deliberate calldata discrepancy
3. Mandate using tools to check a transaction matches the audited proposal (tenderly, simulation repo)
4. If we assume AI is good, then we can have both affordable and tier 1 (full audit of calldata) security councils in the near future, where everyone just runs their AI bot on the proposal end-to-end
5. Make sure a security council's expectations are strongly defined

Another shameless self-plug, all this being said, if you want to chat about how much you, your DAO, or L2 is spending on security initiatives, you know where to find the Cyfrin team and me. As you can see, this is something we are very passionate about.

People that I’ve worked with, who go above

Here is a short list of people/groups I’ve worked with who, through their work on security councils, go above and beyond to ensure that councils sign proposals correctly. There are many others who do good work too, but they do it especially well. Cyfrin and I work with many great teams on SCs who do good work. I also like how this list has a range of expertise, and I think it’s great that most security councils are not “just auditors” or “just people who care about technology Y”. Security has a large surface area, and it’s good to have specialists across sectors.

• Dedaub: Yannis Bollanos⁩, Dedaub is a competitor of Cyfrin’s, but I’d always advocate for having them on an SC with me
• pcaversaccio: Probably the most vigilant man on earth
• Opsek: ⁨Pablo Sabbatella⁩, opsec-related security initiatives
• alisha.eth: For coordination
• Michael Lewellen: Especially when it comes to DAOs and giving high-level input
• Raúl Martínez: From the story team, who takes advantage of having so many technical people to spark discussion

I sleep much better at night knowing they are on a security council with me.