OG Rust Bounties

Proponent: cl0w

Date: 10.01.2025

Requested DOT: 250,000 DOT

Summary

This is a proposal to allocate 250,000 DOT for the creation of the OG Rust Bounties - a bounty designed to incentivize Rust engineers to carry out developer tasks that have been requested under OpenGov, or by some reputable authority such as the Fellowship. The tasks should relate to the Polkadot relay chain or any of its System Chains and target code changes to Polkadot-SDK or to some of the Runtimes (Polkadot Relay Chan and its System Chains). The bounty is curated by 5 curators who both a) possess technical knowledge of Substrate, and b) are active participants in the Polkadot ecosystem and mindful of its needs.

Curators

Valery Gantchev / cl0w - founder of the Polkadot Assurance Legion (PAL), contributor to Hydration and Rust engineer with 19 years coding experience;
Jakub Panik - CTO of Galactic Council, contributor to Hydration and Rust engineer;
Bastian Köcher - a guy at Parity working on Polkadot since 2018 using Rust. Fellowship member. Developed Cumulus and some stuff around.
Donal Murray - Parity core dev, System Parachains lead and fellowship member
Curator #5 - TBD (reach out if you think you are a fit)

Problem statement

This proposal addresses the need to set up a framework of incentives and procedures which enables external (non-fellowship) developers to engage in Rust engineering tasks relating to the Polkadot Protocol. This should help ease up the growing backlog of tasks that have been requested by OpenGov or some other legitimate authority such as the Fellowship.

Over the past months, the community has requested several features using the Wish for Change (WFC) track – see for example Ref #712 regarding the implementation of optimistic project funding. While the involvement of the community in the Polkadot roadmap should be welcomed as a form of decentralization, the implementation of such requests poses challenges. More specifically, it is not clear who would be responsible for carrying out the work, and how this would be incentivized.

The Technical Fellowship does have the expertise to carry out the required work, however their capacity is constrained by limited resources and a set of concurrent tasks they are working on. In a related development, the Fellowship also sees the need to outsource some of its tasks. Also here, there is no clear mechanism for incentivizing and managing the contributions.

Proposed Solution

OG Rust Bounties aims to open up the implementation of technical tasks requested under OpenGov or by the Fellowship to anyone with the required technical skills (e.g. PBA graduates or other Rust engineers). As the social consensus on the feature has already been reached, the developers will not need to undergo the whole OpenGov process again, or look for other complicated routes to fund their work. Instead, they can focus on a technical proposal for the implementation of the feature which should be reviewed based on its technical merits.

To foster competition, OpenGov Bounties work on the basis of Calls for Proposals. After the feature/change is requested by a reputable authority, the curators will publish a Call for Proposals which allows anyone to submit their proposal for implementing the task. After the submission deadline has closed, the curators will evaluate all submissions and pick the preferred supplier based on the following criteria:

Applicants should lay out in sufficient detail how the task will be implemented;
Complex tasks should be accompanied by a technical RFC;
Tasks that require longer than 2 weeks to be implemented should be split into verifiable milestones;
The preparation of an RFC can be carried out as the first milestone of the project and funded;
The proposal must contain a description of the applicant and their track record;
The proposal must specify how many FTEs the applicant will be dedicating to the task in question;
The proposal must specify timelines for the delivery of every milestone.

Curators

The bounty will be managed by 5 curators who satisfy both of the following criteria: a) possess technical knowledge of Substrate, and b) are active participants in the Polkadot ecosystem and mindful of its needs.

The responsibilities of the curators include:

Collect the requested tasks and initiate the relevant Calls for Proposals;
Review the submitted proposals. This includes a feasibility assessment based on the submitted RFC and on the track record of the applicants;
Award the task to the best proposal, which is a subjective judgment informed by the quality of the submissions and their execution price;
Prepare quarterly community reports which outline the activities of the bounty and contribute to transparency.

To fulfill these responsibilities, curators should be able to dedicate at least 0.2 FTE. For fellowship members, work on this bounty will be accounted towards their fellowship duties and financed through their fellowship salaries. Curators who are not part of the Fellowship will be incentivized by a monthly remuneration of $ 3,000 (paid out in DOT).

Thanks for the bounty description.

We would like to have a concrete time set for future refills and a time frame for fund use. This requirement is now is also a part of the bounty compliance standard set by referendum 1254. Paragraph 2 section 2
https://polkadot.subsquare.io/referenda/1254
so early refills are discouraged at this point, attempting to comply with the requested amounts at the previously announced dates is encouraged. In short, announcing a spend period is now required in order to avoid early refills or surprise refills. Also, to help with budgeting in the future. In addition we also would like to add that a setting a spending time also makes it hard for bounties to become abandoned or too reactive to external factors as we've seen with bounty 39 and 27 (for now). Regardless of that, a time frame set with a range should also work but never has been attempted before. Other variations of an announced time frame should work too as long as they are reasonable time frames (so nothing vague like: "from 1 month to 100 years").
The deplete and request approach or fund and wait approach for bounties is something we really dislike as it has proven to be a detrimental approach for the treasury on previous bounties. So we really would like to see a refill or use determined by this bounty and all bounties from now on.

Also, make sure to abide by the Paragraph 5 which now requires an additional work by bounties such as opening communication channels, points of contact and present summaries a quarterly financial report, monthly progress summary along with other expected or unexpected changes in the bounty starting from approval time. So these items should be required in addition to or instead of the 6 month community report proposed by this bounty.