Protocol DAO Security Council

[peteris]

RPIP-33: Implementation of an On-Chain pDAO

Presently, the team has control over the pDAO “guardian”. This allows the team to immediately disable features of the protocol that may protect against loss of funds in the case of a protocol bug or exploit. This proposal removes this safety net. As a compromise, this proposal introduces a “Security Council” which has limited power to make immediate changes to the protocol. This Security Council needs to be maintained to always comprise active members who can react to potential threats.

Security Council membership is a serious role and the pDAO SHOULD develop strong entry requirements and processes for routinely flushing stale members. The development of these requirements and processes is left for a future RPIP.

Until we agree on how to appoint a security council, the guardian (controlled by the team) will be the sole member of the security council.

This topic is to discuss the requirements and processes to establish the security council.

The security council can currently do the following without a delay:

• Disable the deposit pool
• Disable creation of new minipools
• Disable converting 16 ETH minipools to 8 ETH
• Disable converting solo validators to minipools
• Disable RPL price updates
• Disable RPL and smoothing pool rewards submissions

(Complete list and more details are in the RPIP-33)

Points to discuss

Who can be on the security council?

What are the requirements to become a member on the security council?

If a security incident is reported each member should be able to evaluate it and decide how to react.

The more requirements we have for the members the fewer qualified candidates we’ll have.

Should the members be doxxed?

Should we have any restrictions? Like jurisdiction, conflict of interest, etc.

How many members?

How many members should there be on the security council and what should be the quorum?

The more the merrier because it’s harder to collude but many members and a high quorum can slow down the response.

Should there be any limits to how many people from the same cohort (e.g. Rocket Pool team, jurisdiction, etc.) can be on the security council?

Response time

How quickly are the security council members expected to react?

This will impact who will be interested in being on the security council and what kind of compensation they expect.

Can someone take some time off? How should this be handled?

Compensation

How much and how frequently should the security council members be compensated?

Drills

Should there be practice drills? If so, how frequently and who should organize them?

Punishment

What to do if a member fails to respond to an incident or doesn’t participate in a drill?

Election

How should the security council members be appointed?

Other duties

Are there any other duties the security council should perform? If we pay them we might as well make them earn it.

Leader

Optimism security council has one. They are responsible for writing post-morterms and run drills.

Should we have a leader? What are their duties? How are they chosen? What about compensation? What if they become unavailable?

Communication

How and where should the security members coordinate and be notified of security incidents?

Other

Anything else?

---

I suggest thinking about the answers yourself first before reading other posts.

[peteris]

peteris thoughts

Who can be on the security council?

Ideally they’d be technically proficient with Ethereum, Solidity, EVM, familiar with the Rocket Pool protocol and contracts and have a good track record in the community.

However, there are not that many people who meet these criteria. We could find technical people from outside the community but then we’d have to entice them with attractive compensation.

We could have no requirements so that anyone can be a member but then we could end up with a council full of influencers and figure heads.

Perhaps one half could be technical and the other half could be less technical.

We could also write a guide about how the Rocket Protocol works, how the settings the security council can change interact with everything else in the protocol so that anyone can become proficient.

So idk. I think there should be a wishlist/guidelines but no hard requirements. The pDAO can decide when voting if someone qualifies or not.

I personally don’t want to be fully doxxed. But how can you then know two addresses are not the same person? I’d say if it’s someone from the Rocket Pool community with a good track record then they can be anon or pseudo anonymous. Otherwise they should be fully doxxed.

I don’t think there should be any restrictions who can become a member. If Lord Voldemort wanted to become a member I’m sure the pDAO would be smart enough not to elect him.

How many members?

I think we should use L2beat’s guidelines that they use for evaluating the security councils of L2s.

Options are 6/8, 7/9, 8/10, 9/11, 9/12, 10/13.

I like 8/10. It’s not the minimum but not too many. The more people you have the harder it is to get everyone to sign.

No more than 2 people from the Rocket Pool team should be on the security council.

Response time

