Welcome to the Anticapture Commission Communication Thread!
The Anticapture Commission (ACC) is mandated to represent the interests of individual delegates as a key tokenholder group and to prevent the capture of the Token House by any single tokenholder or group of tokenholders, including protocols, OP Chains, etc. This program, introduced as an experiment in Season 5 , consists of high-impact delegates who meet the membership criteria outlined here and have opted in.
Expectations
This program is best understood as a temporary measure to increase votable supply via delegation to a targeted tokenholder group - similar to what we’ve done with the Protocol Delegation Program and proposed Chain Delegation Program. This is meant to be a short term delegation program that increases the voting power of our highest impact delegates.
In exchange for receiving this delegation, Commission members will uphold the specified levels of engagement and serve the very important role of bridging communication between the Token House and Citizens’ House.
The Commission will create this bridge between Houses by filing two types of reports. The Commission has no decision making power in the Citizens’ House; they may only serve as a warning system. Each report requires 4 delegate approval from Commission members to be considered valid. The Citizens’ House may, of course, choose to disregard or disagree with a report.
Read the full description here 13 .
Members
Brichis (Anticapture Commission Lead)
Gonna.eth (Grants Council Lead)
Gene (Code of Conduct Council Representative)
Blockchain @ USC
Butterbum
Ceresstation
GFX Labs
Griff Green
ITU Blockchain
Joxes (SEED Latam)
Katie Garcia
Lefteris
L 2 BEATs
Michael Vander Meiden
MinimalGravitas
MoneyManDoug
OPUser
PGov
She 256
StableLab
web 3 magnetic
404 DAO
Internal Operating Procedures 6
On January 17 th, the Anticapture Commission received a delegation of 10 M OP from the Governance Fund for Season 5 and 6 contained in this multisig 5 .
The post introduces the Anticapture Commission Communication Thread, a program meant to represent tokenholders' interests and prevent the capture of the Token House by any single entity. The program aims to increase voting power temporarily through targeted delegation to selected tokenholders and ensure effective communication between the Token House and Citizens' House. The Commission includes high-impact delegates who need to uphold engagement standards and act as a communication bridge. The members are listed, and the Commission received a delegation of 10 M OP from the Governance Fund for Seasons 5 and 6.
Welcome to the Anticapture Commission Communication Thread!
The Anticapture Commission (ACC) is man…
Welcome to the Anticapture Commission Communication Thread!
The Anticapture Commission (ACC) is mandated to represent the interests of individual delegates as a key tokenholder group and to prevent the capture of the Token House by any single tokenholder or group of tokenholders, including protocols, OP Chains, etc. This program, introduced as an experiment in Season 5 , consists of high-impact delegates who meet the membership criteria outlined here and have opted in.
Expectations
This program is best understood as a temporary measure to increase votable supply via delegation to a targeted tokenholder group - similar to what we’ve done with the Protocol Delegation Program and proposed Chain Delegation Program. This is meant to be a short term delegation program that increases the voting power of our highest impact delegates.
In exchange for receiving this delegation, Commission members will uphold the specified levels of engagement and serve the very important role of bridging communication between the Token House and Citizens’ House.
The Commission will create this bridge between Houses by filing two types of reports. The Commission has no decision making power in the Citizens’ House; they may only serve as a warning system. Each report requires 4 delegate approval from Commission members to be considered valid. The Citizens’ House may, of course, choose to disregard or disagree with a report.
Read the full description here.
Members
Brichis (Anticapture Commission Lead)
Gonna.eth (Grants Council Lead)
Gene (Code of Conduct Council Representative)
Blockchain @ USC
Butterbum
Ceresstation
GFX Labs
Griff Green
ITU Blockchain
Joxes (SEED Latam)
Katie Garcia
Lefteris
L 2 BEATs
Michael Vander Meiden
MinimalGravitas
MoneyManDoug
OPUser
PGov
She 256
StableLab
web 3 magnetic
404 DAO
Internal Operating Procedures
On January 17 th, the Anticapture Commission received a delegation of 10 M OP from the Governance Fund for Season 5 and 6 contained in this multisig.
Welcome to the Anticapture Commission Communication Thread! The Anticapture Commission (ACC) is man…
Welcome to the Anticapture Commission Communication Thread! The Anticapture Commission (ACC) is mandated to represent the interests of individual delegates as a key tokenholder group and to prevent the capture of the Token House by any single tokenholder or group of tokenholders, including protocols, OP Chains, etc. This program, introduced as an experiment in Season 5 , consists of high-impact delegates who meet the membership criteria outlined here and have opted in. Expectations This program is best understood as a temporary measure to increase votable supply via delegation to a targeted tokenholder group - similar to what we’ve done with the Protocol Delegation Program and proposed Chain Delegation Program. This is meant to be a short term delegation program that increases the voting power of our highest impact delegates. In exchange for receiving this delegation, Commission members will uphold the specified levels of engagement and serve the very important role of bridging communication between the Token House and Citizens’ House. The Commission will create this bridge between Houses by filing two types of reports. The Commission has no decision making power in the Citizens’ House; they may only serve as a warning system. Each report requires 4 delegate approval from Commission members to be considered valid. The Citizens’ House may, of course, choose to disregard or disagree with a report. Read the full description here 3 . Members Teresa Carballo (Code of Conduct Council Lead) Brichis.eth (Anticapture Commission Lead) Blockchain @ USC Butterbum Ceresstation GFX Labs Gonna.eth (Grants Council Lead) Joxes (SEED Latam) Katie Garcia Lefteris L 2 BEATs Michael Vander Meiden MinimalGravitas MoneyManDoug OPUser PGov StableLab web 3 magnetic 404 DAO Internal Operating Procedures 1 On January 17 th, the Anticapture Commission received a delegation of 10 M OP from the Governance Fund for Season 5 and 6 contained in this multisig 1 .
Updates - Voting Cycle # 17
During our inaugural cycle, we published our Internal Operating Proced…
Updates - Voting Cycle # 17
During our inaugural cycle, we published our Internal Operating Procedures (IOP) 8 and established public communication channels, including email and a Discord channel, with @vonnie 610 & @lavande support. Additionally, we tested the Snapshot Space for the ACC, hosted our first synchronous events, and vote from the ACC multisig for the first time:
Upgrade Proposal # 3 : Delta Network Upgrade 2
Vote: “For” ( 15 votes, unanimity)
Quorum: 15 / 7
Proposal to Reclassify Grant Misusage Enforcement 2
Vote: “For” ( 15 votes, unanimity)
Quorum: 15 / 7
Summary of Code of Conduct enforcement decisions
Vote: No votes
Quorum: 0 / 7
There have been multiple discussions regarding our role as the Anticapture Commission. We decided to address these topics in our first Internal Meeting, which is available for viewing here. Our initial focus was on the influence of 10 M OP in our governance and whether we should vote on all matters or limit our involvement, as our IOP does not specify this. We are currently discussing the process and the voting will start in the coming days and plan to amend the IOP during the Review Period of Voting Cycle # 18 . Once the draft is prepared, it will be submitted as a proposal in our Snapshot Space 2 . For this cycle, we decided to vote on all proposals due to the lack of a pre-established policy.
Another significant discussion revolved around the frequency of Office Hours. Some members suggested having one Office Hours per cycle for efficiency, considering that alerts may not be frequent. Others viewed it as an opportunity for individual delegates to engage with high context delegates about governance, not just capture, which would slightly alter the objective of the Office Hours. We are currently voting on this here 1 .
The third key discussion concerned the quorum for our Snapshot Space. Initially, 30 % was proposed before confirming the final number of members (currently 21 ). We discussed increasing this percentage, given our delegation’s weight over the votable supply and our active status, making a higher quorum achievable. We are proposing to increase it to 60 % and are currently voting on this here.
On Thursday, 25 th, we held our first Office Hours. Most attendees were ACC members, so we used this time to discuss concerns about the Upgrade of the Governor Contract. You can find the details here and the ensuing discussion here.
The voting in our Snapshot Space will likely lead to changes in the upcoming weeks, possibly affecting our weekly Office Hours, voting frequency, and quorum. Keep up with the voting in real time here 2 .
See you next Voting Cycle! :sparkles:
Updates - Voting Cycle # 17
During our inaugural cycle, we published our Internal Operating Proced…
Updates - Voting Cycle # 17
During our inaugural cycle, we published our Internal Operating Procedures (IOP) and established public communication channels, including email and a Discord channel, with @vonnie 610 & @lavande support. Additionally, we tested the Snapshot Space for the ACC, hosted our first synchronous events, and vote from the ACC multisig for the first time:
Upgrade Proposal # 3 : Delta Network Upgrade
Vote: “For” ( 15 votes, unanimity)
Quorum: 15 / 7
Proposal to Reclassify Grant Misusage Enforcement
Vote: “For” ( 15 votes, unanimity)
Quorum: 15 / 7
Summary of Code of Conduct enforcement decisions
Vote: No votes
Quorum: 0 / 7
There have been multiple discussions regarding our role as the Anticapture Commission. We decided to address these topics in our first Internal Meeting, which is available for viewing here. Our initial focus was on the influence of 10 M OP in our governance and whether we should vote on all matters or limit our involvement, as our IOP does not specify this. We are currently discussing the process and the voting will start in the coming days and plan to amend the IOP during the Review Period of Voting Cycle # 18 . Once the draft is prepared, it will be submitted as a proposal in our Snapshot Space. For this cycle, we decided to vote on all proposals due to the lack of a pre-established policy.
Another significant discussion revolved around the frequency of Office Hours. Some members suggested having one Office Hours per cycle for efficiency, considering that alerts may not be frequent. Others viewed it as an opportunity for individual delegates to engage with high context delegates about governance, not just capture, which would slightly alter the objective of the Office Hours. We are currently voting on this here.
The third key discussion concerned the quorum for our Snapshot Space. Initially, 30 % was proposed before confirming the final number of members (currently 21 ). We discussed increasing this percentage, given our delegation’s weight over the votable supply and our active status, making a higher quorum achievable. We are proposing to increase it to 60 % and are currently voting on this here.
On Thursday, 25 th, we held our first Office Hours. Most attendees were ACC members, so we used this time to discuss concerns about the Upgrade of the Governor Contract. You can find the details here and the ensuing discussion here.
The voting in our Snapshot Space will likely lead to changes in the upcoming weeks, possibly affecting our weekly Office Hours, voting frequency, and quorum. Keep up with the voting in real time here.
See you next Voting Cycle! :sparkles:
Updates - Voting Cycle # 17 During our inaugural cycle, we published our Internal Operating Proced…
Updates - Voting Cycle # 17 During our inaugural cycle, we published our Internal Operating Procedures (IOP) 3 and established public communication channels, including email and a Discord channel, with @vonnie 610 & @lavande support. Additionally, we tested the Snapshot Space for the ACC, hosted our first synchronous events, and vote from the ACC multisig for the first time: Upgrade Proposal # 3 : Delta Network Upgrade 1 Vote: “For” ( 15 votes, unanimity) Quorum: 15 / 7 Proposal to Reclassify Grant Misusage Enforcement Vote: “For” ( 15 votes, unanimity) Quorum: 15 / 7 Summary of Code of Conduct enforcement decisions Vote: No votes Quorum: 0 / 7 There have been multiple discussions regarding our role as the Anticapture Commission. We decided to address these topics in our first Internal Meeting, which is available for viewing here. Our initial focus was on the influence of 10 M OP in our governance and whether we should vote on all matters or limit our involvement, as our IOP does not specify this. We are currently discussing the process and the voting will start in the coming days and plan to amend the IOP during the Review Period of Voting Cycle # 18 . Once the draft is prepared, it will be submitted as a proposal in our Snapshot Space 1 . For this cycle, we decided to vote on all proposals due to the lack of a pre-established policy. Another significant discussion revolved around the frequency of Office Hours. Some members suggested having one Office Hours per cycle for efficiency, considering that alerts may not be frequent. Others viewed it as an opportunity for individual delegates to engage with high context delegates about governance, not just capture, which would slightly alter the objective of the Office Hours. We are currently voting on this here. The third key discussion concerned the quorum for our Snapshot Space. Initially, 30 % was proposed before confirming the final number of members (currently 21 ). We discussed increasing this percentage, given our delegation’s weight over the votable supply and our active status, making a higher quorum achievable. We are proposing to increase it to 60 % and are currently voting on this here. On Thursday, 25 th, we held our first Office Hours. Most attendees were ACC members, so we used this time to discuss concerns about the Upgrade of the Governor Contract. You can find the details here and the ensuing discussion here. The voting in our Snapshot Space will likely lead to changes in the upcoming weeks, possibly affecting our weekly Office Hours, voting frequency, and quorum. Keep up with the voting in real time here 1 . See you next Voting Cycle! :sparkles:
Updates - Voting Cycle # 18
In our latest cycle, the Anticapture Commission (ACC) continued to ref…
Updates - Voting Cycle # 18
In our latest cycle, the Anticapture Commission (ACC) continued to refine its processes. Changes are visible in the updated ACC’s Internal Operational Procedures:
Frequency of Voting from the ACC Multisig
Process to step down from the ACC
Anticapture Commission Snapshot Quorum
ACC Office Hours Frequency 1
As we’ve agreed to vote only on proposals that possess veto rights (currently limited to protocol upgrades) and in special situations as outlined in our IOP, the only vote we cast on Agora was this one:
Protocol Upgrade # 4
Vote: “For” ( 15 votes, unanimity)
Quorum: 15 / 13 1
The ACC’s second internal meeting highlighted the challenges of decentralization while balancing efficiency. A significant portion of the conversation centered around the desire for the OP token to control the governance contract and to have a decentralization roadmap around governance structures. Additionally, there was palpable frustration regarding the necessity of double transactions for voting in recent cycles.
Despite an understandable impatience for swift changes, there was agreement on the importance of patience and comprehending the ongoing process. It was recognized that the journey towards decentralization and refining governance is inherently gradual, demanding both time and meticulous thought for successful execution.
Catch the full discussion here: https://youtu.be/_BPKVZM 4 Zfg 1
Updates - Voting Cycle # 18
In our latest cycle, the Anticapture Commission (ACC) continued to ref…
Updates - Voting Cycle # 18
In our latest cycle, the Anticapture Commission (ACC) continued to refine its processes. Changes are visible in the updated ACC’s Internal Operational Procedures:
Frequency of Voting from the ACC Multisig
Process to step down from the ACC
Anticapture Commission Snapshot Quorum
ACC Office Hours Frequency
As we’ve agreed to vote only on proposals that possess veto rights (currently limited to protocol upgrades) and in special situations as outlined in our IOP, the only vote we cast on Agora was this one:
Protocol Upgrade # 4
Vote: “For” ( 15 votes, unanimity)
Quorum: 15 / 13
The ACC’s second internal meeting highlighted the challenges of decentralization while balancing efficiency. A significant portion of the conversation centered around the desire for the OP token to control the governance contract and to have a decentralization roadmap around governance structures. Additionally, there was palpable frustration regarding the necessity of double transactions for voting in recent cycles.
Despite an understandable impatience for swift changes, there was agreement on the importance of patience and comprehending the ongoing process. It was recognized that the journey towards decentralization and refining governance is inherently gradual, demanding both time and meticulous thought for successful execution.
Catch the full discussion here: https://youtu.be/_BPKVZM 4 Zfg
Updates - Voting Cycle # 18 In our latest cycle, the Anticapture Commission (ACC) continued to ref…
Updates - Voting Cycle # 18 In our latest cycle, the Anticapture Commission (ACC) continued to refine its processes. Changes are visible in the updated ACC’s Internal Operational Procedures: Frequency of Voting from the ACC Multisig Process to step down from the ACC Anticapture Commission Snapshot Quorum ACC Office Hours Frequency As we’ve agreed to vote only on proposals that possess veto rights (currently limited to protocol upgrades) and in special situations as outlined in our IOP, the only vote we cast on Agora was this one: Protocol Upgrade # 4 Vote: “For” ( 15 votes, unanimity) Quorum: 15 / 13 The ACC’s second internal meeting highlighted the challenges of decentralization while balancing efficiency. A significant portion of the conversation centered around the desire for the OP token to control the governance contract and to have a decentralization roadmap around governance structures. Additionally, there was palpable frustration regarding the necessity of double transactions for voting in recent cycles. Despite an understandable impatience for swift changes, there was agreement on the importance of patience and comprehending the ongoing process. It was recognized that the journey towards decentralization and refining governance is inherently gradual, demanding both time and meticulous thought for successful execution. Catch the full discussion here: https://youtu.be/_BPKVZM 4 Zfg 1
Updates - Voting Cycle # 19
During past cycles, the Anticapture Commission engaged in discussions …
Updates - Voting Cycle # 19
During past cycles, the Anticapture Commission engaged in discussions about security. In voting cycles # 17 and # 18 , the Anticapture Lead manually casts votes on Agora, given the current setup of the multisig is 1 / 2 (with the Lead & the FND gov Safe). We presented multiple options to prevent a scenario in which the Lead executes a vote not aligned with the public results of the Snapshot:
Implementing a member multisig and altering the setup to include this multisig. After finalizing the proposal on Snapshot, the ACC will submit the vote as a transaction through the member multisig. Concerns include:
Potential delays in obtaining signatures within the one-week voting period (for Snapshot proposal finalization and multisig transaction submission).
The operational overhead for the Foundation and commission members in managing direct voting via multisig.
Discontinuing the use of Snapshot and directly voting on Safe with the multisig member. Each member can accept or reject the transaction.
The main concern is the diffusion of responsibility when using only the multisig to vote, as opposed to platforms like Snapshot, Tally, or Jokerace, which provide transparent records.
Utilizing Snapshot for off-chain decisions, such as defining the frequency of ACC calls, and using multisig for on-chain decisions.
Exploring tools like UMA’s oSnap or Hats Protocol + Safe for enhanced voting mechanisms.
Converting the current multisig to a 2 of 3 arrangement with FND, the ACC Lead, and another multisig address comprising all ACC members as signers, with a 9 / 21 threshold. It would be structured as follows:
Multisig # 1 (current Multisig) 2 / 3 :
OP FND
ACC Lead
ACC members multisig
Multisig # 2 (ACC members Multisig) 9 / 21 :
All ACC members
OP FND (for maintenance)
Continuing as is, placing trust in the Lead not to vote against the ACC’s consensus.
In this voting cycle, we tested UMA’s oSnap. However, it proved confusing, requiring two transactions per Agora proposal—one to vote “For” and one to vote “Against”—and only executing upon reaching quorum. We did not achieve quorum for voting cycle # 19 , acknowledging this as our oversight. Feedback has been provided to UMA’s team regarding our use case.
Discussions continue on finding the right balance between speed, ease, and security.
Currently, the Lead, with the Foundation’s support, is recalculating the ACC membership as outlined in the Lead’s responsibilities:
Anticapture Commission
Calculate qualifying delegates at the mid-point of the Season and before the start of the next Season, including assessment of whether Members have upheld the Member Responsibities
You can watch the recording of our last internal meeting here.
For Voting Cycle # 20 , Gene will replace Teresa as representative of the Code of Conduct Council in the Anticapture Commission.
Updates - Voting Cycle # 19 During past cycles, the Anticapture Commission engaged in discussions …
Updates - Voting Cycle # 19 During past cycles, the Anticapture Commission engaged in discussions about security. In voting cycles # 17 and # 18 , the Anticapture Lead manually casts votes on Agora, given the current setup of the multisig is 1 / 2 (with the Lead & the FND gov Safe). We presented multiple options to prevent a scenario in which the Lead executes a vote not aligned with the public results of the Snapshot: Implementing a member multisig and altering the setup to include this multisig. After finalizing the proposal on Snapshot, the ACC will submit the vote as a transaction through the member multisig. Concerns include: Potential delays in obtaining signatures within the one-week voting period (for Snapshot proposal finalization and multisig transaction submission). The operational overhead for the Foundation and commission members in managing direct voting via multisig. Discontinuing the use of Snapshot and directly voting on Safe with the multisig member. Each member can accept or reject the transaction. The main concern is the diffusion of responsibility when using only the multisig to vote, as opposed to platforms like Snapshot, Tally, or Jokerace, which provide transparent records. Utilizing Snapshot for off-chain decisions, such as defining the frequency of ACC calls, and using multisig for on-chain decisions. Exploring tools like UMA’s oSnap or Hats Protocol + Safe for enhanced voting mechanisms. Converting the current multisig to a 2 of 3 arrangement with FND, the ACC Lead, and another multisig address comprising all ACC members as signers, with a 9 / 21 threshold. It would be structured as follows: Multisig # 1 (current Multisig) 2 / 3 : OP FND ACC Lead ACC members multisig Multisig # 2 (ACC members Multisig) 9 / 21 : All ACC members OP FND (for maintenance) Continuing as is, placing trust in the Lead not to vote against the ACC’s consensus. In this voting cycle, we tested UMA’s oSnap. However, it proved confusing, requiring two transactions per Agora proposal—one to vote “For” and one to vote “Against”—and only executing upon reaching quorum. We did not achieve quorum for voting cycle # 19 , acknowledging this as our oversight. Feedback has been provided to UMA’s team regarding our use case. Discussions continue on finding the right balance between speed, ease, and security. Currently, the Lead, with the Foundation’s support, is recalculating the ACC membership as outlined in the Lead’s responsibilities: Anticapture Commission Calculate qualifying delegates at the mid-point of the Season and before the start of the next Season, including assessment of whether Members have upheld the Member Responsibities You can watch the recording of our last internal meeting here. For Voting Cycle # 20 , Gene will replace Teresa as representative of the Code of Conduct Council in the Anticapture Commission.
Updates - Voting Cycle # 20
The Anticapture Commission membership has been re-calculated and re-ev…
Updates - Voting Cycle # 20
The Anticapture Commission membership has been re-calculated and re-evaluated at the mid-point of Season 5 . You can read more about it here.
We warmly welcome the new members:
@itublockchain
@Griff
@she 256
For Voting Cycle # 20 , @gene will replace @teresacd as representative of the Code of Conduct Council.
The list of members is as follows:
Brichis (Anticapture Commission Lead)
Gonna.eth (Grants Council Lead)
Gene (Code of Conduct Council Representative) [New]
Blockchain @ USC
Butterbum
Ceresstation
GFX Labs
Griff Green [New]
ITU Blockchain [New]
Joxes (SEED Latam)
Katie Garcia
Lefteris
L 2 BEATs
Michael Vander Meiden
MinimalGravitas
MoneyManDoug
OPUser
PGov
She 256 [New]
StableLab
web 3 magnetic
404 DAO
Their addresses will be added to the whitelist on Snapshot as soon as they complete the KYC process required to become a member of the Anticapture Commission. With 22 members, the quorum for our Snapshot Space will be of 14 members.
No votes were required during Voting Cycle # 20 ; consequently, our Office Hours resembled a water cooler talk. During our Internal Meeting, we welcomed new members and discussed changes following the membership recalculations. The discussion also revolved around the voting method to be used for the next Voting Period. Catch the discussions here.
Thanks to all members for their engagement with the Commission, as well as to @op_julian and @lavande, for their significant help with the membership re-calculation. :pray:
Updates - Voting Cycle # 21
In Voting Cycle # 21 , we experimented with a different voting method …
Updates - Voting Cycle # 21
In Voting Cycle # 21 , we experimented with a different voting method to find a balance between speed, security, and ease. This cycle saw new signers added to the SAFE multisig, which now includes 22 signers:
21 ACC members (waiting for one KYC approval to complete the group)
1 from the Foundation.
It requires 13 out of 22 confirmations to execute a transaction (to vote on a proposal).
This cycle, we voted “for” the proposal “Governor Upgrade # 1 : Improve Advanced Delegation Voting”. The process went smoothly, even considering we encountered an issue when the link to the original proposal changed, requiring us to create another transaction. Special thanks to @vonnie 610 and @Gonna.eth for their guidance in finding a solution.
Transaction details
The Lead recommended a few modifications to member responsibilities in the IOP; however, as the Charter takes priority over the IOP, these will be considered as feedback for future seasons.
We are currently working on enhancing our Delegate Statement as some individuals have started delegating to that address. We aim to clarify expectations regarding voting turnout from this multisig.
For Voting Cycle # 22 , we expect some changes in signers, including:
Adding She 256 (KYC pending)
Removing Lefteris as he has decided to step down
Replacing the multisig from Blockchain@USC (Ethereum to Optimism)
Catch the full conversation by watching the recording here.
Updates - Voting Cycle # 21
In Voting Cycle # 21 , we experimented with a different voting method …
Updates - Voting Cycle # 21
In Voting Cycle # 21 , we experimented with a different voting method to find a balance between speed, security, and ease. This cycle saw new signers added to the SAFE multisig, which now includes 22 signers:
21 ACC members (waiting for one KYC approval to complete the group)
1 from the Foundation.
It requires 13 out of 22 confirmations to execute a transaction (to vote on a proposal).
This cycle, we voted “for” the proposal “Governor Upgrade # 1 : Improve Advanced Delegation Voting”. The process went smoothly, even considering we encountered an issue when the link to the original proposal changed, requiring us to create another transaction. Special thanks to @vonnie 610 and @Gonna.eth for their guidance in finding a solution.
Transaction details
The Lead recommended a few modifications to member responsibilities 1 in the IOP; however, as the Charter takes priority over the IOP, these will be considered as feedback for future seasons.
We are currently working on enhancing our Delegate Statement as some individuals have started delegating to that address. We aim to clarify expectations regarding voting turnout from this multisig.
For Voting Cycle # 22 , we expect some changes in signers, including:
Adding She 256 (KYC pending)
Removing Lefteris as he has decided to step down
Replacing the multisig from Blockchain@USC (Ethereum to Optimism)
Catch the full conversation by watching the recording here.
Updates - Voting Cycle # 22
In Voting Cycle # 22 , no votes were cast. However, a few transactions…
Updates - Voting Cycle # 22
In Voting Cycle # 22 , no votes were cast. However, a few transactions were necessary to modify the members within our multisig and update our delegate statement. Regarding the modification in the multisig, She 256 , originally slated for addition, failed to complete KYC on time. This sparked discussions during the internal meeting about whether KYC should be a requirement for ACC membership. Additionally, we removed Lefteris from the multisig, who decided to step down during Cycle 20 , thus adjusting the threshold to 12 signatures. We also updated the address for Blockchain@USC due to their different address for Optimism and Ethereum Mainnet.
Looking ahead, we will schedule these calls for the two Special Voting Cycles expected during the reflection period:
Special Voting Cycle # 23 a (May 23 – 29 , 2024 )
Office Hours: May 23 rd 16 : 00 - 16 : 30 UTC
Internal Meeting: May 28 th 16 : 00 - 16 : 30 UTC
Special Voting Cycle # 23 b (June 13 – 19 , 2024 )
Office Hours: June 13 th 16 : 00 - 16 : 30 UTC
Internal Meeting: June 18 th 16 : 00 - 16 : 30 UTC
Both cycles will feature shorter, 30 -minute calls to maintain efficiency. During our recent internal call, we also considered the distribution strategy for Retro Funding 6 , given its planned to happen in the middle of Season 6 . Reflections on Season 5 have been finalized and can be viewed here. 1
Catch the full conversation and updates in the recording here.
Updates - Voting Cycle # 22
In Voting Cycle # 22 , no votes were cast. However, a few transactions…
Updates - Voting Cycle # 22
In Voting Cycle # 22 , no votes were cast. However, a few transactions were necessary to modify the members within our multisig and update our delegate statement. Regarding the modification in the multisig, She 256 , originally slated for addition, failed to complete KYC on time. This sparked discussions during the internal meeting about whether KYC should be a requirement for ACC membership. Additionally, we removed Lefteris from the multisig, who decided to step down during Cycle 20 , thus adjusting the threshold to 12 signatures. We also updated the address for Blockchain@USC due to their different address for Optimism and Ethereum Mainnet.
Looking ahead, we will schedule these calls for the two Special Voting Cycles expected during the reflection period:
Special Voting Cycle # 23 a (May 23 – 29 , 2024 )
Office Hours: May 23 rd 16 : 00 - 16 : 30 UTC
Internal Meeting: May 28 th 16 : 00 - 16 : 30 UTC
Special Voting Cycle # 23 b (June 13 – 19 , 2024 )
Office Hours: June 13 th 16 : 00 - 16 : 30 UTC
Internal Meeting: June 18 th 16 : 00 - 16 : 30 UTC
Both cycles will feature shorter, 30 -minute calls to maintain efficiency. During our recent internal call, we also considered the distribution strategy for Retro Funding 6 , given its planned to happen in the middle of Season 6 . Reflections on Season 5 have been finalized and can be viewed here.
Catch the full conversation and updates in the recording here.
Updates - Special Voting Cycle # 23 a
During Special Voting Cycle 23 a, we voted “for” the followi…
Updates - Special Voting Cycle # 23 a
During Special Voting Cycle 23 a, we voted “for” the following proposals:
Protocol Upgrade # 7 : Fault Proofs
Protocol Upgrade # 8 : Changes for Stage 1 Decentralization
Governor Update Proposal # 2 : Improvements to advanced delegation allowance calculations
Discussion Highlights:
There was a notable discussion about voting “for” Protocol Upgrade # 7 after comments from Zach Obront, Lead of the Developer Advisory Board (DAB), regarding the Fault Dispute Game not being included in the audit for Fault Proofs (expected by July). Despite these concerns, there was no strong sentiment against voting for it due to the existence of the Guardian role. Thanks @Joxes for bringing this topic to the table.
The conversation extended to what would happen if we wanted to vote against or abstain. Currently, using Safe, we create a “for” vote transaction for each proposal in Agora, but there’s no transaction for voting against. We discussed the idea of having both “for” and “against” in each nonce, but this could cause confusion, as seen when we tried using Snapshot with oSnap. We haven’t concluded on the best approach, and discussions continue as we strive to find the least imperfect way to vote.
There was a duplication when creating the batch of transactions for this season. Thanks to @kaereste for verifying and noticing the duplicate transactions. We created three transactions, one for each proposal. Special thanks to @Luckyhooman.eth for collaborating to ensure the process was error-free.
Unfortunately, there is no recording of the call due to a technical failure with Google Meet. Apologies for the inconvenience. However, the agenda for the day can be found here.
Additional Discussions:
The possibility of adding a new position on the Commission for the next season was raised, and the role for this new position is almost ready.
We briefly discussed applying for Retro Funding 6 to cover contributions not considered in Retro Rewards for Governance Participants, such as attending Office Hours, internal calls, and participating in votes for changes in the IOP.
These additional discussions will continue as we move forward.
Our next ACC Office Hours is on June 13 at 16 : 00 GMT. See you next Special Voting Cycle!
Updates - Special Voting Cycle # 23 b
During Special Voting Cycle 23 b, we voted “for” on “Upgrade…
Updates - Special Voting Cycle # 23 b
During Special Voting Cycle 23 b, we voted “for” on “Upgrade Proposal # 9 : Fjord Network Upgrade.” 1
Our Internal Meeting was brief, and you can watch it here 1 .
The Lead from Season 5 shared some recommendations for the lead for Season 6 and encouraged members to apply, offering assistance with the onboarding process.
Recommendations mentioned:
Migration of Snapshot from Mainnet to Optimism
IOP expected updates:
Extending voting windows/forms of notification for votes taking place
Member & Lead responsibilities
Application to Retro Funding 6 :
How it could be structured with a points-based distribution for contributions not considered in Retro Rewards for Season 5 , such as attendance at Office Hours and internal meetings, plus votes that were not considered, such as votes on modifications to the IOP and votes occurring during the reflection period.
This is illustrative only and can be modified at any time after receiving member feedback or a proposal from the new lead.
You can check it here 2 with the member records from all season.
Add a new role for Season 6 : Ops (with Retro Funding incentives)
Thank you to all members who participated in this experiment during Season 5 . This is the last update from Season 5 .
Updates - Special Voting Cycle # 23 b
During Special Voting Cycle 23 b, we voted “for” on “Upgrade…
Updates - Special Voting Cycle # 23 b
During Special Voting Cycle 23 b, we voted “for” on “Upgrade Proposal # 9 : Fjord Network Upgrade.”
Our Internal Meeting was brief, and you can watch it here.
The Lead from Season 5 shared some recommendations for the lead for Season 6 and encouraged members to apply, offering assistance with the onboarding process.
Recommendations mentioned:
Migration of Snapshot from Mainnet to Optimism
IOP expected updates:
Extending voting windows/forms of notification for votes taking place
Member & Lead responsibilities
Application to Retro Funding 6 :
How it could be structured with a points-based distribution for contributions not considered in Retro Rewards for Season 5 , such as attendance at Office Hours and internal meetings, plus votes that were not considered, such as votes on modifications to the IOP and votes occurring during the reflection period.
This is illustrative only and can be modified at any time after receiving member feedback or a proposal from the new lead.
You can check it here with the member records from all season.
Add a new role for Season 6 : Ops (with Retro Funding incentives)
Thank you to all members who participated in this experiment during Season 5 . This is the last update from Season 5 .
During Voting Cycle # 24 , there were no proposals on which the Anticapture Commission had to exerc…
During Voting Cycle # 24 , there were no proposals on which the Anticapture Commission had to exercise its vote.
Updates - Voting Cycle # 25
During Voting Cycle # 25 , there were no proposals on which the Antica…
Updates - Voting Cycle # 25
During Voting Cycle # 25 , there were no proposals on which the Anticapture Commission had to exercise its vote.
For Season 6 of Optimism Governance, the Anticapture Commission membership has been reconstituted in accordance with its Charter, and we warmly welcome the following Delegate members who have joined the Commission:
@MattL
@Tane
@stevegachau.eth
@chom
@olimpio
@Gauntlet
@v 3 naru_Curia
The full list of Members of the ACC is as follows:
Delegate name
@katie
@Brichis
@web 3 magnetic
MinimalGravitas
OPUser
seedlatam
MattL
PGov
blockchainatusc
404 DAO
Michael
Tane
stevegachau.eth
GFXlabs
Butterbum
kaereste (L 2 Beat)
she 256
chom
olimpio
Moneymandoug
StableLab
Griff
Gauntlet
v 3 naru_Curia (Curia Labs)
@Web 3 magnetic has been elected as the ACC Lead for the Season.
The Season 6 IOP for the Commission has been published:
Anticapture Commission S 6 - Internal Operating Procedures (IOP) Internal Operating Procedures
ACC Season 6 : Internal Operating Procedures
1 . Introduction
This document outlines the Internal Operating Procedures (IOP) for the Anticapture Commission for Season 6 of Optimism Governance. It is designed to ensure alignment with the objective of the Anticapture Commission, with active participation of high context delegates, transparency, minimized governance, and clear accountability in line with the Commission’s goals and the Foundation’s guidelines.
2 . Transparent Communications
2 . 1 Conta…
The Snapshot Spaces and Multisig of the ACC will be configured with the changes to ACC for the Season.
MultiSig Tx 14 :
Remove:
Delegate
Associated Address
ceresstation.eth
0 x 48 a 63097 e 1 ac 123 b 1 f 5 a 8 bbffafa 4 afa 8192 fab 0
Gonna.eth
0 xdcf 7 be 2 ff 93 e 1 a 7671724598 b 1526 f 3 a 33 b 1 ec 25
Gene Davis
0 x 4318 cc 449 b 1 cbe 6 d 64 dd 82 e 16 abe 58 c 79 e 076 c 2 b
itublockchain.eth
0 xbec 643 bd 5 b 7 f 5 e 9190617 ca 4187 ef 0455950 c 51 c
Add:
Delegate
Associated Address
Matt
0 x 1 f 4 ba 000 d 042 ca 0045 ef 094691615 f 3912 debea 8
Tané
0 xb 79294 d 00848 a 3 a 4 c 00 c 22 d 9367 f 19 b 4280689 d 7
stevegachau.eth
0 x 1208 a 26 faa 0 f 4 ac 65 b 42098419 eb 4 daa 5 e 580 ac 6
she 256
0 xed 11 e 5 ea 95 a 5 a 3440 fbaadc 4 cc 404 c 56 d 0 a 5 bb 04
Chomtana
0 x 5 f 4 bcccb 5 c 2 cbb 01 c 619 f 5 cfed 555466 e 31679 b 6
olimpio
0 xf 4 b 0556 b 9 b 6 f 53 e 00 a 1 fdd 2 b 0478 ce 841991 d 8 fa
Gauntlet
0 x 11 cf 2 f 033 b 079 fbb 195425 bfcb 7 d 5 dac 4 db 2 d 752
curia-delegates.eth
0 x 17296956 b 4 e 07 ff 8931 e 4 ff 4 ea 06709 fab 70 b 879
Updates - Voting Cycle # 26
During Voting Cycle # 26 , the Commission was required to vote on the …
Updates - Voting Cycle # 26
During Voting Cycle # 26 , the Commission was required to vote on the Granite Upgrade Proposal.
An internal meeting was held on 22 nd Aug 2024 where the Granite Network Upgrade proposal was discussed, and it was agreed among member delegates that the Commission will vote on the Granite Network Upgrade.
However, delegates expressed major reservations in the way this upgrade had been proposed.
After approval by the Delegates and reaching the required quorum, on 27 th August 2024 the ACC Multisig Voted YES on the Granite Network Upgrade. The transaction can be found here: ACC Multisig TX # 15
Along with voting on the Governance Upgrade proposal, in the Internal Meeting the ACC Members also considered the Agora voting UI/UX issue from last voting cycle. A call was held with Agora team members, and Agora team had shared a demo of the new features they were rolling out to prevent voting errors from occurring again. It was decided that the Delegates would try the new upgrades to Agora, and share their feedback and if any future errors remain, the Delegates and ACC would discuss and propose specifications of changes to be required in the Agora voting module.
ACC:
However, delegates expressed major reservations in the way this upgrade had been proposed…
ACC:
However, delegates expressed major reservations in the way this upgrade had been proposed.
Can you provide more details (or are the specifics of this conversation documented somewhere that we could reference?) so future upgrades can take these concerns into consideration?
Thank you,
The main concerns was that the way the proposal came about with fallback mechanism activ…
Thank you,
The main concerns was that the way the proposal came about with fallback mechanism activated and almost like an emergency upgrade to disable fraud proofs, this resulted in a situation where the network was potentially very close to a major incident in which the security council would have had to step in if anything bad happened or a malicious actor taking advantage.
Some of the concerns that were raised are documented mainly in the Granite Network Upgrade thread 1 , other delegates had issues with how the full audit was not done, and that the fault proof system was outside the scope of the audit. In the ACC internal meeting the L 2 Beat Delegate representative had shared that such a step was taken in a casual manner, and L 2 Beat have also documented their concerns :
x.com
L 2 BEAT ? 2
@l 2 beat
On August 16 , OP Mainnet effectively disabled the fault proof system as part of a bug fix. The project has been set to Under Review as we further assess the situation. Given the unprecedented nature of this procedure, here are a few important comments and considerations ?
2 : 43 PM - 19 Aug 2024
380
55
Thank you,
The main concerns was that the way the proposal came about with fallback mechanism activ…
Thank you,
The main concerns was that the way the proposal came about with fallback mechanism activated and almost like an emergency upgrade to disable fraud proofs, this resulted in a situation where the network was potentially very close to a major incident in which the security council would have had to step in if anything bad happened or a malicious actor taking advantage.
Some of the concerns that were raised are documented mainly in the Granite Network Upgrade thread, other delegates had issues with how the full audit was not done, and that the fault proof system was outside the scope of the audit. In the ACC internal meeting the L 2 Beat Delegate representative had shared that such a step was taken in a casual manner, and L 2 Beat have also documented their concerns :
x.com
L 2 BEAT ?
@l 2 beat
On August 16 , OP Mainnet effectively disabled the fault proof system as part of a bug fix. The project has been set to Under Review as we further assess the situation. Given the unprecedented nature of this procedure, here are a few important comments and considerations ?
2 : 43 PM - 19 Aug 2024
380
55
In Voting Cycle # 27 and # 28 , the ACC did not vote on any proposals, as there were no upgrade pr…
In Voting Cycle # 27 and # 28 , the ACC did not vote on any proposals, as there were no upgrade proposals that were being voted on during these voting cycles.
The ACC discussed the Accelerated Decentralization Proposal For Optimism with its Delegate Members, GFX Labs representative and Foundation, and decided that at this stage, the ACC would not vote directly on the proposal. The ACC’s statement on this proposal can be found here.
Accelerated Decentralization Proposal For Optimism
ACC’s Statement on the Proposal for Accelerated Decentralization for Optimism
On 26 th September 2024 , the Anticapture Commission (ACC) held an Internal Meeting where one of the key agenda items was the discussion on the Petition for Accelerated Decentralization for Optimism. Along with the Delegate members of the ACC, we also invited GFX Lab’s PaperImperium and members of the Foundation to discuss the petition.
There was wide agreement among all parties that the proposal represented a step in …
ACC Updates for Voting Cycle # 29
In voting cycle # 29 , the ACC voted “For” on the Governor Updat…
ACC Updates for Voting Cycle # 29
In voting cycle # 29 , the ACC voted “For” on the Governor Update Proposal # 3 : Enable Onchain Treasury Execution.
The proposal was internally discussed among members of the ACC, and the rationale for ACC’s vote is as below:
The Proposal aims to further decentralize execution of token transfer proposals, which are currently manually executed by the Foundation. After execution of this proposal, token transfer proposals can be voted and executed fully onchain without relying on Foundation.
The proposed changes have completed audit and the audit report indicates that the identified issues have been addressed.
The upgrade, when completed, will not result in a situation where any single entity captures or has a significant control over governance.
Thus, after discussion the proposal, the onchain vote was initiated from the ACC Multisig. After achieving the required quorum among ACC members, the vote transaction was executed from the ACC multisig.
