Why Dev Fund proposals fail, measured from the repository

Disclosure first: proposal #860 is mine, and no vote has ever been opened on it. Every number below comes from a tool anyone can run.

I went looking for why some proposals sit still and found something more useful than I expected.

Seven votes have failed. Six recorded no vote against at all. They ran out of their 21 days while the eligible voters did not vote. The threshold is 51% of allowed voters rather than of votes cast, so an absence counts exactly like a no.

Four of those seven were reopened within days of expiring. #813 the same day, #866 and #453 on 9 November, and #577 on 10 November. So a failed vote is a restarted clock, not a verdict, and reading your own failure as a rejection of the work is probably wrong.

All seven were opened within ninety seconds of each other on 16 October, so all seven expired on the same day. One batch, not seven decisions.

One thing for anyone measuring this themselves: the repository’s labels show three failures, not seven. A reopened vote has its label reset too, so the first failure stops being visible. My own tool counted that way and was wrong by four until I checked the vote comments instead.

Working, tools, and every figure:

Two things I could not establish and would value an answer on. Is there a published calendar for the voting sittings? And when a vote expires unvoted, what triggers it being reopened?

A proposal’s progress depends on the champion, and if they have one in the first place.
Do you have a champion for your proposal?? If yes then they have to make sure the proposal is under vote.

You can learn the proper process at Canton LocalNet Guide