Ideally they’d react within 10 minutes. But then they need to carry their devices with them everywhere they go and have them within arm’s reach. People will not sign up for this unless they are well compensated for this 24/7 on-call duty.

Or it could be something more relaxed like 1 day or 3 days. But you can drain a lot of funds in 3 days and what’s the point of having a slow security council.

So it will likely have to be something between 1h (more realistic requirement than 10 min) and 1 day.

I think we need to decide whether we require a fast response (1-4h) or a slower one is acceptable (>4h).

Fast response requires you to sleep with your phone next to you and bring your laptop on your hike. You’d want to be compensated well for this inconvenience. Or we pay less but you can respond when you wake up or return from your hike.

Security council members should let the council know when they will be unavailable and for how long.

Compensation

I did some research on security councils (Arbitrum, Optimism, Polygon zkEVM, Taiko, Lido, EigenLayer, zkSync Era) and could only find information about Arbitrum. Arbitrum security council members are compensated $5,000 per month. But there’s no information about their response time requirements.

I personally think I’d be a very qualified candidate for the security council. However, I was on a 24/7 on-call for the past several years and I am not motivated to sleep with my phone next to me again, bring my laptop on hikes and go skiing with a laptop in my backpack. Unless the position is well compensated and I’d be a fool to refuse.

Compensation should be per one rewards period which is 28 days (or roughly 1 month but there’s 13 periods per year).

Scheduled unavailability should be deducted. It’s some admin work but straightforward.

Compensation should be denominated in USD but paid out in RPL.

Fast response (1h)

Would I do for $1? No way.
Would I do it for $1m. Of course.
What about $100? Nope, my sleep is worth way more than that.
What about $100k? Where do I sign.
How does $1000 sound? It’s good money in many parts of the world but not for me.
How does $10k sound? It’s a very good full-time salary so I’m down.
What about $2000? Not excited about it but would consider it.
What about $8000? Yes.

I think we’d find candidates who’d do it for $1000.

We’d have even more candidates for $2000-$5000.

Can we find people for lower e.g. $500? Maybe.

Slower response (12-24h)

Would I do for $100? Nope, not dragging my laptop with me for that.
Would I do it for $10k. Of course.
What about $500? Personally no.
What about $5k? Sure.
How does $1000 sound? Maybe.
What about $2000? Doesn’t sound bad for checking messages twice a day.

Not sure people would take the duties seriously for $100.

We’d likely find people who wouldn’t mind checking their messages twice a day for $500.

Even more for $1000.

Drills

There should be at least two random practice drills every period.

They could be organized by the leader or members take turns.

Punishment

Compensation should be paid out with a 3 period delay. Perhaps more, like 6.

If you fail to respond on time you forfeit unpaid compensation and are kicked out of the security council.

Election

I like how Arbitrum does it. Term lasts for 1 year. Every 6 months half of the members are up for election.

If someone leaves or gets kicked out the next candidate with the most votes can take their place.

We may want to set a minimum threshold of how many votes someone needs to get.

If we have no more suitable candidates they are replaced by members of the Rocket Pool team. Or maybe the guardian.

Other duties

I’d say no.

If they are technical they could review upgrades and smart node releases.

Not opinion on MEV monitoring.

Leader

I think we can avoid having one. Members can take turns running practice drills and someone will volunteer to write post-mortems or take turns writing them.

Communication

Private discord server for communication and coordination. No idea who should own it. Telegram as backup. Slack as another backup.

Use a PagerDuty-like service to send alerts to everyone. Any member can trigger them. Anyone from the Rocket Pool team can trigger them. Oracle DAO members and Rocket Scientists also.

All members need to expose their phone number to the council.

[Darkmessage]

@peteris

Who can be on the security council?

Perhaps one half could be technical and the other half could be less technical.

So if we have 8/10 but 5 of those are not able to analyze a situation themselves and just do whatever the other 5 tell them, then they have no value and we could just do 4/5. I don’t see why we should be paying somebody to press the button other people tell them to.

Thus, IMO, it’s worth paying more to get skilled people that do not let themselves be influenced by the masses and are able to analyze the problem and come to a conclussion themselves.

