As part of its governance, the Arbitrum DAO incorporates a Security Council that can take certain emergency and non-emergency actions:
The first election to replace the first cohort of Security Council Members is expected to begin on the 15th September.
The code representing the proposed architecture is final and available for full review in: https://github.com/ArbitrumFoundation/governance/commit/46dd56f55f4e0d96548fb6546122d47623c7a804.
The work has already been audited by Trail of Bits and the identified issues have been patched, the full audit report is available here.
A Code4Rena audit competition has also been completed for the election system.
An overview of the election process as described by the Constitution alongside the process for how to enact a code change to Arbitrum’s smart contract suite:
Comment
An understanding of the following smart contract suites will help the reader evaluate this proposal as it re-uses several components:
The Constitution specifies that membership of the Security Council is split into two cohorts. Every 6 months, all positions in a single cohort are put up for election.
The proposed election implementation, which must adhere to the specification laid out in the Constitution, is split into:
The election process and update stages are performed via on-chain smart contracts. A brief overview of each stage includes:
Process for selecting and voting for the new cohort of Security council members.
Process to install the newly elected cohort of Security Council members into the Arbitrum smart contracts.
This stage consists of handling election timing, candidate registration, candidate endorsement:
The nominee selection process is implemented by the SecurityCouncilNomineeElectionGovernor contract.
It inherits most of its functionality from the Open Zeppelin Governor contracts and we have extended it with an extra feature:
The governor contract has the following characteristics:
The Foundation will be given 14 days to vet the prospective nominees. If they find that a candidate does not meet the compliance check, they can exclude the candidate from progressing to the next stage. Note that grounds for exclusion could include greater than 3 members of a given organisation being represented in the nominee set (as described in section 4 of the Constitution).
The foundation can exclude a nominee by:
The Governor smart contract enforces the 2 week time period and the Foundation must exclude nominees by this deadline.
Once the compliance check has completed:
If there are less than 6 eligible nominees, then the Foundation will consult with outgoing members of the cohort on whether they will continue in this role for another 12 months. Members of the existing cohort may be selected at random to fill the remaining seats.
The voting process can begin once a set of compliant candidates have been successfully nominated.
The voting process is designed to encourage voters to cast their vote early. Their voting power will eventually decay if they do not cast their vote within the first 7 days:
Additionally, delegates can cast votes for more than one nominee:
The Security Council member election will take place in a separate SecurityCouncilMemberElectionGovernor contract which will also inherit from Open Zeppelin Governor contracts.
After the 14 day waiting period for the compliance check, anyone can trigger a new member election:
The SecurityCouncilMemberElectionGovernor includes:
At the end of the 21 days of election:
The security council manager is a contract which contains the canonical list of security council members, and which cohort they are part of. When a member election completes, the manager updates its local list of the current cohorts then forms cross chain messages to propagate those updates to each of the Security Council Gnosis safes.
The manager also provides some additional functionality to allow the security council to:
The manager functionality is contained within a custom SecurityCouncilManager smart contract. Since the SecurityCouncilManager is indirectly able to make calls to the standard UpgradeExecutor contracts which have far reaching powers, special care must be take to ensure the manager only makes council member updates.
Calling the UpgradeExecutors on each of the chains requires navigating withdrawals transactions, timelocks and inboxes, the SecurityCouncilManager outsources the calldata creation for these routes to a UpgradeExecRouteBuilder contract.
Constitutional DAO proposals all pass through:
You can read more about these stages in the governance docs. The purpose of these delays is to ensure that users wishing to withdraw their assets before the proposal is executed will have the time to do so. Changing the Security Council members should also provide this guarantee, so after the election has completed and before the Security Councils are updated the update message also goes through these same stages. The update message will use the existing timelocks to enforce these delays.
The existing governance timelock contracts are used as part of this flow.
The SecurityCouncilManager is given the PROPOSER role on the L2 timelock enabling it to create messages that will eventually be received by each UpgradeExecutor.
The new Security Council members need to be installed into 4 Gnosis safes:
The old cohort of members will be removed, and the new cohort will replace them.
To do this the existing Upgrade Executor contracts on each chain will be installed as Gnosis Safe modules into the Security Council safes. A custom Governance Action Contract will be used to call the specific OwnerManager addOwnerWithThreshold and removeOwner methods on the Gnosis safes.
The Constitution also declares some other additional affordances to certain parties
The proposed implementation mostly satisfies the specification outlined by the Arbitrum Constitution. There are some minor changes that are required to the Constitution’s text to take into account the time it takes to install new candidates and to support compliance procedures set out by the Arbitrum Foundation.
Note, the final wording for how to update the Constitution will be provided in a later revision. We simply want to notify the requirement that the text needs to be changed. At this stage, our request for feedback is focused on the implementation details of the smart contract suite.
The Section 4 of the Constitution contains the text:
From T until T+7 days: Any DAO member may declare their candidacy for the Security Council; provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort. To the extent that there are more than six candidates, each eligible candidate must be supported by pledged votes representing at least 0.2% of all Votable Tokens. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
From T+7 days until T+28 days: Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+14 days will have 100% weight. Votes cast between T+14 days and T+28 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+14 days, decreasing linearly to 0% weight at T+28 days.
At T+28 days: The 6 candidates who have received the most votes are elected and immediately join the Council, replacing the Cohort that was up for re-election.
We need to make three changes to the Arbitrum Constitution:
With the above in mind, we propose an update to Section 4 of the Constitution with the following text:
Nominee selection (T until T+7 days): Any DAO member may declare their candidacy for the Security Council; provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort. To the extent that there are more than six candidates, each eligible candidate must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
Compliance process (T+7 until T+21 days): All candidates will cooperate with The Arbitrum Foundation and complete the compliance process. The Arbitrum Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
Member election (T+21 until T+42 days): Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+28 days will have 100% weight. Votes cast between T+28 days and T+42 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+28 days, decreasing linearly to 0% weight at T+42 days.
At T+42 days: The process for replacing the cohort of Security Council members with the 6 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new Security Council members are installed.
The Constitution contains the text:
The text gives an affordance to the Foundation to conduct a compliance check on the potential nominees. We propose to make this check an explicit stage of 14 days between Nominee Selection and Member Election to allow the Foundation to conduct these checks. Details of compliance checks will be provided by the Arbitrum Foundation at a later date.
We propose to update the Constitution with the following text:
For completeness, the amended text for Section 4 of the Arbitrum Constitution, including the changes from AIP-4:
The Security Council has 12 members, who are divided into two Cohorts of 6 members.
The initial Security Council Cohorts were determined by randomly splitting the 12 members into two 6-member cohorts - 6 members in the 'First Cohort' and 6 members in the 'Second Cohort'. The members of the initial Security Council Cohorts are detailed in a transparency report here.
The first Security Council election is scheduled to begin on the 15th September 2023 or the earliest possible date. The election can only begin upon the availability of an on-chain election process that is approved and installed by the Arbitrum DAO. This first election replaces the 'First Cohort'. The next election replaces the 'Second Cohort' and so forth.
The date chosen for the first election will form the basis for all future elections. Every election should begin 6 months after the previous election has started and it will replace its respective cohort of 6 members.
All Security Council members are expected to serve their term until the election is complete and the new Security Council members are installed.
The following timeline governs an election that starts at time T:
Nominee selection (T until T+7 days): Any DAO member may declare their candidacy for the Security Council; provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort. To the extent that there are more than six candidates, each eligible candidate must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
Compliance process (T+7 until T+21 days): All candidates will cooperate with the Arbitrum Foundation and complete the compliance process. The Arbitrum Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
Member election (T+21 until T+42 days): Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+14 days will have 100% weight. Votes cast between T+21 days and T+35 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+21 days, decreasing linearly to 0% weight at T+42 days.
At T+42 days: The process for replacing the cohort of security council members with the 6 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new security council members are installed.
The Arbitrum Foundation is allocated 14 days for the Compliance process and it should be executed between the Nominee selection and Member election. The Arbitrum Foundation has flexibility to update its compliance policy for every new election. This is required to allow The Arbitrum Foundation to comply with Cayman Island laws. Furthermore, The Arbitrum Foundation maintains the right to issue new procedures and guidelines for off-chain components of the Security Council election. All efforts should be made by The Arbitrum Foundation to ensure an orderly, fair, and transparent election.
As a matter of best practice for maintaining an independent Security Council, no single organisation should be overly represented in the Security Council. In particular, there should not be more than 3 candidates associated with a single entity or group of entities being elected to the Security Council, thereby ensuring that there will be no single entity or group of entities able to control or even veto a Security Council vote.
Furthermore, no candidate with conflicts of interest that would prevent them from acting in the best interests of the ArbitrumDAO, Governed Chains and/or The Arbitrum Foundation should be elected to the Security Council. Potential conflicts of interest could be, but are not limited to, affiliations with direct Arbitrum competitors, proven histories of exploiting projects and others.
The DAO may approve and implement a Constitutional AIP to change the rules governing future Security Council elections, but the AIP process may not be used to intervene in an ongoing election.
Security Council members may only be removed prior to the end of their terms under two conditions:
At least 10% of all Votable Tokens have casted votes "in favour" of removal and at least 5/6 (83.33%) of all casted votes are "in favour" of removal; or
At least 9 of the Security Council members vote in favour of removal.
The seats of Security Council members who have been removed prior to the end of their respective terms shall remain unfilled until the next election that such seats are up for appointment, unless otherwise replaced prior to such next election by a vote of at least 9 of the Security Council members, in which case such seat shall be up for appointment at the next such election. The Security Council may not re-appoint a removed member and they can only be re-elected via the election voting system.
As part of its governance, the Arbitrum DAO incorporates a Security Council that can take certain emergency and non-emergency actions:
The first election to replace the first cohort of Security Council Members is expected to begin on the 15th September.
The code representing the proposed architecture is final and available for full review in: https://github.com/ArbitrumFoundation/governance/commit/46dd56f55f4e0d96548fb6546122d47623c7a804.
The work has already been audited by Trail of Bits and the identified issues have been patched, the full audit report is available here.
A Code4Rena audit competition has also been completed for the election system.
An overview of the election process as described by the Constitution alongside the process for how to enact a code change to Arbitrum’s smart contract suite:
Comment
An understanding of the following smart contract suites will help the reader evaluate this proposal as it re-uses several components:
The Constitution specifies that membership of the Security Council is split into two cohorts. Every 6 months, all positions in a single cohort are put up for election.
The proposed election implementation, which must adhere to the specification laid out in the Constitution, is split into:
The election process and update stages are performed via on-chain smart contracts. A brief overview of each stage includes:
Process for selecting and voting for the new cohort of Security council members.
Process to install the newly elected cohort of Security Council members into the Arbitrum smart contracts.
This stage consists of handling election timing, candidate registration, candidate endorsement:
The nominee selection process is implemented by the SecurityCouncilNomineeElectionGovernor contract.
It inherits most of its functionality from the Open Zeppelin Governor contracts and we have extended it with an extra feature:
The governor contract has the following characteristics:
The Foundation will be given 14 days to vet the prospective nominees. If they find that a candidate does not meet the compliance check, they can exclude the candidate from progressing to the next stage. Note that grounds for exclusion could include greater than 3 members of a given organisation being represented in the nominee set (as described in section 4 of the Constitution).
The foundation can exclude a nominee by:
The Governor smart contract enforces the 2 week time period and the Foundation must exclude nominees by this deadline.
Once the compliance check has completed:
If there are less than 6 eligible nominees, then the Foundation will consult with outgoing members of the cohort on whether they will continue in this role for another 12 months. Members of the existing cohort may be selected at random to fill the remaining seats.
The voting process can begin once a set of compliant candidates have been successfully nominated.
The voting process is designed to encourage voters to cast their vote early. Their voting power will eventually decay if they do not cast their vote within the first 7 days:
Additionally, delegates can cast votes for more than one nominee:
The Security Council member election will take place in a separate SecurityCouncilMemberElectionGovernor contract which will also inherit from Open Zeppelin Governor contracts.
After the 14 day waiting period for the compliance check, anyone can trigger a new member election:
The SecurityCouncilMemberElectionGovernor includes:
At the end of the 21 days of election:
The security council manager is a contract which contains the canonical list of security council members, and which cohort they are part of. When a member election completes, the manager updates its local list of the current cohorts then forms cross chain messages to propagate those updates to each of the Security Council Gnosis safes.
The manager also provides some additional functionality to allow the security council to:
The manager functionality is contained within a custom SecurityCouncilManager smart contract. Since the SecurityCouncilManager is indirectly able to make calls to the standard UpgradeExecutor contracts which have far reaching powers, special care must be take to ensure the manager only makes council member updates.
Calling the UpgradeExecutors on each of the chains requires navigating withdrawals transactions, timelocks and inboxes, the SecurityCouncilManager outsources the calldata creation for these routes to a UpgradeExecRouteBuilder contract.
Constitutional DAO proposals all pass through:
You can read more about these stages in the governance docs. The purpose of these delays is to ensure that users wishing to withdraw their assets before the proposal is executed will have the time to do so. Changing the Security Council members should also provide this guarantee, so after the election has completed and before the Security Councils are updated the update message also goes through these same stages. The update message will use the existing timelocks to enforce these delays.
The existing governance timelock contracts are used as part of this flow.
The SecurityCouncilManager is given the PROPOSER role on the L2 timelock enabling it to create messages that will eventually be received by each UpgradeExecutor.
The new Security Council members need to be installed into 4 Gnosis safes:
The old cohort of members will be removed, and the new cohort will replace them.
To do this the existing Upgrade Executor contracts on each chain will be installed as Gnosis Safe modules into the Security Council safes. A custom Governance Action Contract will be used to call the specific OwnerManager addOwnerWithThreshold and removeOwner methods on the Gnosis safes.
The Constitution also declares some other additional affordances to certain parties
The proposed implementation mostly satisfies the specification outlined by the Arbitrum Constitution. There are some minor changes that are required to the Constitution’s text to take into account the time it takes to install new candidates and to support compliance procedures set out by the Arbitrum Foundation.
Note, the final wording for how to update the Constitution will be provided in a later revision. We simply want to notify the requirement that the text needs to be changed. At this stage, our request for feedback is focused on the implementation details of the smart contract suite.
The Section 4 of the Constitution contains the text:
From T until T+7 days: Any DAO member may declare their candidacy for the Security Council; provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort. To the extent that there are more than six candidates, each eligible candidate must be supported by pledged votes representing at least 0.2% of all Votable Tokens. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
From T+7 days until T+28 days: Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+14 days will have 100% weight. Votes cast between T+14 days and T+28 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+14 days, decreasing linearly to 0% weight at T+28 days.
At T+28 days: The 6 candidates who have received the most votes are elected and immediately join the Council, replacing the Cohort that was up for re-election.
We need to make three changes to the Arbitrum Constitution:
With the above in mind, we propose an update to Section 4 of the Constitution with the following text:
Nominee selection (T until T+7 days): Any DAO member may declare their candidacy for the Security Council; provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort. To the extent that there are more than six candidates, each eligible candidate must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
Compliance process (T+7 until T+21 days): All candidates will cooperate with The Arbitrum Foundation and complete the compliance process. The Arbitrum Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
Member election (T+21 until T+42 days): Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+28 days will have 100% weight. Votes cast between T+28 days and T+42 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+28 days, decreasing linearly to 0% weight at T+42 days.
At T+42 days: The process for replacing the cohort of Security Council members with the 6 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new Security Council members are installed.
The Constitution contains the text:
The text gives an affordance to the Foundation to conduct a compliance check on the potential nominees. We propose to make this check an explicit stage of 14 days between Nominee Selection and Member Election to allow the Foundation to conduct these checks. Details of compliance checks will be provided by the Arbitrum Foundation at a later date.
We propose to update the Constitution with the following text:
For completeness, the amended text for Section 4 of the Arbitrum Constitution, including the changes from AIP-4:
The Security Council has 12 members, who are divided into two Cohorts of 6 members.
The initial Security Council Cohorts were determined by randomly splitting the 12 members into two 6-member cohorts - 6 members in the 'First Cohort' and 6 members in the 'Second Cohort'. The members of the initial Security Council Cohorts are detailed in a transparency report here.
The first Security Council election is scheduled to begin on the 15th September 2023 or the earliest possible date. The election can only begin upon the availability of an on-chain election process that is approved and installed by the Arbitrum DAO. This first election replaces the 'First Cohort'. The next election replaces the 'Second Cohort' and so forth.
The date chosen for the first election will form the basis for all future elections. Every election should begin 6 months after the previous election has started and it will replace its respective cohort of 6 members.
All Security Council members are expected to serve their term until the election is complete and the new Security Council members are installed.
The following timeline governs an election that starts at time T:
Nominee selection (T until T+7 days): Any DAO member may declare their candidacy for the Security Council; provided that a current Security Council member in one cohort may not be a candidate for a seat in the other cohort. To the extent that there are more than six candidates, each eligible candidate must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
Compliance process (T+7 until T+21 days): All candidates will cooperate with the Arbitrum Foundation and complete the compliance process. The Arbitrum Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than six candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their Cohort) until there are 6 candidates.
Member election (T+21 until T+42 days): Each DAO member or delegate may vote for any declared candidate. Each token may be cast for one candidate. Votes cast before T+14 days will have 100% weight. Votes cast between T+21 days and T+35 days will have weight based on the time of casting, decreasing linearly with time, with 100% weight at T+21 days, decreasing linearly to 0% weight at T+42 days.
At T+42 days: The process for replacing the cohort of security council members with the 6 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new security council members are installed.
The Arbitrum Foundation is allocated 14 days for the Compliance process and it should be executed between the Nominee selection and Member election. The Arbitrum Foundation has flexibility to update its compliance policy for every new election. This is required to allow The Arbitrum Foundation to comply with Cayman Island laws. Furthermore, The Arbitrum Foundation maintains the right to issue new procedures and guidelines for off-chain components of the Security Council election. All efforts should be made by The Arbitrum Foundation to ensure an orderly, fair, and transparent election.
As a matter of best practice for maintaining an independent Security Council, no single organisation should be overly represented in the Security Council. In particular, there should not be more than 3 candidates associated with a single entity or group of entities being elected to the Security Council, thereby ensuring that there will be no single entity or group of entities able to control or even veto a Security Council vote.
Furthermore, no candidate with conflicts of interest that would prevent them from acting in the best interests of the ArbitrumDAO, Governed Chains and/or The Arbitrum Foundation should be elected to the Security Council. Potential conflicts of interest could be, but are not limited to, affiliations with direct Arbitrum competitors, proven histories of exploiting projects and others.
The DAO may approve and implement a Constitutional AIP to change the rules governing future Security Council elections, but the AIP process may not be used to intervene in an ongoing election.
Security Council members may only be removed prior to the end of their terms under two conditions:
At least 10% of all Votable Tokens have casted votes "in favour" of removal and at least 5/6 (83.33%) of all casted votes are "in favour" of removal; or
At least 9 of the Security Council members vote in favour of removal.
The seats of Security Council members who have been removed prior to the end of their respective terms shall remain unfilled until the next election that such seats are up for appointment, unless otherwise replaced prior to such next election by a vote of at least 9 of the Security Council members, in which case such seat shall be up for appointment at the next such election. The Security Council may not re-appoint a removed member and they can only be re-elected via the election voting system.
The specs are in line with the process described in the DAO constitution, thus we are voting FOR its' implementation.
The specs are in line with the process described in the DAO constitution, thus we are voting FOR its' implementation.
I support this proposal, but I am voting Abstain as in transparency, Tally.xyz was selected to build this version of the Security Council Election software, so it seems reasonable that I should abstain as CEO of Tally.xyz
he change empowers a secure, transparent, and timely process for electing Arbitrum Security Council members, adhering to constitution guidelines, ensuring compliance, and maintaining a balanced, accountable governance structure, hence we are in favor of this proposal
I support this proposal, but I am voting Abstain as in transparency, Tally.xyz was selected to build this version of the Security Council Election software, so it seems reasonable that I should abstain as CEO of Tally.xyz
he change empowers a secure, transparent, and timely process for electing Arbitrum Security Council members, adhering to constitution guidelines, ensuring compliance, and maintaining a balanced, accountable governance structure, hence we are in favor of this proposal
@Goodo Very well said. To build a stronger security team
@Goodo Very well said. To build a stronger security team
While voting on AIP-6 closes on 20230903 and we ought not jump the gun prematurely, the distribution of votes is sending a strong signal. High level, the community is largely on board with a 'Security Council'. @nach211 made an interesting suggestion in Open Governance Call #5 that the community could extend this further to simplify UX in moments of market stresses. I think we could extend his proposal even further to broader kinds of adversarial behavior or regulatory change. On a first pass, a 'Technical Council' seems well-motivated in the sense of addressing some of the issues that @stonecoldpat and @krst are helping the community surface. On a second pass, a 'Technical Council' could help better manage (A) smart contract risk(s) [down the MEV rabbithole(s)] & (B) market risk(s). The DAO has a plethora of options open to it regarding ecosystem management. We could think of 'Council' layers above the base L2 as a mechanism [w/ suitable checks + balances] that can drastically improve the consensus process needed to achieve decentralized coordination.
If you keep pace with arbitrum governance, you can see the major changes they have made even since the year's beginning. It takes a lot of time and patience to even write and present a proposal in such a precise form; therefore, I appreciate you. A thorough selection of members is required since the security council is at a level where it can make emergency decisions. High levels of blockchain knowledge, developer and software understanding, as well as technical knowledge of Rollups and Ethereum, are, in my opinion, critical for their success. Furthermore, many thanks to Tally and @Frisson for allowing us to experience these votes as well as provide feedback.
We have to somehow get an opinion about specific people in a given Kohort. Maybe some reports? It is necessary to have a better group of people in the Research & Development Collective (ARDC) from elections to elections. There must be some form of rotation in a group but experience and acquired knowledge of people after 6 months cannot go in vain. Especially in the Security area.
This is now up for a vote on-chain
While voting on AIP-6 closes on 20230903 and we ought not jump the gun prematurely, the distribution of votes is sending a strong signal. High level, the community is largely on board with a 'Security Council'. @nach211 made an interesting suggestion in Open Governance Call #5 that the community could extend this further to simplify UX in moments of market stresses. I think we could extend his proposal even further to broader kinds of adversarial behavior or regulatory change. On a first pass, a 'Technical Council' seems well-motivated in the sense of addressing some of the issues that @stonecoldpat and @krst are helping the community surface. On a second pass, a 'Technical Council' could help better manage (A) smart contract risk(s) [down the MEV rabbithole(s)] & (B) market risk(s). The DAO has a plethora of options open to it regarding ecosystem management. We could think of 'Council' layers above the base L2 as a mechanism [w/ suitable checks + balances] that can drastically improve the consensus process needed to achieve decentralized coordination.
If you keep pace with arbitrum governance, you can see the major changes they have made even since the year's beginning. It takes a lot of time and patience to even write and present a proposal in such a precise form; therefore, I appreciate you. A thorough selection of members is required since the security council is at a level where it can make emergency decisions. High levels of blockchain knowledge, developer and software understanding, as well as technical knowledge of Rollups and Ethereum, are, in my opinion, critical for their success. Furthermore, many thanks to Tally and @Frisson for allowing us to experience these votes as well as provide feedback.
We have to somehow get an opinion about specific people in a given Kohort. Maybe some reports? It is necessary to have a better group of people in the Research & Development Collective (ARDC) from elections to elections. There must be some form of rotation in a group but experience and acquired knowledge of people after 6 months cannot go in vain. Especially in the Security area.
This is now up for a vote on-chain
This is one of the most important and critical elements of the “DAO Arbitration”, so if someone has transferred votes to a delegate, it may be worth considering returning to your own voting.
Offchain Labs engaged Trail of Bits to audit the work they did implementing the election system. The audit report can be viewed in https://drive.google.com/file/d/1HAogOJU3T9qXJPhf5d609ah2uD7U7n59/view?usp=sharing
The proposal is now on snapshot: https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xfd3551e2a0effc5d900e522b79300f68c351ec930cb05b62f537842508feceff
Please take some time to read the specification and the preaudit code: https://github.com/arbitrumfoundation/governance/tree/c18de53820c505fc459f766c1b224810eaeaabc5
Hi all,
The main proposal has been updated with new text :)
The preaudit code is available, so please have a look. We are hoping to get this proposal on Snapshot asap :)
This is one of the most important and critical elements of the “DAO Arbitration”, so if someone has transferred votes to a delegate, it may be worth considering returning to your own voting.
Offchain Labs engaged Trail of Bits to audit the work they did implementing the election system. The audit report can be viewed in https://drive.google.com/file/d/1HAogOJU3T9qXJPhf5d609ah2uD7U7n59/view?usp=sharing
The proposal is now on snapshot: https://snapshot.org/#/arbitrumfoundation.eth/proposal/0xfd3551e2a0effc5d900e522b79300f68c351ec930cb05b62f537842508feceff
Please take some time to read the specification and the preaudit code: https://github.com/arbitrumfoundation/governance/tree/c18de53820c505fc459f766c1b224810eaeaabc5
Hi all,
The main proposal has been updated with new text :)
The preaudit code is available, so please have a look. We are hoping to get this proposal on Snapshot asap :)
The proposed framework for rotating the security council into a new cohort seem to address all concerns and is in line with the constitution. I agree with the sentiment in the separate proposal that leeway for the Sep 15 date should be given to ensure confidence in security guarantees for the new contracts.
I look forward to hopefully registering as a candidate and partaking in the election!
The proposed framework for rotating the security council into a new cohort seem to address all concerns and is in line with the constitution. I agree with the sentiment in the separate proposal that leeway for the Sep 15 date should be given to ensure confidence in security guarantees for the new contracts.
I look forward to hopefully registering as a candidate and partaking in the election!
I will be voting in support of the proposal
I have voted in favor of the proposal. The changes are logical and adds clarity to the initial procedure. These aspects make for effective change and progress in our DAO procedures.
Tally's work on the Security Council Elections experience is progressing well. We are on track to deliver the user interface for the first Security Council Election on September 15th.
We expect to begin testing a staging version of Election Stage 1 in the coming weeks. If you're interested in testing and providing user feedback on what we're building, please send me a DM.
someone has to call? So terms are not a specific number of days, just a minimum number of days?
Correct (tho one can reasonably expect that it'll get called at just about exactly the 6-month mark each cycle)
For absolute clarity, this is a permissionless function that someone has to call? So terms are not a specific number of days, just a minimum number of days?
I am excited to announce that Tally will extend the Arbitrum DAO onchain governance user interface to support the Security Council Proposed Implementation Spec.
The Security Council plays an important and powerful role in the Arbitrum DAO. In case of emergency, the Security Council has the ability to bypass the normal constitutional proposal process (which requires many weeks to execute). The Security Council also has the ability to block DAO proposals, providing an important check-and-balance against the power of ARB token holders.
I am excited to announce that Tally will extend the Arbitrum DAO onchain governance user interface to support the Security Council Proposed Implementation Spec.
The Security Council plays an important and powerful role in the Arbitrum DAO. In case of emergency, the Security Council has the ability to bypass the normal constitutional proposal process (which requires many weeks to execute). The Security Council also has the ability to block DAO proposals, providing an important check-and-balance against the power of ARB token holders.
While the Security Council plays an important and powerful role in the Arbitrum DAO, it is itself beholden to ARB token holders. Security Council Members can only be elected and therefore added to the Security Council multisig via onchain vote by ARB token holders every six months.
The Security Council Elections experience on Tally will be integrated into the existing interface where ARB delegates and token holders already participate in onchain governance of the Arbitrum DAO. Tally will implement an end-to-end Election process that fully supports the smart contracts developed by Offchain Labs for Arbitrum Security Council Elections, including:
Tally is honored to serve as the decentralization stack for the Arbitrum DAO, powering chain upgrades, treasury spend, and now elections. Thank you for supporting our work. We can’t wait for you to use Tally to participate in Arbitrum Security Council Elections!
I will be voting in support of the proposal
I have voted in favor of the proposal. The changes are logical and adds clarity to the initial procedure. These aspects make for effective change and progress in our DAO procedures.
Tally's work on the Security Council Elections experience is progressing well. We are on track to deliver the user interface for the first Security Council Election on September 15th.
We expect to begin testing a staging version of Election Stage 1 in the coming weeks. If you're interested in testing and providing user feedback on what we're building, please send me a DM.
someone has to call? So terms are not a specific number of days, just a minimum number of days?
Correct (tho one can reasonably expect that it'll get called at just about exactly the 6-month mark each cycle)
For absolute clarity, this is a permissionless function that someone has to call? So terms are not a specific number of days, just a minimum number of days?
I am excited to announce that Tally will extend the Arbitrum DAO onchain governance user interface to support the Security Council Proposed Implementation Spec.
The Security Council plays an important and powerful role in the Arbitrum DAO. In case of emergency, the Security Council has the ability to bypass the normal constitutional proposal process (which requires many weeks to execute). The Security Council also has the ability to block DAO proposals, providing an important check-and-balance against the power of ARB token holders.
I am excited to announce that Tally will extend the Arbitrum DAO onchain governance user interface to support the Security Council Proposed Implementation Spec.
The Security Council plays an important and powerful role in the Arbitrum DAO. In case of emergency, the Security Council has the ability to bypass the normal constitutional proposal process (which requires many weeks to execute). The Security Council also has the ability to block DAO proposals, providing an important check-and-balance against the power of ARB token holders.
While the Security Council plays an important and powerful role in the Arbitrum DAO, it is itself beholden to ARB token holders. Security Council Members can only be elected and therefore added to the Security Council multisig via onchain vote by ARB token holders every six months.
The Security Council Elections experience on Tally will be integrated into the existing interface where ARB delegates and token holders already participate in onchain governance of the Arbitrum DAO. Tally will implement an end-to-end Election process that fully supports the smart contracts developed by Offchain Labs for Arbitrum Security Council Elections, including:
Tally is honored to serve as the decentralization stack for the Arbitrum DAO, powering chain upgrades, treasury spend, and now elections. Thank you for supporting our work. We can’t wait for you to use Tally to participate in Arbitrum Security Council Elections!