What Are Governance Proposals?

Introduction

governance proposals are the mechanism blockchains and DAOs use to convert a possible change into a reviewable, contestable, and often executable decision. That sounds straightforward, but it solves a hard coordination problem: in decentralized systems, there is no single manager who can simply decide what ships next, who gets paid, or when protocol rules change. A proposal is the object around which that coordination happens.

What makes proposals interesting is that they sit at the boundary between discussion and action. A forum post can express an opinion, and code can express an implementation, but a governance proposal has to connect the two. It needs enough structure that other people can understand the intended change, argue about tradeoffs, evaluate risks, and, in some systems, trigger the change automatically if it passes.

This is why governance proposals appear across very different ecosystems. Ethereum uses EIPs to specify changes and document rough consensus. Cardano uses CIPs as formal design documents in its governance pipeline. Tezos uses TZIPs for ecosystem standards while protocol amendments follow a separate on-chain process. Cosmos chains commonly use an on-chain governance module where a proposal can carry executable messages. Polkadot OpenGov treats proposals as public referenda routed through tracks with different thresholds and timing. Compound-style DAO systems package proposals as bundles of on-chain actions, then delay execution through a timelock. Snapshot lets communities vote off-chain while still defining who has voting power and what the vote means.

The common idea is simple: a governance proposal is a standardized claim that a community can evaluate and, if accepted, treat as authoritative. The details vary because different systems disagree about what “accepted” should mean and what should happen next.

Why is a governance proposal more than just a vote?

The easiest mistake is to think a governance proposal is just a ballot item. In practice, the proposal comes earlier and does more work than the vote itself.

The problem being solved is not merely “count preferences.” It is coordinate many parties around a shared description of a change. In a blockchain ecosystem, those parties may include tokenholders, validators, delegates, client developers, wallet teams, application developers, exchanges, and users. They do not all have the same role, and they often do not even use the same decision mechanism. A proposal gives them a common object to inspect.

That common object usually has three layers. First, it identifies the problem: what is wrong, missing, or worth changing. Second, it specifies the mechanism: what exact rule, interface, parameter, or transfer is being proposed. Third, it states the rationale: why this design was chosen instead of alternatives, and what risks it introduces. Ethereum’s EIP process makes this explicit by requiring a concise technical specification and a rationale, plus a mandatory security considerations section before an EIP can become Final. Cardano’s CIP format similarly requires a specification, rationale, and a “Path to Active,” including acceptance criteria and an implementation plan. Tezos guidance for TZIPs expects not just a specification and rationale but also implementation guidance and an FAQ addressing objections and alternatives.

That structure is not bureaucracy for its own sake. It exists because governance fails when participants are voting on different interpretations of the same text. A proposal format forces the author to compress ambiguity before the community has to make a decision.

Why do governance processes require strict proposal formats?

If proposals are coordination objects, standardization is what makes them usable at scale.

Ethereum’s EIP-1 is a good example. An EIP must include a defined preamble and sections such as Abstract, Specification, Rationale, Security Considerations, and copyright waiver. Cardano’s CIP process similarly requires Markdown with a YAML preamble and defined sections. These requirements look editorial, but the mechanism is deeper: a fixed schema makes proposals searchable, comparable, reviewable, and archivable. Editors and tools can tell what stage a proposal is in, what dependencies it has, where discussion happens, and whether core information is missing.

There is also a governance reason for strict formatting. In decentralized systems, there is often no central product manager to ask, “Is this complete enough to review?” The process needs objective checks that can be applied by editors or maintainers without deciding the proposal’s merits. EIP editors, for example, handle administrative tasks such as checking formatting, assigning numbers, and merging process-compliant submissions, while explicitly not acting as arbiters of technical truth. Cardano CIP editors play a similar process-enforcement role.

This separation matters. If the same actor both controlled admissibility and judged substance, the proposal process would quietly become centralized. By narrowing the editor’s role to process hygiene, many ecosystems try to preserve a distinction between *is this properly formed? * and *should the community adopt it? *

Still, formatting does not eliminate politics. It only makes the politics legible.

How does a governance proposal progress from draft to implementation?

A governance proposal matters only if people know where it stands. That is why mature systems define a lifecycle.