As you say, also response times are critical but also influence the willingness of people putting up with the ramifications of that.

So we could beginn hiring with strict rules and if we don’t find people, then we would lessen some aspects and the pay of course.

[NonFungibleYokem]

Who can be on the security council?

• I tend to think members should have sufficient skill to be able to independently verify incident reports - which means having the ability to read solidity smart contract code and understand the structure of the Rocket Pool contracts and their functions.
• Members need to have enough knowlege and skill to know what kinds of settings changes are appropriate for a given situation.
• As far as doxing goes - I think as long as there is more than a quorum’s worth of people who are either fully publicly doxed, or privately doxed to someone else in the community, then we can have one or two fully anon folks.

Commitee Size/Quorum/Composition

• I think it’s important to recognize that the RP security council has very limited powers compared to the councils in other protocols. The powers are all related to pausing deposits or the movement of funds within the protocol, and can’t withold withdrawals or change contracts. There are some additional powers proposed for Saturn (making small changes to commissions, possibly vetoing contract upgrades), but its still not a huge amount of power. So I think a simple majority with somewhat smaller size 6-10 works.
• I do like the concept of splitting the council into 2 election groups and an even number helps with that.
• Team and ODAO members should be limited to a small, non-quorum blocking number

Response Time

I think a somewhat slower response time (2-4 hours) is reasonable given the limited powers available to the council. The council can’t stop withdrawals, so they woundn’t be able to say, stop the deposit pool or the vault from being drained. But they could stop new validator deposits and assignments. And any funds on the beacon chain would take at least 27 hours to get withdrawn. Unbacked reth minting could be stopped, but I’m not sure that even a 10 minute response time would be fast enough to stop the damage from that kind of incident. Hacks that damage the content of the storage contract (say somehow overwriting withdrawal addresses) or injecting an unauthorized network contract would have the same response - stop new funds from coming into the protocol and discourage people from exiting while proper fixes from the ODAO get deployed.

I think we also need to recognize that there’s some variability in terms of defining “response”. Ie, a member can be away from home, and accept the call, participate in discussions and be fully engaged, but may be delayed from being able to sign a vote to change a setting until they can retrieve their signing device. And insisting on members carrying their device and a computer everywhere to enable faster response also has some risk due to loss or theft.

Compensation

• There’s a tension here in that ideally we’re paying folks to do nothing (other then drills and check-ins). But when we do need the members to respond - they need to respond. In my initial write-up I envisioned something like $30-$50 per day for this.
• The DAO doesn’t have a huge amount of money to spend, so compensation on the order of what Arbitrum pays I don’t think is appropriate. If that doesn’t get enough interest from qualified people then we could consider a smaller council at higher pay, or re-think the skills requirements.
• “Vacation” time does need to be part of the deal to allow members breaks from being on-call for periods of time.

Drills

• A drill a couple of times a year on a private deployment on holesky would go a long way to making sure everyone knew and was familiar with what they needed to do if a real situation came up.
• I also think some regular (but not predictably so) signed message check-ins are needed to make sure everyone’s keys are still available. We can’t have someone lose their keys and we only find out when its time to act.

Punishment

Kick from the council for total non-response (to a drill, missing a check-in, or a real incident) is reasonable.

Elections

Splitting the council into two groups elected for one year terms ever six months is good. It keeps the membership lively. We do need a process for getting the slate of on chain votes narrowed down - so an off-chain selection process like the MC elections is needed to decide who gets on-chain invite votes.

Other Duties

I tend to think the council should be very focused with limited powers to respond to reports that others (the team, whitehats, public incident reports, etc) have brought forward. If the dao wants to give the council other duties and powers - they can as long as they are clearly defined. For example, since it’s not the duties of the council to act on MEV theft, and there are no relevant powers they could use to respond, monitoring for MEV theft probably should stay out of the council’s duties. But if the pDAO specifically want to define such a duty and expectations -then it could be added.

Leader

