RFC: Update SnapShot space and delegate authority to admins to update in the future

Gm fox fam! Curious to hear your thoughts on this draft prop before moving it to ideation. There are a few different SnapShot updates that could be batched into a single proposal, but if any of the proposed updates are contentious, happy to remove them so they can be considered on their own.

Summary

This proposal seeks approval from the community to make the following updates to the shapeshiftdao.eth SnapShot space:

  1. Ratify the recent increase of FOX voting power required to publish a proposal to 50,000 200,000 FOX
  2. Replace ShapeShift’s current SnapShot admins, who were appointed prior to the DAO launch, with the moderation workstream leader and treasury signers
  3. Officially delegate authority to the SnapShot admins to be able to modify certain settings in ShapeShift’s SnapShot space without requiring an additional proposal
  4. Create a new SnapShot sub-space for the Ideation stage of the governance process
  5. Set the voting period to 5 days for the main SnapShot space and to 7 days for the Ideation space

Abstract

Currently ShapeShift’s governance process depends heavily on SnapShot. Prior to the DAO’s launch, 4 foxes were appointed as SnapShot admins to get the ball rolling with the understanding that the community could make a proposal to replace or remove these admins in the future. Since then, a moderation workstream has been established, a process for electing treasury signers has been implemented, and several malicious proposals have been published with the intent of phishing FOX voters. In light of these developments, this proposal seeks to ratify the following changes to the shapeshiftdao.eth SnapShot:

  1. Ratify the recent increase of FOX voting power required to publish a proposal to 50,000 200,000 FOX

Context: Initially only 100 FOX voting power was required to publish a proposal. This worked well for a while, but eventually scammers realized they could buy 100 FOX tokens and publish malicious proposals to the shapeshiftdao.eth SnapShot that promise an airdrop, but in reality aim to drain funds from victims’ wallets. To combat this, SCP-136 1 raised the threshold to 10,000 FOX, which was sufficient for about 8 months until December 20th, 2023 when the vulnerability was exploited again. Each time this exploit has occurred, admins of the shapeshiftdao.eth space have been quick to delete the scam proposals, but the scammers would simply repost repeatedly. This prompted the admins to increase the limit to 20,000, which worked for 10 hours until the exploit occurred again. The admins then increased the minimum to 50,000, which so far appears to be keeping the scammers at bay. Update: more scam proposals were posted on January 24th, 2024. This time, SnapShot admins increased the limit to 60,000, then 100,000 when the attacker acquired more voting power and republished, and finally 200,000 when the attacker acquired even more voting power and republished. This has been enough to deter the attacker for now, but the community may want to consider making a separate proposal for an additional or alternative approach to mitigating these proposals beyond additional voting power increases. Here’s Gnosis’ forum discussion on how to combat this issue for reference.

Specification: Required voting power to publish a proposal has already been increased to 200,000 to prevent the ongoing spam attacks. This simply ratifies this change.

Motivation: Mitigate ongoing attacks and the risk of community members falling victim to scams.

Drawbacks: This unfortunately has the unintended consequence of raising the barrier for community members to publish bonafide proposals. However, several community members have already offered to provide assistance and publish proposals on behalf of those that don’t have the necessary voting power. As mentioned, the community should consider additional or separate requirements to further defend against this exploit going forward.

  1. Replace ShapeShift’s current SnapShot admins with the moderation workstream leader and treasury signers

Context: The current SnapShot admins were appointed prior to the DAO’s launch, and included the original 2 treasury signers as well as 2 other former ShapeShift employees that planned to contribute actively to the DAO. SnapShot admins have the ability to edit Space settings and delete proposals with the exception of admin users and archive proposals. Since then, the DAO has elected new treasury signers as well as approved the formation of a moderation workstream leader. Shapeshiftdao.eth, which is controlled by the DAO’s mainnet treasury, is already set as the controller of the space and has full control, so this update can be executed onchain via oSnap.

Specification:

A transaction will be created to remove the current SnapShot admins and moderator and add the current treasury signers and moderation workstream leader as the new admins.

Moderation worktream leader: Giantkin.eth (0xff75E131c711e4310C045317779d39B3B4f718C4)

Treasury signer #1: 0xF5AA59151bE6515C4Ca68A0282CF68B3eA4846fC