In Ethereum, an idea begins informally, becomes a Draft when formally tracked, then can move through Review and Last Call toward Final. It can also become Withdrawn, Stagnant, or Living, depending on what happens. Cardano’s CIP process uses a simpler status model (Proposed, Active, Inactive) but adds a required explanation of how the proposal will become Active. These statuses are not ceremonial. They answer a basic question for implementers and users: *is this merely being discussed, or is it now something others should build against? *

The key invariant is that proposal status should describe the state of social and technical convergence, not just the author’s enthusiasm. A Draft means “this exists”; it does not mean “this will ship.” Final means something stronger, but even that depends on the ecosystem. For an Ethereum Core EIP, reaching Final generally requires client implementation and, where relevant, the coordination needed for a fork. In Cardano, the CIP process is explicitly documented as not itself governing deployment; it is a crucial pipeline component, but not the enforcement mechanism. Tezos makes the split even clearer: TZIPs usually describe standards and ecosystem improvements, while protocol amendments follow a different formal on-chain governance path.

This is a useful distinction to remember: a proposal process can define legitimacy without directly changing chain state. Some proposal systems are primarily documentation and consensus machinery. Others are also execution machinery.

Documentation-first vs execution-first proposals: what's the difference?

Most governance proposals fall somewhere between two poles.

At one pole, the proposal is mainly a specification and coordination record. EIPs, CIPs, and many TZIPs work this way. They tell the community what change is being proposed, gather feedback, and document the final design if it is adopted. But the proposal document itself does not usually flip a protocol bit on-chain. Actual deployment still depends on client releases, validator adoption, ecosystem coordination, or a separate amendment process.

At the other pole, the proposal is an on-chain instruction container. Cosmos SDK governance is an unusually clear example. A proposal includes an array of sdk.Msgs. If the vote passes under the chain’s quorum, threshold, and veto rules, those messages are executed automatically by the governance module account. In Compound governance, a proposal consists of executable actions that, once approved, are queued in a timelock and then executed. In OpenZeppelin’s Governor architecture, the same logic appears as a general pattern: a proposal passes through voting, then a timelocked operation becomes executable after a delay.

The difference is not cosmetic. In the first model, the proposal’s main output is shared knowledge and legitimacy. In the second model, the proposal’s output is state transition. That changes what must be secured.

If a proposal only documents a standard, the main risks are ambiguity, ecosystem fragmentation, or premature standardization. If a proposal can execute transactions, the risks include malicious payloads, hidden side effects, governance capture, and timing attacks. That is why execution-oriented governance systems often add economic gates, quorum rules, timelocks, vetoes, or emergency cancellation paths.

Example: How does a proposal change a protocol parameter end-to-end?

Imagine a lending protocol wants to reduce the collateral factor for a volatile asset because market conditions have worsened.

In a specification-first ecosystem, the proposal might begin as a design document. The author explains the problem: under current parameters, liquidations may not happen quickly enough in a sharp move. The specification states the exact parameter change. The rationale explains why this value was chosen instead of a more aggressive reduction. Security considerations discuss the risk of unnecessary liquidations, oracle assumptions, and the possibility that integrators have hard-coded old values. Review happens in public, dissent is documented, and if rough consensus forms, the change is implemented by client teams or protocol maintainers through the ecosystem’s deployment process.

In an execution-first DAO, the same change would likely be packaged as an on-chain proposal. The proposer assembles the exact function call needed to update the risk parameter. If the system resembles Compound, only an address with enough delegated voting power can submit it directly, though some systems provide lower-friction paths such as autonomous or sponsored proposals. Voting opens after a delay so participants can inspect the payload. Tokenholders or delegates vote. If quorum and majority conditions are met, the proposal is queued in a timelock. During that delay, users can react: exit positions, challenge the proposal socially, or prepare for the change. Once the timelock expires, anyone authorized by the system’s execution rules can trigger the transaction. The parameter on-chain changes, and the proposal has moved from text to state.

The mechanism is the same in both cases at a high level: define the intended change, expose it to scrutiny, measure acceptance, then make the accepted version authoritative. The difference is where the last step happens.

Who can submit proposals and how are proposer gates enforced?

Proposal systems also need a gate at the front door. Without one, spam overwhelms review and voters face an impossible filtering problem.