I think some leader responsible for basic coordination to keep track of check-ins, vacations, and drills. But this member would not have any other special powers.

Communication

Multiple channels - discord, telegram, direct SMS, direct phone should be available. Probably there should be council set policy on which mechanisms are to be used in which situations and in what order. But there needs to be an emphasis on reliability and credible fallbacks.

Other

There needs to be a process figured out between the team and the council to decide how to handle critical vulnerability reports. The team may want to legitimately keep the details of the report under wraps to prevent premature leaks (inadvertant or otherwise). But there’s no point to having a community based council if they are simply totally trusting the team on their reports. I think a decent compromise might be that if there are members on the council from the team, who can fully brief other fully doxed members of the council, then there may still be enough members to reach a quorum without the pseudanon and anon members needing to act.

[Patches]

Who can be on the security council?

What are the requirements to become a member on the security council?

• Entities with strong technical resources and respectable security practices. I’m leaning against having too many individuals, for some reason.

Should the members be doxxed?

• Hard yes from me.

Should we have any restrictions? Like jurisdiction, conflict of interest, etc.

• We should have language around targeting diverse jurisdictions. We should not allow someone who serves as a member of one security seat to serve as an individual or member of another.

How many members?

How many members should there be on the security council and what should be the quorum?

• 10 feels right. 2/3rds quorum, so 7/10.

Should there be any limits to how many people from the same cohort (e.g. Rocket Pool team, jurisdiction, etc.) can be on the security council?

• Yes

Response time

How quickly are the security council members expected to react?

• A subway ride to one’s keys is rarely longer than 60 minutes, so, 60 minutes.

Can someone take some time off? How should this be handled?

• Yes, the council should coordinate so a quorum is always available.

Compensation

How much and how frequently should the security council members be compensated?

Gut says $50 per day is what you’d have to pay me to:

1. Constantly worry about being near my keys
2. Become an expert on the exact way the SCs work
3. Keep that knowledge extremely up-to-date
4. Participate in a pager rota that has the potential to rouse me in the wee hours

Drills

Should there be practice drills? If so, how frequently and who should organize them?

• Quarterly or twice a year

Punishment

What to do if a member fails to respond to an incident or doesn’t participate in a drill?

• Public shaming on strike 1
• Ejection on strike 2

Election

How should the security council members be appointed?

• pDAO vote

Other duties

• Review protocol changes (will be needed anyway to stay up to date on things)

Leader

Should we have a leader? What are their duties? How are they chosen? What about compensation? What if they become unavailable?

• The council should probably determine among themselves. No special comp nor formal status.

Communication

• Several modes should be used- eg, sms + email + discord.

Other

Anything else?

Multisigs present a good way to let seats establish rotations.

e.g. the Rescue Node maintainers have an interest in participating as a group, but we will likely want to split up the on-call hours. I think this should be permissible- we can campaign and apply transparently, use a 1/3 multisig, and since we span the clock in terms of timezones, can split active hours accordingly.

That said, adding a multisig to the council presents certain unanswered questions- is it ok to modify it, who decides who can join, etc.

[Valdorff]

Who can be on the security council?

I’d like to see it be technically strong folks, though I don’t think it’s important to be a specialist. This group’s time-critical role should be responding to specific threats that either have been seen (ie, there are transactions that can be traced) or reported (ie, someone is explicitly showing a path and ideally has a proof of concept issue). I think it would be nice to have ~2-3 solidity wizards with decent knowledge of the RP contracts, but I don’t think everyone need fit that mold.

There are other proposed duties for the security council, including vetoing oDAO proposals and executing some actions on behalf of the pDAO (eg, fast track node_share increase). These are not really time sensitive. What they do require is a significant degree of communication with the community. Similar to the hard technical skills, I don’t think this needs to be everyone, but having 1-2 people with a strong pulse on the community would be really great.

I think we should have few requirements. I think we should maintain a table of members, proficiencies, doxxed status, value of reputation, conflicts, jurisdictions. I see a high value pseudonymous reputation as a partial substitute for doxxing.

