nips/43.md

# NIP-43

## Bounties

`draft` `optional`

## Abstract

This NIP defines a standard for creating and providing solutions to bounties.

## Event Overview

1. **Bounty Event:** defined as a parameterized replaceable event of kind 30050. This event is published by the creator of the bounty.

2. **Bounty Application Event:** defined as a parameterized replaceable event of kind 30051. This event is published by a bounty applicant and MUST reference a **Bounty Event**.

## Bounty Event

_Describes some work that the creator is offering to pay someone to complete._

The `.content` of this SHOULD be a string text in Markdown syntax similar to [NIP-23](https://github.com/nostr-protocol/nips/blob/master/23.md#format). See the [complete state](#lifecycle-state-complete) in the **Bounty Lifecycle** section for details on the mutability-resistance of this field.

### Tags

The following tags MUST be present:

- A `title` tag to provide a title for the bounty.

- A `c` tag to specify the currency of the reward, for example: "BTC" or "USD". Fiat currency SHOULD conform to [ISO 4217](https://en.wikipedia.org/wiki/ISO_4217). For Bitcoin, use “BTC”. MUST be uppercase.

- A `reward` tag to specify a reward for the bounty. This is an array in the format `[ "reward", "<number>" ]`. Measured in the currency specified in the `c` tag. Denominated in whole units for fiat (i.e. for `c`=”USD”, 1=$1, 0.01=$0.01) and in sats for Bitcoin.

- A `d` tag to provide a unique identifier for the bounty.

- An `s` tag to communicate the current status of the bounty event. MUST be one of: `open`, `complete`, `withdrawn`.

The following tags MAY be present:

- An `image` tag to show an image along with the bounty.

- A `summary` tag to provide a short summary of the bounty.

- A `deadline` tag to provide a timestamp after which the bounty creator is no longer interested in receiving a solution. MUST be a stringified integer. Interpreted as a UNIX timestamp, in seconds.

- A `links` tag to provide links to external resources that provide more information about the bounty. This is an array where the first element is `links` and all subsequent elements are entries.

- An arbitrary amount of `t` tags that can be used as categories to filter bounties.

The following tags MUST be present when a bounty’s status (`s` tag) is `complete`:

- A `p` tag representing the public key of the user that provided the solution. See the `solution` tag below.

- An `a` tag to reference the **Bounty Application Event** accepted as the solution.

- A `solution` tag with the stringified **Bounty Application Event** signifying that it was chosen as the solution by the bounty creator.

The following tags MAY be present when the bounty is updated to `complete` status:

- A `zap_receipt` tag to reference the payment the bounty creator claims to have made to the creator of the accepted application.

## Bounty Application Event

_Describes the status of the work of an individual bounty applicant on a particular bounty._

The `.content` field SHOULD be updated with any relevant information regarding the solution of the bounty that the bounty applicant wishes to make public.

### Tags

The following tags MUST be present:

- A standard `a` tag to reference the **Bounty Event**.

- A `bounty` tag describing what the bounty applicant is applying to. MUST contain a stringified **Bounty Event**.

- An `s` tag to communicate the status of the bounty application event. MUST be one of: `applied`, `submitted`, `withdrawn`.

The following tags MAY be present:

- A `p` MAY be used to notify anyone that you have applied to this bounty.

## Bounty Lifecycle

The following is a description of the lifecycle of a [bounty event](#bounty-event):

1: **Open:** The bounty creator has not accepted any solution. This state is represented by an `s` tag of `open`. Bounties SHOULD begin in this state.

<a name="lifecycle-state-complete"></a>
2: **Complete:** The creator of the bounty has accepted a submission from a bounty applicant. This state is represented by an `s` tag of `complete`. The `.content` field of the **Bounty Event** MUST match the `content` field found in the `bounty` tag of the **Bounty Application Event** chosen as the solution. This “MUST” clause is to prevent the bounty creator from changing the description of the completed work after the bounty applicant has submitted their solution.

3: **Withdrawn:** The bounty has been withdrawn by the creator. This state is represented by an `s` tag of `withdrawn`.

## Bounty Application Lifecycle

The following is a description of the lifecycle of a [bounty application event](#bounty-application-event):

1: **Applied:** Communicates a user's interest in working on a bounty, making them a bounty applicant. This state is represented by an `s` tag of `applied`. Bounty Applications SHOULD begin in this state.

2: **Submitted:** A bounty applicant believes they have completed the work described in the bounty. This state is represented by an `s` tag of `submitted`.

3: **Withdrawn:** The bounty application has been withdrawn by the bounty applicant, indicating they are no longer interested in completing the bounty. This state is represented by an `s` tag of `withdrawn`.