Different ecosystems choose different anti-spam mechanisms because they are controlling different failure modes. In Ethereum’s EIP process, the cost is mostly social and editorial: you need to write a conforming design document and sustain discussion. In Cosmos governance, there is a direct economic gate: proposals require a deposit, and only after the total deposit reaches MinDeposit do they enter the voting period. If the threshold is never reached before deposit_end_time, the proposal is removed and deposits can be burned. In Polkadot OpenGov, moving a referendum into its Decision Period requires a Decision Deposit, and the amount depends on the privilege level of the proposal’s origin. In Compound, the gate is delegated voting power: only addresses with enough delegated COMP can create standard proposals, though an autonomous proposal path lowers the initial barrier by requiring a smaller lock and later sponsorship.

These gates all do the same conceptual job: they force the proposer to bear some cost before imposing attention costs on everyone else. But they produce different politics. Deposit-based systems are more open to anyone with capital. threshold-based systems are more open to those with social backing from delegates or tokenholders. editorial systems are more open to technically capable authors who can write a credible spec and build discussion.

No choice is neutral. A low gate increases participation but invites noise. A high gate reduces noise but can entrench existing power.

What different voting mechanisms do blockchains use?

Once a proposal reaches decision, “voting” can mean surprisingly different mechanisms.

Some systems count plain token-weighted yes/no preferences. Others build more structure into what a vote expresses. Cosmos governance includes Yes, No, NoWithVeto, and Abstain, with separate quorum, threshold, and veto logic. Polkadot OpenGov evaluates proposals using two simultaneous metrics: Approval, which compares conviction-weighted aye votes to aye-plus-nay, and Support, which measures aye plus abstain relative to active issuance. Those metrics are checked against track-specific curves during the confirmation period. This means a proposal needs not just intensity among participants but enough broader backing to clear the relevant track.

Some systems also change how voting power itself is measured. Snapshot spaces use configurable voting strategies to determine voting power, and the total may aggregate several strategies. This makes off-chain governance flexible: a DAO can define voting power by token balances, delegated balances, whitelists, or custom logic. Polkadot lets voters increase influence through conviction by locking tokens longer. Compound-style systems use delegated voting with historical snapshots so that voting power is measured at a defined point rather than being manipulable during the vote.

The underlying invariant is that governance must define both who counts and when their weight is measured. If either is unclear, proposals become gameable.

Why do governance systems use timelocks and execution delays?

A proposal that passes instantly is efficient, but it is also dangerous.

Execution delays exist because governance is not just about preference aggregation; it is also about credible notice. Compound’s model makes this explicit: after a successful vote, proposals are queued in a Timelock and can only be implemented after the delay. OpenZeppelin’s TimelockController generalizes the same idea. Operation statuses move from unset to pending to ready to done, and only ready operations can be executed.

The mechanism here is simple and powerful. By separating approval from execution, the system gives users time to inspect what is about to happen and react if necessary. They can withdraw funds, unwind leverage, exit a protocol, alert others to a malicious payload, or prepare software changes. In effect, the timelock turns governance from a surprise into a scheduled event.

This also explains why emergency powers remain controversial but common. If a malicious or clearly broken proposal slips through, some systems provide cancellation or kill paths. Polkadot defines origins that can cancel or kill referenda, with different refund and slashing outcomes. Compound allows cancellation under specific conditions before execution. These controls reduce catastrophic risk, but they also reintroduce privileged actors. The tradeoff is real: more safety often means less pure decentralization.

What real-world changes do governance proposals enable?

Governance proposals are often described abstractly, but their practical role is concrete: they are the authorized path for changing shared rules or shared resources.

In protocol governance, proposals may change consensus or network behavior, as with Ethereum Core EIPs or formal on-chain amendment systems. In standards governance, proposals define interfaces that let independent builders interoperate, such as ERCs in Ethereum or TZIP standards like wallet interaction and token interfaces in Tezos. In DAO operations, proposals commonly direct treasury allocations, parameter changes, incentives, grants, software upgrades, and role assignments. This is why governance proposals are the control surface for treasury management and protocol administration.