One thing I’d consider as a requirement, and at least as a suggestion, would be limiting participation to 1 member associated with the same entity (including the core dev team).

How many members?

An m-of-n council is stronger at preventing bad council actions with high m/n and high m. It is more expensive to have high n. Getting m signers is easier with high n.

The risk of confidential info being leaked or abused scales with n (any single bad actor is a risk). I actually believe this risk dominates taking bad actions as a council. Disabling everything would cause serious issues, require pDAO to replace the council, mess things up for weeks, and have downstream issues. But… abusing a known critical issue can drain contracts, eg, so that is a worse worst case.

Lockout risk isn’t as bad as most multisigs – the pDAO can simply replace the security council if it were locked out due to simultaneous loss of keys/members.

I think we should aim pretty low on n and high on m. Things like 4/5, 5/6, 5/7, or 6/7 come to mind. A small group also lets us be picky and try to find candidates that “have it all” or otherwise bring a lot to the table.

Response time

Total gut check: let’s say 3.5 hours
This does imply carrying a way to sign with you.

Compensation

I’d suggest escrowing 3 months of pay and then streaming payment.

Since I’ve chosen to go on the small side, I’d suggest paying on the high side. Maybe $40k/yr per seat. I think we should also have up to $50k discretionary budget for software, tools, and performing extra work (eg, pager infra setup, making guides to contracts or verification, running drills, writing postmortems, taking community questions, etc, etc) – the group can distribute this by vote imo.

Some pay context I had on-hand, though note it's over a year old (so especially stuff like TVL will be waaaay off)

• Arbitrum security council (12 ppl) getting $5k/month (usd denominated) = $60k/yr each and $720k/yr total. $2.2B TVL
• Balancer pays 11 people 500 BAL/6 months. Using an eyeball average of $8.50, this is $8.5k/yr each or $93.5k/yr total. $1.26B TVL.
• Hop: lead signer paid $6k/yr, other 4 signers paid $3k/yr. Net spend is $18k/yr total (USD denominated). $103M TVL.
• Aura: 7 members; not paid (couldn’t find any pay documented and a team member thought not). For “initial bootstrapping of the project and for governing key parameters”. $728M TVL.
• Aave: 10 members; not paid (read through all related governance posts). Can veto on-chain proposals. For V3, vote proposals in. Can emergency pause. $5.5B TVL.

Drills

I’d suggest ~20 drills a year. I’m imagining these as very simple – a 0-ETH transfer from the associated wallet with a specified message. This is how we did oDAO voting and it’s very easy to track in dune, eg.

Punishment

If someone is up to 1 hour late, I would give them a strike. One strike allowed per year. If someone gets a second strike, or is more than an hour late, they should be replaced.

If a drill had any strikes, it should not count towards the yearly count. Social pressure from peers is great.

If you get a strike, lose a month from escrow (and your next month goes there rather than streaming to you). If you’re kicked, lose the entirety of escrow.

Selection

I think we should do the same thing we do for MCs, with the exception of doing it in cohorts. I think 2-3 would be great. To me, the main advantage of using a cohort is that we could see part of what the group has already when deciding what else we wish to add to it. Re-election should be totally fine.

Other duties

I’ve mentioned the tokenomics rework has 3 proposed duties

• Veto malicious/incorrect oDAO proposals
• Speed up oDAO proposals, when directed by the pDAO
• Increase no_share under pDAO specified conditions

I think these add very little work.

In the pay section I ideated a bit around other ad-hoc duties that members might do.

Leader

I don’t think it’s necessary, but I don’t mind the group choosing to have one. If so, they should use their discretionary budget to pay them.

Communication

Something like opsgenie makes sense.

The group should also have private chat groups in at minimum 2 platforms. Ideally, one or more of these makes it easy to add external folks (eg a private discord server with reasonable permissions). Phone numbers should be known within the group.

---

Some thoughts reading what other folks wrote

