Default Collection Governance

SZNS Voting Process
Collections democratize the management of NFT baskets as a DAO. Decentralized governance is an evolving problem and effective DAO models vary from community to community. 
SZNS makes the initial governance setup easy by offering a lightweight system with sensible default parameters to both empower Collection holders with ownership decision-making, as well as protect owners from malicious proposals.
Voting Process
SZNS simplifies governance by pulling the majority of actions for a standard proposal into a single interface.
1.A Collection member (owns some amount of Collection token) submits a proposal
2.Collection members vote on active standard proposals
3.After voting, the sznsDAO or any user will submit a 1ETH bond to confirm proposal results
4.If the bond is not challenged during the 1 week period, the transactions are executed by the Collection
Default Proposal Requirements
Programatic Parameters (determined programmatically):
SnapShot Parameters
Submitter Owns Collection Token
Reality Oracle Parameters
Bond: 1 ETH
Expiration: 1 Week
Timeout: 48 Hrs (defines the amount of time before execution is unavailable)
Cooldown: 0
Subjective Parameters (double-checked via reality.eth):
Length of Voting: defined by proposer
Length of Verification: 1 Week (defined here)
Voting Quorum: 50% Total Supply
‘Yes’ Token Weighted Threshold: 85% 
‘No’ Token Weighted Threshold: 10%
The default parameters expect a high participation rate from Collection token holders to make a collective decision. This assumption is built around the idea that Collections will consist of a fairly tight knit community.
Proposal Rejection
Proposals can be rejected at two main stages: (1) during Snapshot voting and (2) during the Reality.eth arbitration.
(1) A proposal is rejected if it doesn't follow the Governance Rules:
Less than 50% of the token economy votes (quorum)
Less than 85% of the voting population votes Yes
(2) Reality.eth arbitration
2.1 Users Challenging Incorrect Verification
After a successful Snapshot voting period, the proposal is sent to Reality.eth for a verification of results before the proposal's transaction is sent on-chain. During this period, users can check whether a successfully voted proposal has met the guidelines of what constitutes a valid proposal. 
During the verification stage on Reality.eth, users must put up a Bond of 1ETH to as part of their attestation that the buyout proposal is indeed valid. Users can contest by doubling the Bond. At the end of the verification period, users who have put up a Bond for the incorrect answer will lose their Bonded ETH, those who place a bond for a correct answer receive their ETH back, and those who successfully challenge someone who bonded an incorrect answer receives the ETH staked by the incorrect user. This process prevents malicious actors who lie to pass invalid proposals.
2.2 Users asking for Arbitration
The other way a proposal might be rejected is via Arbitration. To begin, the SZNS multisig is the first arbiter for all Collections. Eventually this responsibility will be given to others within the Collection community. 

Collection Governance - Previous

Collection Lifecycle

Tokenholder Voting

Last modified 1mo ago

Copy link

Outline

Voting Process

Default Proposal Requirements

Proposal Rejection