Voting & Proposal Mechanics
Proposal Process: To make any change or decision, a community member typically goes through:
Discussion: First, informally discuss the idea on forums or Discord. For major changes, a StableUnit Improvement Proposal (SIP) document might be drafted.
Proposal Submission: On the governance platform (currently Snapshot), a proposal is submitted. Depending on the rules, the proposer might need to hold a certain amount of SuDAO or have an NFT to create proposals. Some DAOs require a small deposit or backing by others.
Voting Period: Each proposal has a set voting window (e.g., 3-7 days). During this time, SuDAO holders cast their votes. Because of the dual voting mechanism, the UI likely shows overall results and possibly breakdowns by class.
Quorum: There might be a minimum quorum requirement – e.g., at least X% of the total voting power must participate for the vote to be valid. This prevents a small group from making decisions while most are inactive.
Approval Threshold: As discussed, normal proposals need >50% support. Constitutional proposals might need a higher bar (e.g., >66% or separate majorities). These specifics would be defined in the DAO governance docs.
Execution:
Currently, after a successful Snapshot vote, the core team’s multisig wallet will execute the result manually (for example, calling a function to change a parameter or deploying a new contract). This is done in trust of the team following the vote.
In the future, a system like Aragon, Tally, or a custom Governor contract will take the votes on-chain. Possibly, the protocol will implement a scheme where Snapshot votes produce a hashed result that a multisig can submit on-chain to a Governor contract to trigger execution (some projects do this as an interim step).
Eventually, the aim is full on-chain governance: proposals would be created on-chain (or Snapshot with on-chain execution through a module like Snapshot X or Tally), and once the vote passes, the changes are executed automatically by smart contracts (assuming timelocks or safety delays as needed).
Types of Proposals:
Risk Parameter Changes: e.g., “Increase ETH debt ceiling from $50M to $75M” or “Reduce stability fee on stETH from 3% to 2%.” These directly affect users and usually are frequent as the market evolves.
New Collateral Onboarding: e.g., “Add support for WBTC as collateral with 140% min collateralization, 5% stability fee, $20M ceiling.” Such proposals
New Collateral Onboarding: e.g., “Add support for WBTC as collateral with 140% min collateralization, 5% stability fee, $20M ceiling.” Such proposals would outline risk parameters and usually come after analysis by a risk working group. The DAO would debate and vote, and if passed, the devs (or an automated process) would enable that collateral in the protocol.
Economic Parameter Tweaks: e.g., adjusting the yield distribution rate algorithm, changing the circuit breaker percentage, or reallocating the SuDAO incentive emission schedule.
Treasury Actions: e.g., “Use $X from the treasury to buy back and burn USD Pro or SuDAO” or “Fund a grant of 50k SuDAO to a community developer building a mobile wallet integration.”
Protocol Upgrades: As the protocol evolves, there may be proposals to deploy new smart contracts or migrate to a new version. These require technical review and often a higher threshold (since they carry more risk).
Off-chain to On-chain: Currently, because voting is off-chain, after a vote passes there might be a slight delay before execution while the multisig enacts it. As the system moves to trustless on-chain voting, execution might be subject to a timelock (for security, giving a window where if something malicious passed it could be noticed and halted by emergency mechanisms).
Delegation in practice: Suppose Alice is very active in StableUnit governance and has proven knowledgeable. Bob and Charlie each hold SuDAO but cannot follow daily events. They delegate their votes to Alice. Now Alice’s votes count as Alice+Bob+Charlie’s weight. If Alice later does something they dislike, Bob and Charlie can undelegate and vote themselves or delegate to someone else. This flexibility ensures even if you can’t participate constantly, your voting power isn’t wasted – you can entrust it to someone aligned with your views.
Voting Interface: Using Snapshot (and in future, on-chain UI), SuDAO holders and NFT holders will use their wallet to sign votes. Each proposal typically provides choices (For, Against, maybe Abstain) and you simply select and confirm. Snapshot automatically reads your token balance and NFT to apply your vote weight. The results are transparent – one can see how much support each side (tokens vs NFTs) gave.
Community Governance Culture: Finally, it’s worth noting that a successful DAO relies on its community being informed and engaged. StableUnit encourages open discussion on its forum and Discord. The governance process is an open book – anyone can propose improvements (though there might be a required minimum amount of SuDAO to prevent spam proposals). Through this hybrid model of governance, StableUnit aims to be both efficient and inclusive: leveraging the expertise and stake of token holders while amplifying the voice of dedicated community members.