Anticapture Commission Communication Thread

Elected Representatives đź’Ľ Council Communication Threads
,
1

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
  • L2BEATs
  • Michael Vander Meiden
  • MinimalGravitas
  • MoneyManDoug
  • OPUser
  • PGov
  • She256
  • StableLab
  • web3magnetic
  • 404 DAO

Internal Operating Procedures

On January 17th, the Anticapture Commission received a delegation of 10M OP from the Governance Fund for Season 5 and 6 contained in this multisig.

5 Likes
4

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 @vonnie610 & @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 10M 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, 25th, 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:

4 Likes
5

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:

  1. Frequency of Voting from the ACC Multisig

  2. Process to step down from the ACC

  3. Anticapture Commission Snapshot Quorum

  4. 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/_BPKVZM4Zfg

3 Likes
6

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:

  1. 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.
  1. 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.

  1. Utilizing Snapshot for off-chain decisions, such as defining the frequency of ACC calls, and using multisig for on-chain decisions.

  2. Exploring tools like UMA’s oSnap or Hats Protocol + Safe for enhanced voting mechanisms.

  3. 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)
  1. 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:

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.

3 Likes
7

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:

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
  • L2BEATs
  • Michael Vander Meiden
  • MinimalGravitas
  • MoneyManDoug
  • OPUser
  • PGov
  • She256 [New]
  • StableLab
  • web3magnetic
  • 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:

5 Likes
8

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 @vonnie610 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 She256 (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.

1 Like
9

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, She256, 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 #23a (May 23 – 29, 2024)
    Office Hours: May 23rd 16:00-16:30 UTC
    Internal Meeting: May 28th 16:00-16:30 UTC

  • Special Voting Cycle #23b (June 13 – 19, 2024)
    Office Hours: June 13th 16:00-16:30 UTC
    Internal Meeting: June 18th 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.

2 Likes
12

Updates - Special Voting Cycle #23a

During Special Voting Cycle 23a, 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!

2 Likes
13

Updates - Special Voting Cycle #23b

During Special Voting Cycle 23b, 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:

  1. Migration of Snapshot from Mainnet to Optimism

  2. IOP expected updates:

  • Extending voting windows/forms of notification for votes taking place
  • Member & Lead responsibilities
  1. 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.
  1. 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.

2 Likes
15

During Voting Cycle #24, there were no proposals on which the Anticapture Commission had to exercise its vote.

1 Like
16

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:

The full list of Members of the ACC is as follows:

Delegate name
@katie
@Brichis
@web3magnetic
MinimalGravitas
OPUser
seedlatam
MattL
PGov
blockchainatusc
404DAO
Michael
Tane
stevegachau.eth
GFXlabs
Butterbum
kaereste (L2 Beat)
she256
chom
olimpio
Moneymandoug
StableLab
Griff
Gauntlet
v3naru_Curia (Curia Labs)

@Web3magnetic has been elected as the ACC Lead for the Season.

The Season 6 IOP for the Commission has been published:

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 0x48a63097e1ac123b1f5a8bbffafa4afa8192fab0
Gonna.eth 0xdcf7be2ff93e1a7671724598b1526f3a33b1ec25
Gene Davis 0x4318cc449b1cbe6d64dd82e16abe58c79e076c2b
itublockchain.eth 0xbec643bd5b7f5e9190617ca4187ef0455950c51c

Add:

Delegate Associated Address
Matt 0x1f4ba000d042ca0045ef094691615f3912debea8
Tané 0xb79294d00848a3a4c00c22d9367f19b4280689d7
stevegachau.eth 0x1208a26faa0f4ac65b42098419eb4daa5e580ac6
she256 0xed11e5ea95a5a3440fbaadc4cc404c56d0a5bb04
Chomtana 0x5f4bcccb5c2cbb01c619f5cfed555466e31679b6
olimpio 0xf4b0556b9b6f53e00a1fdd2b0478ce841991d8fa
Gauntlet 0x11cf2f033b079fbb195425bfcb7d5dac4db2d752
curia-delegates.eth 0x17296956b4e07ff8931e4ff4ea06709fab70b879
5 Likes
17

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 22nd 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 27th 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.

2 Likes
18

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?

2 Likes
20

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 L2Beat Delegate representative had shared that such a step was taken in a casual manner, and L2Beat have also documented their concerns :