• I think @NonFungibleYokem’s point about vacation time is fair, especially for the smaller size groups I suggest. On the other hand, I also suggest more pay. One possibility would be having the signers set up Safes and when they’re on vacation the two “next-in-line” members could then take over (set the Safe to 2-of-3). I need to think about this bit a little more.
• I tweaked my compensation numbers down a fair bit, though I’m still on the high end. Yokem convinced me to move some based on his description of the somewhat limited powers… but I still believe they have a lot of potential for abuse and trust is worth a premium. We’re pretty spread on total spend:
  • Yokem: $65.7k-$182.5k
  • Peteris (fast): $104k-$169k
  • Patches: $183k
  • Val: $250k-$330k
• I am strongly against multisigs as @Patches suggests. As I mentioned above, I think a bigger risk than a rogue council is a rogue member abusing information. Multisigs are a multiplier on that risk.

[haloooloolo]

Who can be on the security council?

I’d lean doxxed unless there is a significant amount of reputation built up. I say this with the understanding that some very qualified candidates may prefer to stay pseudonymous and I don’t think we can afford to lose them as options. We should definitely limit based on groups / entities. With a small council, this can be at most one member each.

How many members?

From a risk perspective, I’m leaning closest to Val in that I think aiming too high for council size poses a greater danger than too low. Say 5/7 sounds reasonable.

Response time

For response time I mostly agree with peteris. This seems like a fairly binary decision about whether we need very fast (<= 1 hour) responses for critical issues or we can live with this being multiple hours. If the former, we can and probably should offer higher compensation. I’d personally lean towards one hour unless we cannot find enough candidates.

Compensation

I’m very torn here. On one hand, the council, especially if small, will have a lot of responsibility to act in good faith. However, if pay becomes a primary motivator to join, we start targeting the people that would also be tempted to potentially exploit a reported vulnerability. Maybe start somewhere in the middle, around $1500 a month.

Drills

I’d start more frequent (e.g. every 1-2 weeks) shortly after induction and settle into something that’s closer to quarterly once the members have established they are able to respond in a timely manner.

Punishment

We should be strict here. If we assume a drill schedule like I suggested above, we can kick on second strike and have fairly fast turnaround to get to a reliable set of members as a result.

Election

Depends how many candidates we find. On-chain governance is expensive as we need a separate vote for each member. I’d say we find a list via Snapshot, similar to the committees and then formally invite them through pDAO proposals. It is going to be hard to get away from the popularity contest part of these things, but I don’t see a good way to avoid this while staying true to the protocol values for an election.

Other duties

I don’t think there should be any. If we feel like we are paying too much, we should decrease compensation instead of trying to add duties.

Leader

I don’t really like the idea of a leader. The security council members should be as independent of each other as possible and one person that takes on special duties, especially coordination, kind of goes against that.

Communication

This seems like something that can be agreed on pretty ad-hoc. Though I agree there should be some level of redundancy. Discord and Telegram or Discord and Signal for example.

[Patches]

If we elect organizations, it strikes me as odd to leave out multisigs. All the same risks apply, with less transparency.

If we only want individuals I worry we might be underpaying at $50 per day.

[Steely]

Who can be on the security council?

Tech & / or Security background and some ability to read smart contract code. With the limited set of buttons and knobs that can be tweaked, it seems more important to know exactly what they all do and the effects.

Doxxed - yes to all.

How many members?

5/7 to 7/10 sounds about right but no real preference.

Response time

Not sure what the requirements will be, but there is a massive difference between 1 hour and 4 hours. I have been on call for more years of my life than I want to remember and constant 24/7/365 (excluding holidays) can take a toll. Also with the shorter 1 hour time frame from a personal perspective it would not be the *16 hours a day I am not working / sleeping that would be an issue, but potential the *8 hours a day work time. Anyone with a “real” job is unlikely to be available in 1 hour timeframe then.

Compensation

Really not sure, but it has to be worth while to get the right people and cover the requirements of 24/7/365

Drills

1 per quarter sounds about right. I see suggestions as often as every 2 weeks - that could grate really fast (timezone dependant!)

Punishment

Agree with all comments above. Escrow funds then stream and forfeit if missed, and removal / replacement.

