Introduction
The Starknet Security Council is made up of 12 members who are both geographically and organizationally diverse. They are tasked with safeguarding the security of Starknet. The Council assesses proposed upgrades to the network’s core contracts and approves them if no security risks are identified. In the event of an emergency, the Council has the authority to expedite necessary actions.
Supporting SNIP
The security council V1.0 design is described in SNIP25.
Composition
The council will be composed of 12 security and blockchain experts and professionals, all of whom are committed to upholding Starknet’s values and ensuring the platform’s safety. They will collectively be in possession of a multisig key that can take some actions detailed below.
Duties and Responsibilities
- Security Risk Assessment: Evaluate upgrades to core contracts, ensuring no security risks.
- Emergency Response: Act quickly during emergencies to safeguard the Starknet protocol.
- Approval Process: Approve upgrades after thorough security vetting.
- Transparency: Provide detailed reports on any decisions, especially for rejected upgrades or emergency interventions.
The Security Council’s role is limited to ensuring the security of the network, and cannot reject upgrades for any reason outside of security.
Operational flows
Upgrade flow
Each upgrade flow will include two functions:
- Add_new_implementation: Declaring upgrade intent and context.
- upgrade_to: Apply upgrade
Flow 1: Vetted time delayed (regular)
This flow is not initiated by the Security Council and therefore, it needs to pass the maturity condition i.e. security vetting and time delay.
- Someone suggests (add_new_implementation) an update to one of the security council-controlled contracts.
- The security council vets the upgrade and votes on it. If it passes (>50% of members voted to approve), they send a tx with a multi-sig, marking the vetting as passed.
- The security council must put out a vetting report
- There is a 7 days time delay that starts once the upgrade was suggested.
- If the time delay and the vetting have passed the contract can be upgraded.
- If the time delay has passed and the upgrade hasn’t been vetted, it is considered rejected and the affected contracts can’t be upgraded.
Vetting failure report
In the event that the evaluation of an upgrade does not receive the requisite number of votes (50% for a regular action and 75% percent for an emergency action), the Security Council shall be obligated to produce a “Vetting Failure Report”. This report will be made publicly available within fourteen days of the vote on the upgrade and should provide a detailed account of the following:
- The rationale behind the negative votes cast by members.
- The rationale of the members who did approve of the upgrade, if such exist
- An enumeration of the issues identified with the upgrade.
- Potential avenues for resolving said issues, if feasible.
The Security Council’s sole grounds for either rejecting or approving upgrades will be security concerns.
Flow 2: Non-vetted, no time delay (emergency action )
This is an emergency flow, it is initiated by the security council; therefore, it is implicitly vetted as the issue was deemed by the security council to be time sensitive it forgoes the time delay.
- The security council votes on the proposed emergency upgrade. It needs 75% of Security Council members to approve it.
- The Security Council suggests the upgrade as an emergency upgrade.
- No vetting is needed, no time delay is in effect, and the upgrade takes effect immediately.
- The security council will put out a report explaining why they took this action.
| Flow | Upgrade Initiator | Threshold | Time delay |
|---|---|---|---|
| Vetted time delayed | Someone (currently, this is only SW or the security council) | 50% | Regular time delay |
| Non-vetted no time delay (emergency action) | Security council | 75% | None |
- Regular time delay should be set to at least 7 days to be in line with l2beat guidelines
Pausing flow
Each pausing flow will include two functions:
- Pause: Stopping the affected smart contract from further changes of statet.
- Unpause: Resuming normal operation
Flow 1: Pausing the contract
In case of critical incidents, a monitoring entity has the ability to pause the affected contracts immediately. This pause mechanism serves as a first line of defense to contain potential losses while the Security Council deliberates on a potential upgrade.
The security council is responsible for adding/removing authorized address(es) that can pause the contract.
Flow 2: Unpausing the contract
Once the security council decides that the smart contract can resume operation, it can unpause the contracts with a majority vote (50%).
Security Concerns
The security council shall be responsible for assessing the extent to which a security concern is present. Given the nature of such concerns, it is not possible to produce a comprehensive list, so below list is non-exhaustive and is provided for illustrative purposes only.:
- Smart Contract Vulnerabilities: Bugs, exploits, and vulnerabilities in smart contracts that can lead to theft of funds, manipulation of the network, or other unintended consequences.
- Attacks and hacks: Sybil, Denial of Service (DoS), Double-Spending, Phishing, Social Engineering.
- Stability and integrity issues
- Liveness issues
- Malicious or rogue nodes
- Oracle manipulation
Security Emergency
The Security Council is permitted to preemptively address actual or anticipated bugs, defects, unplanned maintenance, stability issues, integrity, availability, non-repudiation or other security issues with Starknet.
These emergency response measures may be taken without specific Governance approval.
If the Security Council ever utilizes this discretion, however, it shall provide the community with a prompt and comprehensive retrospective (within the bounds of any legal commitments to, or security requirements for, confidentiality) after the action taken and the rationale for it.
Eligibility
Members must meet the following criteria:
- Technical Competency: Familiarity with Starknet and secure key management.
- Reputation and Alignment: Trustworthy individuals aligned with Starknet’s vision and values.
- Diversity: Geographic and organizational diversity to prevent overconcentration. Less than 50% from any one country, and less than four people from the same organization.
- Screening: All members must pass KYC/AML checks and sign a standard contract accepting their responsibilities within the role.
Compensation
Council members receive a monthly stipend of 3,000 USD paid in STRK tokens for their contributions.
Council administrator
Is responsible for supporting the operation of the council he does not have a vote and serves in an administrative capacity by:
- Alerting key holders of upcoming protocol upgrades.
- Managing required timelines.
- Scheduling, setting agendas, hosting Council meetings, and facilitating discussions.
- Monitoring compliance with the procedures.
- Onboarding new Council participants.
- Communicating with external stakeholders.
Duties and Obligations
Availability commitment
The following communication channels should be responsive with a maximum delay of eight (8) hours:
- Phone call - goes through silent mode (installing Opus Genie);
- Telegram; and
- Email.
Note: In an emergency response, Committee members should be capable of responding with a laptop and a hard ledger wallet during drills involving a realistic emergency scenario.
Scope of Work/Services
Assess and improve StarkGate’s monitoring and security system, including:
-
Reviewing the monitoring service triggers for alerts.
-
Ensure that all essential assets are monitored.
-
Analyzing StarkWare’s monitoring in comparison with other services and chains.
-
Proactively surveying the monitoring agent’s dashboard and event detection to manually
-
identify suspicious activities and suggest alert improvements. (the “Services”)
Work Hours
- The Committee member is required to be on call twenty-four (24) hours a day, seven (7) days a
week.
- If the Committee member is not available on any given day, he must notify the council administrator at least twenty-four (24) hours in advance.
- Days of non-availability are not limited.
Finally, all Security Council participants are also responsible for complying with (i) the Code of Conduct of the Starknet governing body and (ii) any additional internal conflict of interest procedures that the Council may develop from time to time.
Starknet governing body Code of Conduct
In order to foster a community characterized by respect, inclusivity, and safety, all members of the Council are expected to adhere to the following principles:
- Active Participation: Members are expected to actively engage in discussions and decision-making processes.
- Accessibility: Members should remain accessible to the community through open discussions on the Starknet community forum.
- Ethical Behavior: Members should uphold the highest standards of ethics, integrity, professionalism, and accountability in all their interactions.
- Positive Communication: Members are encouraged to contribute to a positive and respectful culture of communication.
- Respect and Non-discrimination: Members are expected to conduct themselves in a respectful manner that promotes diversity and inclusivity. Members must refrain from engaging in any form of disrespect, including but not limited to hate speech, racism, misogyny, gender-based hatred, ageism, religious discrimination, discrimination based on sexual orientation, ableism, or ad hominem attacks.
- Non-Violence: Members are expected to avoid promoting or endorsing physical or verbal violent behavior, or any actions that may cause harm.
- No Abuse of Position: Members must not exploit their position within the Council to promise retribution or undue advantages to others.
- Conflict of Interests: Members are required to declare and, when necessary, withdraw from participation in cases where a conflict of interest arises.
- Confidentiality: Sensitive information obtained during discussions must remain confidential and must not be disclosed.
Adherence to these principles is essential to maintaining the integrity and effectiveness of the Security Council and fostering a harmonious and productive community.
Adding and Removing Members
The Starknet Foundation is responsible for appointing and compensating Council membership from a purely administrative perspective. The Starknet Foundation will similarly have the ability to remove council members purely from an administrative perspective - but only to the extent that the criteria below has been met:
Criteria for removal of council members:
(i) failure to adhere to the code of conduct;
(ii) failure to undertake security council duties and responsibilities;
(iii) a conflict of interest arises;
(iv) a member is responsible for a security breach;
(v) the member no longer possesses the technical or strategic knowledge that is needed for future security challenges; and / or
(vi) there is a wider community loss of confidence in a council member.
Security council phasing in
The Starknet security council V1.0 will be introduced in two phases.
Phase 1
In phase 1, the security council will have a duty to monitor upgrades affecting the Starknet staking core infrastructure.
This will include the following contracts:
- On Starknet
- Staking.
- Operator.
- Minting curve.
- L2 rewards supply.
- Delegation pool.
- On Ethereum
- STRK mint manager.
- L1 reward supplier.
Additionally, the SC will act as the:
- Security Admin on L2 Staking contract:
- Setting the security Agent - the entity that can pause the contracts.
- Can un-pause the contracts.
- Security admin on L1 STRK mint manager:
- Setting the security agent - the entity that can revoke allowance…
- Security agent on L1:
- Can revoke allowance in case of emergency.
See the following role diagram.
Phase 2
In phase 2, the security council will have a duty to monitor upgrades affecting all of Starknet’s core infrastructure.
This will affect all contracts listed in Phase 1, as well as several other contracts affecting the state of Starknet.