Proposal Deposit

The primary function is to impose a cost barrier against frivolous or malicious proposals that could congest the governance process. By requiring a significant financial stake, the system disincentivizes spam, ensuring only serious, well-considered proposals are submitted for community review and voting.

The deposit aligns the proposer's incentives with the network's health. It acts as economic skin in the game, signaling that the proposer has a vested interest in the proposal's success and the broader protocol's welfare, as their funds are at risk during the voting period.

Deposit handling is rule-based:

• Refunded: If the proposal passes a quorum and/or achieves a minimum approval threshold (e.g., 'Yes' votes > 50%).
• Burned/Slashed: If the proposal fails to meet these thresholds, the deposit may be destroyed or sent to the community treasury, penalizing unsuccessful submissions.

The deposit is almost always denominated in the network's native governance token (e.g., ETH, ATOM, UNI). The amount can be a fixed value or dynamically adjusted by governance. For example, a DAO may set a 100,000 token minimum to filter for substantial proposals.

The deposit is locked for the entire voting period and often through an additional timelock or execution delay. This prevents proposers from withdrawing collateral before the community has reached a final decision on the proposal's merits.

A related concept is a proposal bond, which may function similarly but is often specifically structured as a bond curve mechanism. Here, the required deposit amount can increase with the number of active proposals, creating a dynamic economic filter against spam waves.

The primary function is to deter spam proposals and Sybil attacks by imposing a financial cost on submission. This ensures the governance system is not flooded with low-quality or malicious proposals, protecting network bandwidth and voter attention. The deposit amount is typically set high enough to be meaningful but not prohibitive for legitimate proposals.

The deposit acts as a bond that demonstrates the proposer's commitment and belief in their proposal's merit. This "skin in the game" mechanism filters out frivolous submissions, as the proposer risks losing their funds if the proposal is rejected or fails to pass. It aligns the proposer's incentives with the network's health.

Deposit handling follows a defined lifecycle:

• Successful Proposals: The deposit is typically refunded to the proposer after the voting period.
• Rejected/Failed Proposals: The deposit may be burned (permanently removed from circulation) or sent to the community treasury, penalizing unsuccessful submissions.
• Quorum Not Met: Proposals failing to achieve minimum participation may also result in deposit forfeiture.

Deposit requirements vary by chain and are often governance parameters themselves:

• Cosmos Hub: Proposals require a deposit of 250 ATOM (as of governance proposal #248), which is dynamically adjusted.
• Osmosis: Initial deposit is 400 OSMO.
• Thresholds: Many chains implement a minimum deposit period where the proposal only enters voting once a target deposit size is met, allowing the community to crowdfund promising ideas.

A proposal deposit is distinct from a simple transaction fee:

• Fee: Compensates for network computation (gas).
• Deposit: A reclaimable bond tied to the proposal's outcome. Its purpose is economic curation, not resource payment. The deposit is held in escrow during the voting process and is subject to slashing based on governance results.

Compound's on-chain governance requires a proposal to be submitted with a proposal threshold, which is a fixed number of COMP tokens delegated to the proposer. While not a traditional deposit (tokens are not locked in a separate contract), this mechanism serves the same anti-spam function by ensuring only significant stakeholders can initiate governance actions.

A critical phase where the community crowdsources the required deposit. If the minimum is not met within the period (e.g., 14 days on Cosmos SDK chains), the proposal is rejected and deposits are refunded. If the minimum is met, the proposal moves to a vote. Refunds occur after voting concludes for all non-vetoed proposals.

The deposit amount and period are themselves governance parameters that can be changed via proposal. DAOs can adjust these to manage proposal volume—increasing the deposit to reduce spam during high activity, or decreasing it to encourage participation during stagnation. This creates a self-regulating mechanism for governance throughput.

Highlights a key off-chain vs. on-chain design difference. Ethereum Improvement Proposals (EIPs) have no financial deposit; they rely on social consensus, peer review, and client developer adoption. This contrasts with on-chain deposit systems, which use economic stake to gate entry, formalizing the proposal process directly into the protocol's state.

The deposit is a primary defense against Sybil attacks in governance, where an attacker creates many identities to submit spam. By requiring a staked economic value, the system ensures each proposal has a real cost. The threat of slashing for vetoed proposals further disincentivizes malicious or poorly constructed submissions.

The primary function is to disincentivize spam proposals that would congest governance. By requiring a sunk cost, the system imposes a financial penalty for frivolous submissions, ensuring only serious, well-considered proposals are put forward for community vote.

The deposit creates economic alignment between the proposer and the network. A proposer must have a vested interest in the protocol's success, as their funds are at risk. This reduces the likelihood of malicious or reckless proposals designed to harm the system.

Deposits are typically refunded if the proposal passes a preliminary quorum or vote threshold. However, they may be slashed or burned if the proposal is deemed malicious, fails to meet minimum participation, or violates protocol rules. This creates a clear cost for abuse.

Setting the correct deposit amount is a critical game theory problem. If too low, it fails to deter spam. If too high, it centralizes governance by excluding smaller token holders. Many protocols use dynamic adjustment algorithms based on proposal activity.

Unlike a transaction fee paid to validators, a deposit is a reclaimable bond. A fee is permanently spent, while a deposit is conditionally returned. This key difference makes the deposit a tool for quality signaling rather than mere resource pricing.

The deposit period is a defined timeframe during which the required deposit for a proposal must be fully collected. If the minimum deposit is not met by the deadline, the proposal is automatically rejected and deposits are refunded. This creates a social coordination challenge for proposers to rally support.

In some systems, deposits can be slashed or confiscated as a penalty. This typically occurs if a proposal is found to be malicious, spam, or violates network rules after submission. This mechanism adds a reputational and financial cost to bad-faith proposals, strengthening the spam filter.

A bonding curve can dynamically adjust the required deposit based on proposal activity. For example, the cost might increase as more proposals are submitted in a short period. This is an advanced anti-spam mechanism that makes spam attacks economically prohibitive.

Deposit requirements interact with voting power and delegation. Large stakeholders or delegated validators are often best positioned to fund deposits, which can centralize proposal submission. Some protocols allow delegates to pool funds or sponsor proposals to mitigate this.

Governance systems often implement different proposal types with corresponding deposit tiers. A simple parameter change may require a small deposit, while a protocol upgrade or treasury spend requires a much larger one. This aligns the economic stake with the proposal's potential impact.

A refund mechanism returns the deposit to the proposer(s) if the proposal passes certain milestones, such as entering the voting period or being successfully executed. This rewards legitimate participation. Refunds are typically processed automatically by the protocol's smart contracts.