Implement Proposer Roles

Shutter DAO 0x36 SD 0x36 Proposals
1

Proposal

Implement Proposer Roles and increase the minimum SHU token requirement to submit proposals.

The goal is to prevent governance attacks and low-quality proposals in a manner that maintains decentralization and provides a fallback mechanism.

Implementation will be done via a staged rollout, including testing and progressive increases in SHU token requirements.

Context

Last month, Shutter DAO 0x36 implemented a Security Council in order to mitigate the risk of governance attacks. The Security Council is a significant improvement. However, it does not prevent governance attacks, including spam attacks.

Currently, anyone holding at least 1 SHU can create an unlimited number of onchain proposals on Decent at any time.

This proposal introduces the implementation of Proposer Roles and an increase to the minimum SHU token requirement to submit proposals as a way to prevent governance attacks at the source.

Proposer Roles

According to the Decent DAO documentation on roles and permissions:

  • Roles can be assigned to specific addresses

  • Roles can grant permissions (e.g. permission to create onchain proposals on Decent) regardless of SHU token holdings

  • Governance can flexibly combine role-based access control with token-based thresholds

In practice:

  • Proposers are assigned a role, not a committee position

  • Any Proposer may unilaterally create onchain proposals on Decent

  • Proposers should submit any bona fide (non-malicious) proposal, not only those they support

  • Proposer Roles may be granted or revoked at any time via an onchain proposal on Decent

Implementation of Proposer Roles

Addresses to Assign Proposer Roles

The following addresses would be assigned Proposer Roles:

  • 0xffFA76e332cA7afaae3931cb5d513B7fd681C4CF — Kleros Labs

  • 0xe52C39327FF7576bAEc3DBFeF0787bd62dB6d726 — 5pence

  • 0xDffDb9BeeA2aB3151BcBcf37a01EE8726F22ed94 — d0z3y

  • 0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44 — Mikko Ohtamaa

  • 0x06c2c4dB3776D500636DE63e4F109386dCBa6Ae2 — Jacob Czepluch

  • 0x1F3D3A7A9c548bE39539b39D7400302753E20591 — blockful

  • 0x057928bc52bD08e4D7cE24bF47E01cE99E074048 — DAOplomats

  • 0x302a65C78da31B9ec333c62B90d35D2e70fb3f4E — Lanski

  • 0x0f853a4c50763e0553Ac44E2546C0178B417c0Ba — Exocortex GmbH

These addresses include the 8 addresses in the Security Council plus Exocortex GmbH.

Term for Proposer Role

Unlimited.

Increase Minimum SHU Threshold

1 SHU → 100,000,000 SHU (100M SHU).

A minimum SHU threshold of 100M SHU acts as a decentralized fallback in case all Proposers lose access to their addresses.

100M SHU represents a significant portion of circulating supply (>25%). The likelihood of malicious accumulation at this level is extremely low.

In the (extremely rare) case that all Proposers lose access to their addresses, large SHU holders could coordinate to select new addresses to assign Proposer Roles and/or decrease the minimum SHU threshold.

Phased Implementation

Phase 1 (Setup)

  • Proposer Roles assigned to the addresses above

  • Increase minimum threshold 1 SHU → 1,000,000 SHU (1M SHU)

Phase 2 (Validation)

  • Run test transactions to confirm that:

    • An address with a Proposer Role but without 1M SHU can successfully create a proposal

    • An address without a Proposer Role and with ≥1M SHU can successfully create a proposal

    • An address without a Proposer Role and without ≥1M SHU cannot successfully create a proposal

Phase 3 (Final Configuration)

  • Increase minimum threshold to 100,000,000 SHU (100M SHU)

Platform

Decent (this proposal will trigger onchain transactions if passed)

Voting Options

Vote “Yes” to implement Proposer Roles via phased implementation

OR

Vote “No” to not implement

OR

Vote “Abstain” if you do not have an opinion but want to help the vote reach quorum