With the adoption of OpenGov, we have created and followed certain guidelines that have helped us make our decision regarding funding on Polkadot and Kusama. This is NOT a document aimed at becoming a large sets of strict rules for the whole community through social contract and to dictate how they make their decisions. It simply contains some guidelines we thought are important and we abide by them to the extent that it’s possible. Meaning, it’s a subjective assessment which we use and participants of Polkadot’s governance and its parachains are free to adopt in order to make their own decisions.
This document only contains the most recent version on the website.
evolution of this document is visible on Github https://github.com/Saxemberg/GovernanceDocuments/blob/main/Guidelines.md until a proper decentralized Github replacement appears.
This document is always subject to change.
This document is open source so anyone is free to used it in any way they deem necessary, Find the license on: https://github.com/Saxemberg/GovernanceDocuments/blob/main/LICENSE
The bullet points are not ordered by importance. These items are numbered only to facilitate search when it’s quoted in the future.
1. On-chain IDs should be verified whenever possible. If it’s not possible, an effort to prove its identity on-chain using whatever methods is necessary. For instance: Proving web2 identities and reputations on parachains without the identity pallet or without registrars. The reason for this, is that a lack of a verified ID, makes it difficult for all proposals to prove on-chain and to people without first hand knowledge of the team, whether or not they are legitimate. Also, it perpetuates the risk of unknown malicious actors pretending to be other characters with a better reputation in future referendums.
2. There has to be a proper discussion and socialization of projects before the start of the referendum. Posting on Polkassembly/Subsquare and waiting for the agreed time is often not enough. An active socialization of your product or an attempt to do it prior the referendum, should be preferable. The amount of socialization effort, prior to the referendum should be directly correlated to the amount of money asked from the treasury. Similarly, all community questions, doubts, etc. preferably and for the most part, will have to be answered before the referendum starts or make an honest attempt to do it.
3. Engaging in honest conversation and socialization of proposals is a healthy approach, preferably done before the start of the referendum. Attempting to sway votes, specially at the end on the decision period on parties that might tip the balance is not. This type of behavior should be discouraged and honest attempts to discussion should be done before this critical period. Such behaviors should be considered risky and red flags.
4. Patching treasury referendums and its content after the start of the referendum should be kept to the minimum. Participants in OpenGov are not expected to follow the evolution and changes of the proposals after the time it has started. The work of making a properly explained referendum lays exclusively on the entity that is proposing the referendum and it should be laid out completely at the start of the referendum. Therefore, significant changes in the content on the proposal made after its start and during its voting period should be considered as a source of doubt and risk.
5. There has to be some kind of proof on how the funds are going to be spent or have been spent whenever applicable. Receipts, proforma documents, invoices, messages with blockchain signatures or any type of proof should be presented whenever applicable. These will serve as proof of where the funds and how they are going to be spent on a given item in their budget. Expenditures without details are acceptable, as long as they are kept to the minium possible and as long as they are not the most important items. For instance: a proposal for a conference without some proof of venue cost should not be acceptable.
6. Governance proposals that use AWS, Google Cloud and other big tech companies infrastructure or infrastructure that is anti Crypto like Hetzner should be discouraged. Distributing the treasury to big tech or crypto's opponents and relying on their infrastructure is a major flaw and it's not always the cheapest option. There has to be a solid ground on why picking a big tech infrastructure provider is the cheapest option. Arguments along the lines of: "big tech is the most convenient option for the developer(s)" should not be accepted as the main reason for using big tech or crypto's opponents. However, exceptions for consolidated and vital products could be granted to this guideline.
7. A progressive and increasing approach to funding should be adopted by entities seeking funding from the treasury. Meaning, that it’s preferable to start with small amounts, deliver and then move to larger amounts in order to build reputation. This specially applies for novel, experimental or undeveloped products. Alternatively, a structured, milestone based approach should be preferred for large and continuous projects. Specially applicable for products that have not been made its live debut on any of the mainnets.
8. Proposed products describing a way to economic self-sufficiency should be encouraged. Either as own profits, sponsorships, raising funds, etc. Products should, over time, become financially independent from the treasury. And they should not expect perpetual funding from the treasury in order to work. In a similar manner, funding products where they seemingly are on the brink of bankruptcy, discontinuance due to lack of funds, economic hardships should be examined even more thoughtfully as these will most likely continue to require funds from the treasury for prolonged times. In such cases, the importance of said product within the ecosystem should be considered as the main decision factor.
9. Funding products that will always remain closed source should be discouraged. Treasury funds should not be used to create products that will remain under the wraps of closed source code or restrictive licenses. The spirit of the funding should be for products, events and the community at large and not for just the companies revenue. The results of treasury funding should be open, visible and provable. The results cannot be stuck behind walls, paywalled or in private repositories either.
10. The purpose of the treasury should be fostering the Polkadot ecosystem and related projects’ success. Through, but not limited to, application development, software development, hardware development, community building events, liquidity provisioning, grants, fixing bugs or bounties for work done for such projects. The funds granted should have a clear and close connection to Polkadot, parachains and its ecosystem. So treasury funding for: “current geopolitical/economical events” outside the ecosystem should be heavily discouraged.
11. Entities in charge of the proposals should be able to send a final report with the results to governance through governance forums like Polkassembly or Subsquare and on all media possible. A report log with all the progress is also highly encouraged. For the sake of transparency, reporting results should be even more important than creating the proposals.
12. Asking funds for a third party increases the risk of non-delivery and of malicious proposals that will keep the funds for themselves. Therefore, increased diligence and audits should happen for proposals asking for third-party funds. More importantly, funds for third parties must have a solid proof of delivery and the requester a solid reputation. Whether as proof of delivering to a known address, any form of proof that has web2 / web3 links to the payment to the third party or the third party publicly acknowledging the delivery of the funds. For that reason, entities such as individuals, companies, foundations, DAOs, BORGs, autonomous AIs, asking for funds directly without intermediaries should take priority. PR agencies, marketing agencies, intermediaries of any kind, etc. that take a cut from the original proposal, should be discouraged. A single agency can singlehandedly flood the governance process with projects who have never head of Polkadot previously which is against the best interest of Polkadot. The native ecosystem agents with vested interests should be preferred over the ones seeking opportunistic funding.
13. Proposers should do their best effort to interact with all the good intended questions brought up by governance participants on the forums, specially if participants bring up important points. Proposers should not act as if they were above anyone’s reputation on OpenGov. Ignoring comments, ignoring remarks, attempts to reach proposers for comments and refusing to engage with governance forums and their participants should be viewed as a red flag.
14. The treasury should not fund the liquidity of memecoins, pump and dumps or airdrops. All these activities are very dangerous for users as they may fall prey of scams, malware, designed lose of funds and other pitfalls. The reputation of the Polkadot ecosystem and its linked entities will also decrease if such endeavors are funded by the treasury.
