Charters outline the scope, responsibilities, and resources required of a Representative Structure. They are binding documents, as they are approved by governance, and therefore may not be materially changed without governance approval. If ever a discrepancy arises between a Charter and the Internal Operating Procedures (IOPs), Charters take precedence and supersede the IOP.
This Charter outlines the structure and responsibilities of the [structure name] and its participants. It is authored and maintained by the Optimism [structure name.]
This is the Season [ X ] Charter, which supersedes and replaces the Charters of all previous Seasons.
Goals
[This section should be brief and outline the high level goals of the structure, encompassing the full scope for the current Season. You may also include “non-goals” to explicitly outline things that are not in scope for a particular Season or structure.]
Examples
- You can reference the Security Council Goals section here
- You can reference the Grants Council Goals section here
- You can reference the Anticapture Commission Goals section here
- You can reference the Feedback Commission Goals section here
Structure
Signing Structure
The [structure] will operate a [Gnosis Safe] multisig wallet, in accordance with the Collective Multisig Policy [Link when available]. The multisig will have a [X%] threshold. Each participant will control one key, with the exception of the Council Lead (who is not a key holder).
[Please indicate if any tooling will be used for permissioning. E.g. oSNAP, Hats Protocol, etc.]
Signing Actions
The [structure] multisig is responsible for [ X ] types of actions:
- [List all expected signing actions here.]
- You can reference the Security Council Charter signing structure section here
In the event any portion of a budget managed by a community multisig remains unallocated at the end of the Season, it must be sent back to the corresponding treasury.
Normal Circumstances
[Outline the actions expected to be taken under normal circumstances. Operational procedures should be outlined in Internal Operating Procedures.]
[Please include details on any additional roles or powers held by the multisig such as Delayed Upgrades, Challenging, or Veto rights.]
[Compliance with grants policies, KYC, may also be listed here.]
In typical cases, signing should be scheduled in advance and in accordance with the Collective’s governance calendar.
Emergency Circumstances
[If applicable, please outline the circumstances in which emergency actions may be taken. Detailed emergency response procedures may be outlined in the Internal Operating Procedures.]
If the [structure] ever utilizes this discretion, however, it should endeavor to provide the community with a prompt and comprehensive retrospective (within the bounds of any legal commitments to, or security requirements for, confidentiality) on the action taken and the rationale for it.
(Optional): Sub-committees
- Some structures may choose to sub-divide their operations into sub-committees to allow for specialization. Please outline any relevant sub-committees here.
-
For each sub-committee, please list:
- Goals / non-goals
- Number of members
- How members are assigned, appointed, or elected to sub-committee
- Consensus mechanism of members (e.g. simple majority, etc.)
- Any additional notes
Examples
- You can reference the relevant section of the Grants Council Charter here.
-
Participants
Cohorts and Election Terms
- Members may be appointed by the Foundation for an initial term, but are subject to election thereafter.
- After the initial term, all members of a [structure] will be elected at the start of a new term. Elected members serve for the duration of their term and must be re-elected to serve in future Seasons.
- Representatives should only serve in one elected position per term. There are no term limits for representatives, but they may be implemented in the future if the need arises.
(Security Council Only): Eligibility
Participants on the Security Council should be selected in accordance with the following criteria:
- Technical competency. Baseline proficiency with the OP Stack and secure key management and signing standards.
- Reputation. Known, trusted individuals or entities that have demonstrated consistent alignment with the Optimistic Vision.
- Geographic diversity. The number of participants that reside in any country should be less than the quorum required for multisig action. To avoid requiring participants to publicly disclose their physical locations, this requirement will be enforced by the Optimism Foundation as part of the eligibility screening process.
- Diversity of interests. No more than 1 participant is associated with a particular entity, or that entity’s employees or affiliates.
- Alignment. Participants should not possess conflicts of interest that will regularly impact their ability to make impartial decisions in the performance of their role.
In addition, all participants will be required to pass an eligibility screening process before being added to the Council. This process may include KYC and sanctions screening and a requirement that the member sign a standard contract, which will be implemented at the discretion of the Optimism Foundation.
Responsibilities
Members
Leads
-
All representative structures must have Leads. The Lead is always a non-voting/non-signing member, so they remain focused on procedure and operations and may be considered unbiased as they don’t participate in decision making.
-
The Council Lead’s role is procedural, communicative, and ministerial. It has no ability to influence the substantive decisioning making by members or signing by key holders.
-
The Lead may break a tie in the case that members cannot come to consensus or temporarily fill the role of a member who has resigned or been removed.
-
[Please list all Lead responsibilities]
Examples
- You can reference the Security Council Lead Responsibilities section here
- You can reference the Grants Council Lead Responsibilities section here
- You can reference the Developer Advisory Board Lead Responsibilities section here
- You can reference the Anticapture Commission Leads Responsibilities Section here
- You can reference the Collective Feedback Commission Lead Responsibilities Section here
Resignation process
- If a member wishes to resign before the end of their term, they must appoint a replacement and communicate this change to the Lead at least 7 days prior to this change taking effect. If a Security Council member resigns, any replacement must be elected in the next nearest voting cycle.
- The Lead will then adjust quorum/ signing thresholds as needed and communicated the change through the structure’s Communication Thread.
- Any time a key holder is removed from a [structure], the threshold may also be reduced as long as the ratio of the threshold to the number of signers remains above the requirement outlined in the Collective Multisig Policy [to be linked when available]. If the number of Security Council signers is reduced below 8, then a safety mechanism is activated which hands control of the Security Council to the Foundation.
Accountability
- All [structure] members are subject to Representative Removal as outlined in the Operating Manual. Removal votes will occur before the end of the next voting cycle. Please see Representative Structure Framework for additional details about edge cases related to removal.
-
All representatives may be removed from their position for failing to uphold the responsibilities outlined in the relevant Charter or for failing to act with honesty, integrity, and transparency. If there is a vote to remove a representative, the Lead, or a simple majority of the remaining membership, may appoint a replacement for the remainder of the term. If a Security Council member is removed, a contingent vote for their replacement on the Council will run in the same voting cycle (the next nearest voting cycle.)
Special Considerations for the Security Council
-
The Security Council can act unilaterally to remove a participant who fails to satisfy the requirements of this Charter if such failure falls within the defined scope of the Council’s emergency powers (see “Structure – Emergency Response” above).
-
Security Council members may be removed for failure to satisfy the requirements of this Charter immediately via an Emergency Response. A vote for their replacement on the Council would run in the next nearest voting cycle.
-
Additionally, if a Security Council key holder fails to prove access to their keys by satisfying the requirements of a scheduled liveness check (see “Participants – Responsibilities,” above), that participant will be automatically removed from the Council. A vote for their replacement on the Council would run in the next nearest voting cycle.
-
Any time a key holder is removed from the Council, the threshold may also be reduced to as long as the ratio of the threshold to the number of signers remains above 75%. If the number of signers is reduced below 8, then a safety mechanism is activated which hands control of the Security Council to the Foundation.
-
- The [structures] will conduct a retrospective at the end of term which will be posted to the forum by the last day of the term.
- While persistent structures will be assumed to be renewed each Season, delegates may submit Dissolution Proposals if they believe a persistent structure is no longer fulfilling its mandate and should be discontinued.
Budget
-
A Proposed Budget, linking to this Charter, will be proposed by each prospective Lead, subject to approval by governance. The Lead may propose a budget that contains variable rewards for members, provided that the evaluation algorithm for rewards is approved by a simple majority of members by the end of the first month of the term.
-
Budget proposals must follow the template outlined here.
Examples
Iteration
The canonical version of Charters for persistent structures will be published to GitHub. Any material updates to the Charter will be reflected with a new version number at the top of this document, at which point the updated version will go into effect.
The Security Council Charter cannot be altered in any way that would have the effect of fundamentally altering the security model of an OP Chain or constitute a de facto protocol upgrade without a corresponding governance vote. All other Charters, must seek governance approval for major changes to the scope, structure, responsibilities, or budget of the Charter.
It should finally be reiterated that the role of all structures are intended to be progressively and programmatically reduced over time, as its functionalities are no longer needed or can be effectively managed by other means. Ultimately, it is the goal of the Collective to reach a state of protocol and governance reliability that allows for the full and final dissolution of any non-essential structures.