The Vote That Undoes the Last Vote

Six months ago your DAO capped treasury withdrawals at 50,000 USDC per quarter. The debate was long, the vote passed at 63%, and everyone moved on. Now a new proposal wants to pull 200,000 USDC in a single transaction to fund a marketing push. It also passes, narrowly, at 54%. You're sitting in the governance forum watching both outcomes sit there, green checkmarks on both, and nobody can tell you which one is actually in force.

The answer is almost never automatic. That gap between "the vote passed" and "the outcome is settled" is where most DAO governance writing stops paying attention.

Decentralized autonomous organizations have no judge, no board of directors, no appeals court. What they have is a combination of smart contract logic, constitutional documents (usually called a governance framework or charter), and social consensus that ranges from iron-clad to completely absent depending on the project. Understanding how contradictory proposals get resolved means understanding all three layers at once.

When Smart Contracts Are the Final Word

Some DAOs encode their rules directly into immutable or time-locked contracts. Compound's Governor Bravo architecture enforces a mandatory two-day timelock between a proposal passing and its execution. That window is partly a security measure, but it also functions as a conflict-detection buffer. If a new proposal tries to call the same contract function a previous vote already modified, the second transaction will either revert (if the state it expects no longer exists) or silently overwrite the first outcome.

That last option is the dangerous one.

Silent overwriting is how you get a DAO that technically honored every vote and still ended up somewhere its community never intended. It's like a ship's log where the navigator keeps correcting the previous entry instead of recording a new one: the record looks clean, the journey is not.

The cleaner technical pattern is a proposal dependency flag: a proposal declares which prior resolutions it supersedes, and the contract checks whether those prior resolutions are still in their expected state before executing. MakerDAO's governance contracts have used variants of this to manage conflicting Stability Fee adjustments. The mechanism isn't foolproof, but it at least makes the conflict visible on-chain rather than burying it.

Here's a worked example. A DAO's contract holds a single `uint256 maxWithdrawal` variable. Proposal A sets it to 50,000. Proposal B, drafted while A is still in its timelock, sets it to 200,000. Both pass. Both execute in sequence. Final state: 200,000. Proposal A's outcome has been legally overwritten. Nobody cheated. The smart contract did exactly what it was told. The governance process simply had no mechanism to flag that B was in direct tension with A.

The Paper Layer: Constitutions and Frameworks

Because on-chain logic alone can't capture intent, most serious DAOs maintain an off-chain governance framework, sometimes called a constitution or operating agreement. These documents establish things contracts can't: supermajority requirements for amending core parameters, mandatory discussion periods, explicit hierarchies between proposal types.

Uniswap's governance documentation distinguishes between temperature checks, consensus checks, and on-chain governance votes, each tier with different quorum thresholds. A proposal that contradicts a prior on-chain vote could theoretically be blocked at the temperature-check stage by a community that recognizes the conflict, long before it reaches a binding vote.

The catch: these frameworks are only as strong as the community's willingness to enforce them. There's no sheriff. If a whale with 15% of the voting tokens wants to push a contradictory proposal through, the framework is a speed bump, not a wall. The history of DAO governance is littered with cases where a well-written charter simply got voted around by a motivated coalition.

What people consistently get wrong is assuming a "constitutional" proposal is inherently harder to override than a regular one. In most DAOs, it isn't. The same token-weighted vote that passed the constitution can amend or contradict it. The protection is reputational and social, not cryptographic. That's a meaningful distinction, and glossing over it is how communities get ambushed.

The Human Layer: Soft Consensus and the Forum Fight

Between the smart contract and the governance doc sits the messiest layer: forums, Discord threads, and the informal power of core contributors.

Consider two fictional delegates, Priya and Marcus, both holding voting power in the same mid-sized DeFi protocol. Priya voted for the original 50,000 USDC cap and holds roughly 8% of delegated tokens. Marcus is new, backed by a group of investors who joined after the cap passed, and he controls 11%. Marcus submits the 200,000 USDC proposal. In the forum, Priya argues it violates the spirit of the prior vote. Marcus argues the prior vote is stale and circumstances changed. The community splits. The proposal passes on token weight alone.

This is the normal case. Not a hack, not a failure of code. Governance working exactly as designed, producing an outcome that a significant minority considers illegitimate.

The question of legitimacy matters more than it sounds. A DAO whose contributors feel its votes are routinely hijacked by whales will see its best developers leave, its proposals become less ambitious, its treasury decisions made by an ever-shrinking circle. The contradiction between two votes is often less damaging than the erosion of trust that follows how the contradiction was handled.

What Actually Gets Done About It

Practically speaking, DAOs use four mechanisms to manage contradictory proposals, with varying effectiveness.

First, explicit supersession clauses: the new proposal's text states that it replaces resolution X, and delegates can vote knowing exactly what they're overriding. This is the most honest approach and, frustratingly, the least commonly used.

Second, tiered voting thresholds: amendments to foundational parameters require a higher quorum or supermajority than ordinary proposals. Aave's governance V3 architecture uses risk parameter tiers that require guardian multisig approval before certain changes can execute, adding a human checkpoint above the token vote.

Third, time-based precedence rules: some frameworks specify that when two passed proposals conflict, the more recent one governs. Simple, predictable, and occasionally disastrous if the more recent vote was pushed through with low turnout.

Fourth, governance minimization: the most principled escape from the problem is to reduce the number of things that can be changed by governance at all. Fewer governable parameters means fewer surfaces for conflict. Vitalik Buterin has written about this as a design goal worth taking seriously. The fewer decisions a DAO needs to make, the fewer contradictions it can produce.

Are you evaluating a DAO right now? Pull up its governance forum and search for the word "supersede." If no one has ever used it, the project either has very simple governance or has never had to confront a real conflict yet. One of those is fine. The other is a warning.

The conflict itself isn't the bug. Disagreement over direction is what governance exists to process. The bug is building systems where that conflict gets resolved invisibly, by whoever happens to move faster or hold more tokens, with no record of what was overridden and why. On-chain permanence is supposed to be one of this technology's core promises. A governance layer that quietly overwrites its own history is the most ironic way to break it.