# Bounty Compliance Standards 1.0

This document lays out standards which shall apply to all bounties funded through Polkadot OpenGov. The basic intention is to ensure that minimum standards are upheld before a budget is granted. It defines how these executive bodies should handle budgeting, transparency, and compliance.

## 1. Bounty Objectives

1. Bounties shall have a clearly defined list of objectives by which their success can be judged by the community.
2. Funds may only spent within the boundaries of the objectives for which the funds were requested.

## 2. Funding

1. Bounties may request funding at a maximum of one time per quarter.
2. Funding requests must include
a. Budget breakdown: The budget has to give an honest picture of the intended spending and be broken down into positions. Positions should be explained in sufficient detail.
b. Timeframe: The timeframe should give clarity to OpenGov when it can expect the next funding request.
c. Transparency reports that cover past activities up to the time of the request.
3. A funding request has to be put up for discussion in any of the established governance platforms or the Polkadot forum for at least 2 weeks before it is put to a vote.

## 3. Curators

1. All curators must have a verified on-chain identity.
2. Payment terms of curators must be outlined in the funding request. If curators shall receive payment, including for prior work, it has to be defined in the payment terms.
3. Curators may not sign payments for work that they have executed, except curator compensation.
4. Curators must not claim compensation for work that they already have been compensated for otherwise.
5. Curators have to publicly declare and document any conflicts of interest that come up during their duty.
6. Curators have to publicly report any misbehavior or other issues that conflict with the effective and efficient operation of the bounty.

## 4. Recipients

1. All recipients must have a verified on-chain identity.
2. Recipients must not claim compensation for work that they already have been compensated for otherwise.

## 5. Transparency

Bounties are required to provide the following materials for transparency:

1. Official public communication channel where curators are regularly available and the public can participate
2. Regularly updated official overview page
a. Objectives
b. Main contact point
c. Link to the public communication channel
d. A list of all current curators
e. Links to all progress summaries and all other transparency materials listed below
f. Links to relevant documentation
g. Link to current child bounties
h. Guidance for executors on how to participate in the bounty
3. Spending Policy, including how curators are compensated
4. A table of child bounties that contains: status, name, description, amount, beneficiary username, beneficiary address, links to evidence. The table is available in an open format (XLSX, CSV, or similar)
5. Monthly progress summary posted to the bounty page, signed off by at least one curator
a. Current status of projects
b. Current bounty balance
c. Current plans
d. Notable changes to objectives, curation team, operations, etc.
6. Quarterly financial statement
a. Balance
b. Income and Expenses
c. Summary of curator payments
d. Summary of payments by recipient
e. available in an open format (XLSX, CSV or similar)

# Appendix
These are additional questions we have received and considerations we have discussed. They are not included in the on-chain proposal (to keep the proposal minimal) and are intended to help you interpret the intention of the proposal.

## Bounty Objectives

### Would a strategy be considered the defined objectives?
A strategy is much bigger. Objectives are the first part of a strategy. So yes, a proper strategy contains objectives. However, a list of objectives doesn't yet make a strategy.

### Shouldn't a bounty be able to change its objectives?
Yes. Bounties need to be able to adapt to changing circumstances. However, if a bounty promises to do work to achieve a certain goal it should not take the granted money and do something different with it. If it wants to change what the money is designated for, it should have to request a change.

Likewise, it is easy for a bounty to change the objectives for future funding, because it is submitting a funding request anyways. In the context of requesting new funding, it can also communicate changed objectives.

### Should there be success metrics?
In general it would be very helpful to measure against hard metrics. The problem is that it is really hard to arrive at reasonable metrics and very often people come up with bad metrics just so that they can provide KPIs. We have chosen to not include a requirement for metrics yet, because the ecosystem as a whole is not yet mature enough to have agreed on the right metrics. A good first step is to start finding the metrics that make sense before prescribing that metrics have to be used.

### Should a bounty end date be defined?
In the past, OpenGov has shown to just close bounties when they stopped performing. We don't think this has to be explicitely defined.

## Funding

### Will bounties be denied funding if they don't follow the rules outlined in this document?
It is still up to OpenGov, but the idea is that OpenGov shall question bounties that do not provide these things. We suggest OpenGov denies funding requests if proper scoping and transparency criteria are not fulfilled.

### Why should a funding request contain a budget breakdown with specific details? Aren't the details already provided with the objectives?

The objectives long-term and generic in nature. The quarterly budget is focused on specific projects. It might touch only some of the objectives or with different priorities. It is more specific. The idea is to communicate specific plans for how the money is used, not some general ambitions.

## Transparency

### Summary and Details

There are 2 parts to transparency: summary and details

- **For the casual observer, getting a quick overview summary is important.** For them, the answer cannot be that they can "look it up in a table, drive folder, meeting notes, or on-chain". Casual observers are the majority of the participants. For the casual observer, short summaries are important. Auditors need summaries to save time.
- **For the transparency nerd, detail is important.** For them (and auditors), being able to verify all the claims given in summaries is crucial. Bonus points if it is structured data to allow automation to take place.

When we talk about transparency, both aspects are needed: summary and details

### But transparency creates extra work

Yes, dealing with other peoples money requires making it transparent what you did with the money.

### Simple and short is fine

You don't need a dedicated website. Updating the description on the bounty pages in governance explorers like Subsquare/Polkassembly is very much fine. It even helps casual observers find your information quickly.

The same is true for summaries, reports, etc. Keep them short and simple and save everyone time.

### Overview Page

The overview page can be a the Subsquare/Polkassembly page, a dedicated website, Notion page or similar. See examples below:

Events Bounty
- Linktree: https://linktr.ee/dotevents_
- Website: https://dotevents.xyz/

UX Bounty:
- Notion Page: https://braille-wtf.notion.site/UX-Bounty-Homepage-WIP-167a1782242e477bbb9f7a066ef447dd

### Quarterly Financial Statements
Financial statements should provide detailed explanations and metrics of bounty operations. See examples below:

Events Bounty
- https://docs.google.com/document/d/1Y8DuYnXpNuGJYALjJSUJ83ogJypWoOrL2df1_6XTfYc/edit?tab=t.0#heading=h.tv09ho3qoge

PAL
- https://github.com/polkadot-assurance-legion/pal-docs/blob/main/community-reports/pal-24h1.md

### Monthly summaries
Summaries can be short bullet point summaries that gives the general idea of progress for public oversight, they dont have to be as detailed as quarterly reports.

## Open Questions

- Link to child bounties - link to Subsquare or better
- payments per hour and when to start and when to end etc...
- jobs, getting a task/contract but then the bounty changes
- conflict of interest examples

# Bounty Compliance Standards 1.1

## 4. Recipients
3. Recipients must place "funded by Polkadot" on any publicly visible artifacts

## whatever
- bounties may not trade to other cryptos. they can liquidate to stables once, but not trade back and forth
- accountants must not be the same person that does accounting for a supplier

- Invoices, full name and address