Election

pDAO vote / snapshot. Perhaps consider holding a list of “substitutes” that do not make the vote and paying a small (regular) retainer to be ready to immediately join should someone need to urgently leave, or be kicked.

Leader

If anything requires a “Leader” such as initiating test scenarios it should be on a round robin rota.

Communication

Would like to see old school backup methods (email / SMS) in addition to the usual suspects.

[Valdorff]

I’m against both organizations and multisigs (which as you imply are just a specific type of organization, and a structurally useful variant). I am higher on pay, so that seems to line up.

---

I like @haloooloolo’s idea of drills starting fast and ramping down after a little bit.

[peersky]

Hi Everyone.

I would like to introduce readers to offerings established entity, like OpenZeppelin can bring in to the Security Council.

Company mission is to secure an open economy. OpenZeppelin contracts library is the most used solidity smart contract source, has platform for code, audit deploy, monitoring and operate on blockchain.
Now these offerings expand to DAO specific as well.

OpenZeppelin experience with DAOs includes significant role as Security Partner for the Compound DAO, where they act pause-guardian and conduct wargames.
As leading security player, they take active participation in the SEAL Wargames initiative and security standards developed by EEA.

Beside that security work with Compound is wider and includes:

• Smart contract audits
• Governance proposal reviews
• Governance feeds & monitoring ( see their discord )
• Governance proposal execution automation
• Security & Market monitoring feeds ( see their discord )

Also recently stepped in as Arbitrum DAO security council member, where scope is similarly large, and includes ecosystem support and open-source development

Overall, I love the idea of being decentralized as much as possible… however for large protocols, the security council members must be well established participants that wide Eth community can trust.

If you have any questions or interest, I am in RPL Discord, always welcome to ping me in there

[peteris]

Does OpenZeppelin have any input on the questions in the original post?

[peersky]

I will speak for my personal experience and from myself.

You want to have firstly those who are trusted by community and are exceptionally competent in what RPL stack is based at.

That is, in my view:
Smart Contracts
DAO management
Consensus and Execution software
Node operations

That way security councils shall be able to respond to different vectors of threats, ideally covering all of them.

My list might be not fully inclusive, im just learning about rocket pool here.
However, I believe you already have done threat modeling and are aware of the threat directions you have.

Its a good thought to collaborate with those who already engaged on security aspects , such as audits.
Ideally, each part of the stack has someone managing its security

Also desired that software distributions are digitally signed by at least one security council members or a public entity that may be subject of other grants by the DAO.

Security council should be responsible generally for monitoring protocol security and managing any vulnerability.
It shall be council responsibility to propose security enchantments proactively. That is, if security drills showed any insufficient response due to lack of built in security measures, it shall be up for Security council to identify such, and create a grant proposal for enchantments.

Besides that, count, response time and compensation may be different, depending on member resource, commitment and desire.

[Valdorff]

@peersky

Security council should be responsible generally for monitoring protocol security and managing any vulnerability.
It shall be council responsibility to propose security enchantments proactively.

This is interesting, but a very much larger role than the one currently created by RPIP-33: Implementation of an On-Chain pDAO.

[peersky]

Personally, I do think that RPIP security council section looks too loose in scoping out responsibility.
Having well defined requirements would help community to define scope of coverage needed for the protocol, and have clear visibilty on stakeholders covering these.
I also think that’s okey to have it like this, as long as there is general sense of purpose. Such fundamental protocol roles take time to build up.

Workaround is ensuring there are specific partnerships (grantees) who close any gaps in outlined requirements.

For example:

In Compound DAO, Gauntlet handles risk management, while OpenZeppelin handles security services. Both operate in tandem, covering most prominent protocol threat vectors (financial insolvency & smart contract attacks ).
Here are their partnership proposals: 1, 2

This lets Multisig members (guardians) to stay similarly scoped to Contract Administrative Actions.
In practice, signer ability to perform will rely their decisions on expertise and situational awareness on these partners have, hence it does make sense if such partners are in the council.