Proposal

The proposal's core logic and voting outcomes are recorded immutably on a blockchain. This ensures transparency, auditability, and tamper-resistance. Key components include:

• Smart Contract Execution: The proposal payload (e.g., treasury transfer, parameter change) is encoded for automatic execution upon passing.
• Immutable Record: All votes, discussions (if on-chain), and the final state are permanently recorded.
• Gas Costs: Submitting and executing proposals requires paying network transaction fees.

A DAO proposal follows a defined state machine from creation to resolution. A typical lifecycle includes:

• Drafting & Temperature Check: Informal discussion off-chain (e.g., in a forum) to gauge sentiment.
• Formal Submission: The proposal is submitted on-chain, often requiring a proposal deposit.
• Voting Period: Token holders cast votes weighted by their governance power.
• Timelock & Execution: If the vote passes, there is often a mandatory delay (timelock) before the proposal's actions are executed, providing a final safety check.

Proposals are ratified through specific voting models that determine how member preferences are aggregated. Common mechanisms include:

• Token-Weighted Voting: One token equals one vote; voting power is proportional to economic stake.
• Quadratic Voting: Voting power increases with the square root of tokens committed, reducing whale dominance.
• Conviction Voting: Voting power accrues over time a voter supports a proposal, signaling stronger conviction.
• Multisig Approval: Execution requires signatures from a predefined set of trusted addresses.

This is the executable content of the proposal, defining the specific actions to be performed by the DAO's smart contracts. Common payload types include:

• Treasury Management: Transferring funds, approving a grant, or making an investment.
• Parameter Updates: Changing protocol fees, reward rates, or collateral ratios.
• Code Upgrades: Upgrading core protocol smart contracts via a proxy admin or similar mechanism.
• Membership Changes: Adding or removing members from a multisig wallet or council.

These are the minimum participation and approval requirements for a proposal to pass, preventing low-turnout decisions. Key metrics include:

• Quorum: The minimum percentage of total voting power that must participate for the vote to be valid.
• Approval Threshold: The minimum percentage of participating votes required for a 'Yes' outcome (e.g., simple majority >50%, or supermajority >66.6%).
• Veto Threshold: A minimum 'No' vote percentage that can defeat a proposal regardless of 'Yes' votes.

Many DAOs require proposals to be sponsored or have a minimum proposal deposit to prevent spam and ensure seriousness. Key aspects:

• Bond/Deposit: A staked amount (in governance tokens) is required to submit a proposal, which may be slashed if the proposal fails or is malicious.
• Delegated Submission: Some systems allow delegates or working groups to submit proposals on behalf of token holders.
• Whitelisting: Only addresses holding a minimum token balance or belonging to a specific committee can submit proposals.

Critical mechanisms designed to prevent malicious or erroneous proposals from causing protocol harm.

• Timelocks: Enforce a mandatory delay between a vote passing and its execution, allowing users to react or exit.
• Multisig Guardians: Emergency councils (e.g., MakerDAO's Governance Security Module) with the power to pause or veto proposals.
• Proposal Thresholds: Minimum token requirements to submit a proposal, preventing spam.
• Quorums: Minimum participation thresholds for a vote to be valid.

A structured process from ideation to execution. Key stages include:

• Drafting & Discussion: Informal forum debate to refine the idea.
• Temperature Check: A non-binding snapshot vote to gauge sentiment.
• Formal On-Chain Submission: The proposal is submitted with executable code or a clear description, locking a proposal deposit.
• Voting Period: Token holders cast votes, often weighted by stake.
• Timelock & Execution: If passed, a timelock delay allows for review before the proposal's changes are executed on-chain.

Proposals are prime targets for governance attacks. Major risks include:

• Proposal Spam: Flooding the system with proposals to exhaust voter attention or block legitimate ones.
• Malicious Code Injection: A proposal that appears benign but contains hidden logic to drain funds or upgrade to a malicious contract.
• Vote Manipulation: Exploits like vote buying, flash loan voting (borrowing tokens to swing a vote), or timestamp manipulation.
• Typosquatting: Creating a proposal that mimics a legitimate one to trick voters.

Critical parameters that determine a proposal's validity and outcome.

• Quorum: The minimum percentage of total voting power that must participate for the vote to be valid. Prevents a small, active group from controlling outcomes.
• Approval Threshold: The percentage of participating votes required for a proposal to pass (e.g., >50% for simple majority, >66% for supermajority).
• Veto Threshold: Some systems allow a minority with significant stake (e.g., a security council) to veto a malicious proposal that has passed.

Protocols implement safeguards to protect against malicious proposals.

• Proposal Deposits: A stake required to submit a proposal, which is slashed if the proposal fails or is deemed spam.
• Timelocks: A mandatory delay between a proposal's passage and its execution, allowing users to exit or for a last-line veto to be exercised.
• Multisig Guardians: A trusted, elected committee with the ability to pause or cancel a proposal in an emergency.
• Code Audits & Formal Verification: Requiring critical proposals to have undergone independent security review before being executable.

How voting rights are assigned and exercised in decentralized governance.

• Token-Weighted Voting: One token equals one vote. Concentrates power with large holders (whales).
• Delegation: Token holders can delegate their voting power to representatives or delegates who vote on their behalf, increasing participation.
• Quadratic Voting: Voting power increases with the square root of tokens committed, designed to reduce whale dominance.
• Non-Transferable Voting Power: Systems like ve-tokenomics where locked tokens grant non-transferable governance rights, aligning long-term incentives.

What happens after a proposal passes and the challenges of undoing changes.

• On-Chain Execution: The proposal payload (smart contract call) is automatically executed by the governance module.
• Off-Chain Signaling: Some proposals are merely advisory, requiring manual implementation by a core team.
• Irreversibility: Most on-chain executions are immutable. A bad proposal can only be "fixed" by a subsequent proposal, creating race conditions.
• Emergency Forks: In catastrophic cases (e.g., a passed exploit), the community may socially coordinate a chain fork to abandon the malicious state, as seen historically in The DAO hack.

The process of transferring one's voting power to another address, allowing a representative to vote on behalf of the token holder.

• Purpose: Enables efficient governance by consolidating voting power with knowledgeable or active community members.
• Mechanism: Non-custodial; tokens remain in the holder's wallet, but voting rights are assigned to the delegate.
• Outcome: Creates a system of representatives or 'governance whales' who can significantly influence proposal outcomes.

A wallet or smart contract that requires multiple private keys to authorize a transaction, often used as the executive body for a DAO.

• Governance Role: Frequently holds the protocol's treasury or upgrade keys. A successful on-chain proposal typically instructs the multisig to execute the approved action.
• Security Model: Distributes trust among a council of elected or appointed signers (e.g., 4 out of 7 signatures required).
• Evolution: Represents a hybrid model between pure on-chain voting and traditional corporate governance.