W3F voted AYE despite the proposal apparently not satisfying one of its published minimum standards

Referendum 1913 does not appear to meet point 6 of W3F’s published voting guidelines.

According to the guidelines, proposals should generally have at least 14 days of public community discussion before being submitted as a referendum:

Public discussion lead-time: Generally, at least 14 days of community discussion before referendum submissions.

From what I can see, Referendum 1913 was submitted without meeting this discussion period.

If W3F voted AYE despite this guideline not being satisfied, could W3F explain why an exception was made in this case?

W3F voting guidelines:

https://medium.com/web3foundation/w3f-opengov-proposal-voting-guidelines-543ff7faba03

Thank you for surfacing this, @dandan.

The wording is worth quoting directly.

The section is titled “Minimum Standards for All Proposals,” and W3F says proposals “must meet the following standards” to earn an Aye. Point 6 is the 14-day public discussion lead-time. So this is not a vote versus an outside opinion, it is two W3F documents in tension: a published standard that says “must,” and a vote that appears not to meet it, three weeks after it was published.

To be fair, point 6 says “generally,” and #1913 is continued maintenance, not a fresh proposal. An exception may well be reasonable. That is exactly why the question is the right one, so I would sharpen it:

  1. What qualified #1913 for an exception to a standard labelled “minimum” and “must”?
  2. Who decides when an exception applies, and against what written criteria?
  3. Where are those criteria published, so the community knows in advance when the 14-day rule actually binds?

A minimum standard that can be waived case by case, by the largest voting entity, without published criteria, is not really a standard. A clear public answer settles it either way: if there was a good reason, naming it costs nothing.

There were 12 days of discussion. The proposal was posted here: Continued Integration & Maintenance of Polkadot in the Chainflip Protocol Twelve days versus fourteen days is, I believe, within the bounds of the spirit of this guideline (which are, after all, “guidelines”). I’d also note that in your quote for this specific guidelines, it says “generally”.

Additionally, this article was published not three weeks ago, but last year. There have been numerous changes since then and we should update the article. Thank you for bringing this to our attention.

I genuinely don’t understand why we’re still funding Chainflip.

It supports swaps across Ethereum, Solana, Bitcoin and many other ecosystems, yet Polkadot barely seems to matter to them. Just look at their website: DOT has a tiny presence compared to other assets, and even in the footer Polkadot is listed last.

So why are DOT holders paying for this?

What exactly have we gained in return?
How much liquidity has actually been brought into the Polkadot ecosystem?
How many new users has it attracted?
What is the measurable ROI for the treasury?

From where I stand, it looks like we’re financing infrastructure that benefits everyone except Polkadot.

At some point, we need to stop funding projects simply because they’re built with Substrate and start asking whether they actually create value for the ecosystem that’s paying the bill.

Looking at Chainflip’s transaction volume by trading pairs across the ecosystem, it’s genuinely difficult to find meaningful activity involving Polkadot itself.

Why are we funding initiatives that fail to generate measurable on-chain activity, liquidity, or user engagement for DOT and the broader ecosystem?