An on-chain vote publishes each ballot as it is cast, and closes at a block height fixed when the proposal was created. Both properties are usually treated as virtues: the tally is auditable in flight, and nobody can extend a losing vote. Together they hand a measurable advantage to whoever votes last.
A holder who votes early reveals their weight and their direction to everyone who votes after them. A holder who votes late sees the whole distribution and reveals nothing anyone can still act on. The advantage is not an exploit and needs no privileged access – it is simply the shape of a public auction with a hard close, and it grows with the concentration of the electorate, because the fewer addresses can move the outcome, the more of it one late address captures.
It is sharpest against a proposal that appears to be losing. A minority that expects to be outvoted has an incentive to let the tally read Defeated for most of the period – which also suppresses turnout among opponents, since a proposal that is clearly failing is not worth the gas to oppose (voter apathy is a resource here, not only a complaint) – and then to vote its whole position at once, too close to the close for the newly-motivated opposition to organise.
The canonical case. In July 2024 a group calling itself the Golden Boys put Proposal 289, Trust Setup for DAO investment into GoldCOMP, to Compound's Governor Bravo: 499,000 COMP of the DAO's reserves – about $24 million at the time – into a vault the proposers would influence. Tally's record of the on-chain vote is 682.19K COMP for, 633.64K against, 5.24 abstaining, and the proposal's final state is Canceled: it was never executed.
The timing is what makes it a case rather than an anecdote. Governor Bravo's own vote log shows 82% of the support, about 564,000 of the 682,191 COMP cast for it, arriving in the final 34 minutes before the vote closed at 17:45 UTC on 28 July 2024. It came in 20 votes, the largest about 60,000 COMP at 27 minutes out and the last at 8 minutes out, and CryptoSlate's reconstruction gives the same share. Nothing was exploited; Governor Bravo did exactly what it is written to do. The proposal passed, and then the proposers agreed to rescind it in exchange for a negotiated staking product.
That resolution is the part worth reading twice. The rules produced an outcome the DAO did not want, and what reversed it was not the rules but a negotiation conducted off-chain under reputational pressure, by people with no formal standing to conduct it. A governance system whose last line of defence is that the winner can be talked out of winning does not have a last line of defence. Compound's own directory entry covers the capture side of the episode – see Compound DAO.
The design responses differ less in what they do than in what event they watch for, and that difference decides which swings they catch.
OpenZeppelin ships this as GovernorPreventLateQuorum, a Governor module that pushes a proposal's deadline back so that a set amount of time always remains after quorum is first reached – the contract's own stated purpose is to stop "a large voter from swaying a vote and triggering quorum at the last minute, by ensuring there is always time for other voters to react". The parameter is lateQuorumVoteExtension and governance itself can change it. Its documented limit is precise and easy to miss: the module "only reacts to the first time a proposal reaches quorum", so a swing that happens once quorum is already comfortably met – a for-versus-against reversal rather than a quorum event – extends nothing.
Nouns DAO V3 keys on the outcome instead. Its specification defines a lastMinuteWindow at the end of the voting period: if a proposal is Defeated inside that window and a For vote flips it to Successful, an objection period opens, during which accounts that have already voted cannot vote and accounts that have not may only vote Against. Both lengths are contract parameters – lastMinuteWindowInBlocks and objectionPeriodDurationInBlocks. It is a narrower instrument than a deadline extension and a more exact one: it fires on precisely the manoeuvre it is named for, and the asymmetric ballot means the extra time cannot be used to widen the winning margin.
Conviction voting removes the deadline rather than defending it: support accrues weight the longer it is held, so a position taken minutes before a close carries almost none. It is the only one of the four that makes the late vote structurally weak instead of procedurally awkward – and it pays for that by making every decision slower, including the ones nobody contests.
Governance timelocks do not touch the vote at all; they separate passing from executing, so a surprising result is visible before it is irreversible. A timelock alone only relocates the problem – it buys time for a response that still has to come from somewhere – which is why it is usually paired with a guardian or security council that can cancel within the delay. That pairing is the trade the 289 episode pushed the industry toward, and it is a real trade: the DAO gets a stop button, and someone has to hold it.
All four remedies are defences of the process. Each extends the window in which the electorate can respond, and each assumes a response is available – that opponents can be mustered, that a guardian will act, that waiting is affordable. None of them changes what happens to a holder who loses the vote on the merits and wants no part of the result.
That holder's only exit is the market: sell the governance token into whatever bid exists, at a price that already reflects the decision they are trying to escape. It is the worst moment to be selling, which is exactly why the threat of it disciplines nothing. A governance system can be perfectly defended against late-vote swings and still offer a dissenting minority nothing but the door, priced by the people walking through it.
A caper splits the decision in two, so that winning the ballot is not the same as getting the money. The ranked vote is legislative: it decides what the caper wants, and the contract will not proceed without it (trigger_proposal refuses anything that has not passed its tally). What it does not do is execute. A passed proposal then has to be triggered, which opens a market window, and resolution compares the curve's time-weighted average price across that window against the baseline recorded when the window opened. Only if the market holds does the proposal become executable.
A swing in the closing seconds of the ballot therefore buys its author the first phase and nothing else. The second phase has no ballot to snipe: it is priced continuously by everyone holding the token, it starts after the tally is known rather than before, and a tie ratifies – holding is consent. And a holder who dislikes the result does not have to sell into that window: the exit right redeems a share of the treasury sized by their own weight, at treasury value rather than at market. The mechanics are set out on voting and proposals; the window length and the ballot period are fields on the deployed component, and the FAQ explains how to read them off the ledger.
GovernorPreventLateQuorum – the deadline-extension module, and its own note on what it does not catch.NounsDAOInterfaces.sol – lastMinuteWindowInBlocks and objectionPeriodDurationInBlocks as deployed.