The important point is that a proposal is not limited to “big constitutional questions.” Most of the time, it is the routine machinery of maintenance. A protocol’s risk parameters, fee switches, listing criteria, or upgrade modules may all move through the proposal process. Over time, proposals become the chain or DAO’s memory of why things are the way they are.

What are the main risks and failure modes of governance proposals?

Proposal systems are useful because they formalize decision-making. They are fragile because they cannot eliminate power, incentives, or manipulation.

A well-structured proposal can still be socially engineered. The text may sound reasonable while the executable payload does something else. This is especially dangerous in on-chain systems where only a small set of technically sophisticated reviewers inspect calldata or function calls. Proposal interfaces can also mislead users by hiding details, making human-computer interaction a real governance attack surface.

Token-weighted systems face another class of problem: passing a proposal may be cheaper than the value it can extract. Research surveying DAO attacks finds that token-control, bribery, interface manipulation, and code-level exploits all recur in practice, and that low participation materially increases vulnerability. If only a small share of token supply votes, an attacker may not need to buy the whole system; they only need enough influence to dominate the active electorate. Flash-loan governance attacks are the extreme case, where temporary capital is enough to seize control if the system snapshots voting power poorly or gives execution authority too quickly.

Even purely off-chain or documentation-heavy processes have their own failure modes. They may produce respected standards without clear enforcement, leaving adoption fragmented. Or they may create the appearance of legitimacy without genuine implementer commitment. Cardano’s CIP process is explicit that a positive review or endorsement is not itself an implementation promise. Ethereum’s EIP process likewise depends on rough consensus and actual client adoption rather than a formal binding vote on every technical change.

In other words, a proposal is only as strong as the mechanism that turns acceptance into reality. Sometimes that mechanism is code. Sometimes it is social consensus. Sometimes it is the willingness of maintainers, validators, or multisig signers to act.

Why do governance proposals always involve political trade-offs?

It is tempting to divide proposals into “technical” and “political,” but the line is thinner than it looks.

A proposal about a token interface standard may seem technical, yet it changes who can integrate with whom and at what cost. A proposal about a treasury grant may seem political, yet it often depends on technical milestones and implementation plans. Even a parameter change encodes a view about acceptable risk, fairness between users, and who bears downside in stressed conditions.

That is why good proposal processes ask for both specification and rationale. The specification says what changes. The rationale exposes which values and tradeoffs guided the design. Security considerations ask what could go wrong if we are mistaken. Without all three, a proposal is incomplete.

This is also why proposal systems often coexist with neighboring institutions rather than replacing them. Multisigs may execute or emergency-stop changes. Delegates may specialize in review. Client teams may determine practical feasibility. Editors may enforce process shape without deciding substance. The proposal is the focal object, but governance remains a system of interacting roles.

Conclusion

A governance proposal is best understood as the formal container that lets decentralized communities argue about a change in a shared language and, if they accept it, make that change authoritative. Sometimes that authority is documentary, as in standards and improvement proposals. Sometimes it is directly executable, as in on-chain governance modules and timelocked DAO actions.

The enduring idea is simple: decentralized systems still need a way to say, clearly and publicly, here is the change, here is why, here is how we decide, and here is what happens if it passes. Governance proposals are that way. They do not remove politics or risk, but they make both visible enough to be contested.

How does this part of the crypto stack affect real-world usage?

Governance mechanics determine how quickly and safely a proposed change can affect on-chain state and asset value. Before you fund, trade, or hold a governance-sensitive token, check whether the chain’s proposals execute state changes directly or only document a standard; that distinction affects how fast risk can materialize. Use Cube Exchange to act on assets with that context: fund your account on Cube, then execute trades timed and sized to the governance cadence you observed.

1. Read the chain’s governance documentation and confirm whether proposals execute on-chain or are documentation-only, and record the standard timelock length (e.g., 2 days, 7 days).
2. Check how voting power is measured: confirm snapshot timing, delegation rules, and whether off-chain systems (like Snapshot) determine influence.
3. Verify anti-spam and proposer gates: note MinDeposit amounts, deposit refund/burn rules, and proposer threshold requirements.
4. Fund your Cube Exchange account via fiat on‑ramp or supported crypto transfer, open the asset market, and use a limit order for controlled entry timed around the proposal’s execution or timelock window.