… It is becoming increasingly clear to me that the treasury system is being abused.
There is just too little accountability once users are already paid for their work, for the results to be lazy, low quality, or have little to no impact.
Assessing work winds up really tricky too. Ideally, you solve this by giving grants only when you really believe the grant recipient wants to do the work anyways, and is qualified.
We do need proactive payments for established non-blockchain organizations:
Academics – We almost always keep these grants small though. $100k or less should cover 1 year of 1 postdoc or PhD student in Europe. US overhead rates are sky high, so imho no grants for them unless the fit is really perfect. I think the overhead rate at MIT was like 60%, aka only 40% of the money you give them goes for the actual project.
Established non-blockchain open source projects ala Tor, Rust, etc – You know exactly where their priorities lie, so basically zero risk. Some like Mozilla have high overhead, but I think most are lean operations.
I think the cultural fiscalization of blockchains makes everything harder, so yeah maybe payment-on-delivery makes sense whenever recipients have monetization plans, like by launching a parachain.
It’s also always payment-on-polkadot-relevant-delivery here, like if they pivot mid project and deliver something in solidity instead of rust, so they can deploy on ETH, then obviously we do not pay them.
All the above speaks about code, afaik almost all advertising or publicity funding is inherently wasted, but… Yeah your matching funds idea sounds better than any other proposal I’ve heard. It’s far harder to cheat google than to the treasury.
Delegating funds to specialist, proven groups seems eminently sensible as a general approach.
This seems particularly relevant in light of the work emerging around RISC-V and compilers.
I believe some blockchain focused funding would be well spent if delegated to the W3F (Disclosure: I am a current W3F grant recipient).
May need to be cautious about W3F insiders that are DOT holders - but conflicts of interest around treasury voting will have to be addressed at some point. Is now too early?
One aspect I also see as important is “temperate checks”. Before actual voting happens, it is incredibly helpful for the community to arrive at a consensus by voting on different questions without attaching an outcome to it.
E.g performing a temperature check on a rough outline of the proposal highlights if one should move forward with formulating it. Temperature-checking sub-questions help the discussion move forward.
This not only applies to treasury votes but to any governance action.
I like this idea a lot. So far, in some instances, Discussions have served as ad hoc “temperature checks,” in some cases leading to significant changes in proposals, but maybe formalizing that process could be more effective (and less opaque to new proponents/less-engaged voters).
imo we should begin and end polkadot on/off chain governance in this forum.
we should move things from:
high level discussions →
argument, debate →
signalling →
then into proposals →
into on-chain actions →
this makes the most sense from a user experience perspective, rather than moving people to another site.
this is the approach I’m taking from here on, we won’t use other governance forums including why we’re pushing towards substrate logins. Add DOT address login to forum
we will also be levelling up media and production and hosting that content here, not on youtube.
@ChrawnnaCorp would be brilliant if you hosted AAG live from the polkadot/kusama forum through a fully integrated discussion / chat experience.
I was wondering if it would make sense for projects that require higher amount of funding to have a certain minimum vote participation (%) rate. The idea is to counter voter apathy or low turn-out that may allow projects to be funded only because token holders were just not paying enough attention (and some projects go through because of tiny majority vote). So there could be different buckets:
If ask is $xyz then there needs to be a minimum xyz % of voters voting (showing interest in the project) otherwise its automatic fail.
There could be different %'s required for different size buckets?