Instead of channeling a given amount of funds per block to dev teams, do the following:
Define a set of milestones that are expected to be achieved, assign a price for each milestone and extract that amount of value as a tax on a single block once, and only if, the milestone is reached and delivered by the dev team.
This way the community will not bear any risk, and will be customers instead of funders. Customers are usually less gruntier than funders.
If dev teams need the funds now, then sell the rights to part or all of these future payments to investors that are willing to bear the risk, and who will also push developers to deliver.
Maybe this way the community will feel more comfortable paying the tax.
Note: for milestones that require a network update/fork, the deliverable is the new network. Users can even decide to stay in the legacy (less performant) network if they don’t want to pay the tax. For clients and wallets that is not the case.
I like this idea but it kinda moves the problem to defining milestones and deciding whether they’ve been met. It might be possible to mitigate those issues
Welcome to the forums
I think this is covered by @acityinohio’s proposal which seems to have the same mechanism, but rather than milestones it is features, I think.
But I see no reason why the features cannot be broken down into milestones. It might even bolster the proposal.
See the “shielded option metric” and the “what happens in case of a violation”.
Is that the sort of thing? because milestones would certainly help in the case of a violation.
And for a bit more of an explicit example
Is this more like what you were imagining? - I have pointed out before that Ethereum has much better potential to do this on chain. I think really the ECC would have to say if this model fits their development style and requirements. (milestones can be bad in some situations and development structures.)
In that case, this post can be archived. I simply support that proposal.