Treasury signer #2: 0x7a89f1838933DE0bA50aF0e916050977ceACAC9e

Treasury signer #3: 0x8984476627010f0f50F1903f63BbdBe1176c5297

Motivation: Align SnapShot admins with current treasury signers and moderation workstream leader, and avoid requiring a future proposal to update admins if these roles change hands.

Drawbacks: This isn’t necessarily a drawback, but important to understand that each SnapShot admin’s account has the power to act beyond the community’s consent and in a worst case scenario, delete past proposals and prevent new proposals from being published and/or voted on by FOX holders. It’s important that admins are individuals that the community trusts to not abuse these powers as well as to secure their keys so they aren’t compromised.

  1. Officially delegate authority to the SnapShot admins to be able to modify certain settings in ShapeShift’s SnapShot space without requiring an additional proposal

Context: The FOX Governance process implies that SnapShot admins have authority to be able to add strategies to SnapShot to grant voting power for FOX as it expands across chains and DeFi protocols, but they do not have authority to remove strategies.

Specification: SnapShot admins will be granted authority to add strategies as long as the strategy grants 1 vote for 1 fox, no more no less, as well as authority to remove strategies that are no longer relevant, such as FOX deposited into Rari pools or the Tokemak FOX reactor, both of which have been sunset. Further, the ShapeShift treasury signers will be granted authority to execute the necessary transactions to add or remove SnapShot admins as long as each admin is either a treasury signer or the moderation workstream leader.

Motivation: This will free up space for new strategies as ShapeShift’s space is already at the max capacity of 8.

Drawbacks: those who still have FOX deposited into a Rari pool, Tokemak reactor, or a future chain or defi protocol that gets sunset will lose their corresponding voting power.

  1. Create a new SnapShot sub-space for the Ideation stage of the governance process

Context: Ever since the migration of ShapeShift’s forum from Metaforo to Discourse, the Ideation phase has taken place in the shapeshiftdao.eth SnapShot space. Since then, SnapShot has released a feature enabling spaces to add sub-spaces.

Specification: If this proposal passes, a new space would be created called ShapeShift Ideation where Ideation proposals could be published. The ShapeShift Ideation space would be added as a sub-space to the main shapeshiftdao.eth space and would have all of the same settings as the main space, and the governance process would be updated to require that Ideation proposals are published and voted on in the Ideation space.

Motivation: Have a dedicated space to review and vote on Ideation proposals, minimize redundancy in the main SnapShot space (which can lead to confusion or voter apathy for less active community members), and keep the main SnapShot space focused on proposals that have passed Ideation and have a greater likelihood of being refined and passing.

Drawbacks: Changes in the governance process can cause confusion for those accustomed to the current process. This will also make Ideation proposals less visible. It also adds an additional space for the SnapShot admins to manage.

  1. Set the voting period to 5 days for the main SnapShot space and to 7 days for the Ideation space

Context: Currently the governance process requires official proposals to be active in voting for a minimum of 5 days and maximum of 60 days, and for ideation proposals to be active for a minimum of 7 days (no max). SnapShot doesn’t yet offer the ability to set minimum or maximum voting periods, but it does have the ability to set mandatory voting periods.

Specification: Both the main snapshot space and ideation sub-space would be configured to require 5 day and 7 day voting periods respectively.

Motivation: Simplify the process of making a proposal and eliminate the potential for a valid ideation proposal to be active indefinitely.

Drawbacks: This would remove the ability to create proposals with custom voting periods. (this is the change I feel is least necessary, so encourage any community members that prefer to keep the flexibility with voting periods to speak now!)

2 Likes

2023* we cant look that far into the future …

2 Likes

More …clarity there? Admins can delete, but not admin users(?) oh admins cant remove other admins? (are we going to be able to remove the old admins then?)

(at the mod level, i was able to delete the bad snaps… but they just reposted, i couldnt raise the amount to stop them) had to call reinforcements.

1 Like
  1. can we set 2 options? at least set 5day minimum. (or only if we do 4)

exactly, admins can’t delete other admins, but shapeshiftdao.eth can as the controller! was thinking we could include the tx to replace admins and add the new admins in the proposal and execute via oSnap

full deets on space roles and permissions: Space roles - snapshot

1 Like

unfortunately can only set one option per space (so yes, #5 is dependent on #4), and also can’t set a minimum, only a mandatory