Sniping a proposal during Confirmation Period

Governance
,
1

**

Sudden Death at its worst …

**
It’s an open secret in OpenGov: If you really want to kill a proposal, the smartest move is to wait until the confirmation period - after 28 days of debate, feedback, and discussion. All it takes is a slight edge in No votes, and boom - the proposal is instantly dead.

No warning, no second chance….

That’s exactly what happened to us. Our PolkaBiz proposal (ref 1504) was sniped with just a 0.1% margin. We had no time to react - classic sudden death.
And this, despite overwhelming support: praise from the Web3 Foundation, endorsement from the Polkadot Blockchain Academy, glowing feedback from dozens of startups we’ve helped, and strong comments from key ecosystem leaders. All wiped away in an instant.

The reason?

We don’t know.
Because, of course, a sniper never leaves an explanation.

And that’s exactly where the problem lies.

As a founding member of Permanence DAO, I’ve always advocated for one simple principle:
“Whether you vote Yes or No - give feedback.”

Feedback is what elevates the quality of proposals.
Feedback is what helps us grow as a community.
Feedback is how we all get better - together.
But sniping in silence destroys all of that.

Are we heading towards a culture where meaningful feedback dies out - where even community-serving projects get taken down silently by a handful of large wallets at the very end?

That’s not governance. That’s not decentralization. That’s short-sighted gatekeeping.

Let’s face it - sudden death might be fun in a battlefield, but that’s not why we’re here.
We’re here to make the ecosystem stronger.

It’s time we step out of that immature “hide-and-snipe” phase and act like builders - face each other, discuss openly, and improve together. It’s time to grow-up !

A proposal stays on-chain for 28 days - that is more than enough time to voice concerns.
If we can’t openly say what’s wrong, we will never grow up as a community.

So, here’s my proposal :

Let’s disable conviction voting during the confirmation period. Or better yet - let’s abolish sudden death altogether.

Here’s what that would mean:
During the confirmation period, voters can still express support or opposition - but only with 1 DOT = 1 vote. No conviction multipliers. No boosted power.
And if someone decides to change their vote during confirmation, they would lose any conviction multiplier they had earlier.

Will this completely eliminate sniping?
No.

But it will make it significantly harder to game the system with last-minute power plays.
It forces all of us to engage earlier, debate openly, and make our voices heard when it actually matters - not just when it’s too late for anyone to respond.

If we want OpenGov to work, we need more transparency, not more ambushes or last-minute shadow tactics.

Mario Schraepen

6 Likes
2

As somebody who had a proposal sniped two out of three times (with no explanation), I support this proposal. Will ending to conviction voting during confirmation make sniping impossible. As Mario said, of course not. But it’s a good idea to launch a debate around this issue.

4 Likes
3

In the broadest sense, I’m fine with sniping. But I understand it’s very frustrating for proposers, so if we can find an elegant way to get rid of it, I would support it.

3 additional ideas to map out the solution space:

  1. in the confirmation period, stepwise reduce the conviction options from 6 to 1
  2. instead of removing conviction options, introduce candle auctions for the confirmation period → forces earlier voting, adds the drama and excitement of parachain auctions
  3. Alternatively, when the confirmation period begins, start counting the votes every hour and add them to a counter. The accumulated counters at the end of the confirmation period represent the result

Options 2 and 3 would mean that there is no going back to decision period if the proposal fails in confirmation

4 Likes
4

I’m in strong agreement with the aim of this proposal.

Unfortunately, I don’t think we can eliminate bad faith behaviour in voting - code is pretty much law in onchain governance and however detailed a solution we design, there will be some way to game it to gain some advantage against the spirit of the design.
As such, I think the exact mechanics as proposed may lead to other (probably smaller, though) negative effects.

In general, tapers, as @alice_und_bob suggests, are the best simple way to reduce negative effects resulting from a new ‘cliff’
However since we are discussing the confirmation period, not the main voting period, the only rights that voters would lose are those that, arguably, it was not envisioned they should be given in the first place.

So, from me, yes let’s, but I would like to see this implemented with steps/ tapers.

Also: norms for voters
and: watch this space for my proposal for squidsway - a framework to reduce information asymmetry and improve the expereince of both voters and proposers.

1 Like