Polkadot is not a castle in the sky. It builds upon, and uses other countless open source projects developed and maintained by other open source developers. Those upstream open source projects make Polkadot possible, and as a result, it is important that we support them.
This article is a proposal for a set of bounties and treasury spending proposals aiming at using Polkadot treasury for upstream projects.
Many of the upstream projects are not involved in Polkadot directly, and thus there is a significant barrier for them to apply for Polkadot spending. Thus we propose a treasury proposing fee bounty for upstream, a bounty system that covers the initial treasury proposing fee, if upstream projects wish to apply for treasury fundings.
The Rust Polkadot codebase has many direct dependencies. Some of them are not developed or maintained by the current core development teams. Thus we propose a direct dependency maintenance bounty that proposes a fixed amount (decided by Polkadot democracy system) for upstream developers to claim. It’s probably not possible to reach out to all upstream developers, and any unclaimed funds at the end of the period is returned to treasury.
The current Polkadot codebase heavily depends on the Rust programming language, the LLVM project, the GNU toolchains and the Linux operating system. All of those are open source projects. Thus we propose several upstream toolchain sponsorship proposals that aims at bringing the Polkadot governance DAO as sponsors for those projects.
The Rust codebase is not the only codebase available for Polkadot. Other core development teams exist as well. Thus it is possible to propose similar treasury proposals for upstream for them.
Outside of the codebase, Polkadot users also heavily rely on many decentralized and open source project to make their normal rountines work. For example, the Firefox open source browser, the Matrix chat platform, the GNUPG project, and others. Thus we propose several upstream ecosystem project sponsorship proposals for them.
The list above listed here is definitely incomplete and more will be added in the future.
This article is a proposal. It does not necessarily represent the viewpoint of Polkadot council members. The author currently supports this proposal. It is currently written for directional explorations and further discussions.
Treasury proposing fee bounty for upstream
Many (or most) upstream projects mentioned here, while important to Polkadot ecosystem, are not directly involved in Polkadot. The treasury proposing fee bounty aims at covering the proposing fees for them if some of them wishes to submit proposals on Polkadot themselves.
The bounty is submitted quarterly and its amount depends on the previous usages. Non-used funds are returned back to the treasury. Curator is to be decided.
We estimate that this amount may not be high, and might be around USD 10k to 50k equivalent annually.
Direct dependency maintenance bounty
Some dependencies in the Rust codebase are not maintained by the core development teams. The direct dependency maintenance bounty aims are providing all such direct dependencies some sponsorship.
The bounty is submitted annually. It is unfortunately not possible to directly contact maintainers in some situations, thus it will require them to claim the funds, which can be done any time during the year. Non-claimed funds are returned back to the treasury. Curator is to be decided.
The estimated number of authors is around 200, and the proposal plans to send each author 500 DOTs annually, for a total estimation of 100000 DOTs.
There will be a single bounty proposal for the dependency maintenance bounty, for a number of 100000 DOTs.
Due to how Polkadot’s bounty system works, as annual bounty, a new bounty proposal will be submitted each year. This also enables extra scrutiny and allows process change of the bounty to happen easily.
Child bounty system
The bounty relies on the child bounty system in Polkadot runtime to function. It, however, is not yet activated. To actually send out bounties, we have to wait for that system in place.
On the other hand, work will be started to contact authors as soon as the bounty is approved.
Contact dependency authors
As soon as the bounty is approved by council, work on contacting authors will be started. We will ask authors to provide a DOT address and also instruct them on how to claim the child bounties. In addition, the following information will be provided or asked:
- The bounty details, of 500 DOTs for each individual authors.
- Dependencies related to the author.
- Whether the authors have additional primary maintainers they want to add. It’ll be noted that rewards will not be “splitted”, but instead “added up”.
- The possibility to receive higher rewards in the second year’s dependency bounty, as we pay those “more important dependencies” or “developers in need” more, subject to council reviews.
- The bounty is to show Polkadot community’s appreciation for the dependency authors’ work. There are no strings attached. The reason why we cannot send them USD right now is because we don’t yet have a legal structure available to manage the funds for them. This, however, can be improved in the future.
For privacy reasons, part of the information will be shared with council members only. An additional process should be established to allow community members to request or confirm information in the spreadsheet, without damaging dependency authors’ privacy. On the other hand, we plan to publish as much information as possible to the public for transparency purposes.
The current bounty does not contain much subjectivity, and thus it in thoery works already safe in a single curator setup. We’re, however, looking for additional co-curators to help in this cause. If you are interested, please get in touch with Wei.
The bounty will then be paid out using child bounty system. A possible issue in this case is that the bounty system sill requires the receiver to manually claim the funds. For extreme cases of authors who can’t pay for the transaction fees, we’ll propose small amount of tips directly to the authors’ accounts.
Upstream toolchain sponsorship proposals
Those upstream toolchains are what is actually compiling and running Polkadot codebases and nodes. The current proposal in this article is to bring around 100k USD equivalent sponsorship to the foundations behind those project, thus bringing the Polkadot DAO usually to the highest sponsorship tiers in those foundations.
The current shortlist includes the following. Note that this is still subject to change and other projects might be added.
- Rust Foundation, the Rust programming language.
- LLVM Foundation, the LLVM project and the Clang project.
- FSF Foundation, the GNU toolchain.
- Linux Foundation, the Linux kernel.
It thus estimates to around 400k USD equivalent for this proposal annually.
Upstream ecosystem project sponsorship proposals
Those include ecosystem project that Polkadot users depend on. The current shortlist includes the following. Note that this is still subject to change and other projects might be added.
- Mozilla Foundation, the Firefox open source browser.
- Matrix.org Foundation, the Matrix chat platform and the Element frontend.
- GNUPG project. Unfortunately it is not currently certain whether direct sponsorship is possible for it.
It thus estimates to around 300k USD equivalent for this proposal annually.
The current proposal plans to send out 7500 DOTs to each of the eligible foundations. Each sponsorship proposal will be submitted individually, and consultation with community and council will be done first.
Because a bounty can be retracted by council, we don’t ask for the sponsoree’s feedback before submitting the proposal, but only after bounty has been approved by the council. In this way, we can be sure that the Polkadot community supports sending out the bounty rewards before we start talking with the sponsorees.
Currently, we require sponsorees to claim the bounty rewards on the Polkadot blockchain themselves. If the sponsoree cannot do it, then we either let the bounty to expire or retract it, until we figure out a better process.