nips/117.md

NIP-117
======

Bounties
------

`draft` `optional` `author:ChristianChiarulli`

## Abstract

This NIP defines a standard for creating, applying to and assigning bounties.

## Event Overview

1. **Bounty Event:** defined as a regular event of kind 8050. This event is published by the creator of the bounty.

2. **Bounty Application Event:** defined as a regular event of kind 8051. This event is published by an applicant and should reference the **Bounty Event** with a single `e` tag.

3. **Bounty Assignment Event:** defined as a parameterized replaceable event of kind 30050. This event is published by the creator of the bounty after receiving at least one applicant and should reference the chosen applicant by the public key associated with the **Bounty Application Event**. This event may be updated to change the associated `p` tag to a different applicant. 

## Bounty Event

The `.content` of these events should be a string text in Markdown syntax similar to NIP-23.

The following tags MUST be present:

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

- A `reward` tag to provide a reward for the bounty. This is an array in the format `[ "reward", "<number>", "<currency>" ]`,

The following tags MAY be present:

- Multiple `p` tags to notify users who may be interested in taking or reviewing the bounty.

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

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

- A `expiration` tag to provide a date and time when the bounty should be completed by.

- A `context` tag to provide a link to a website or other resource that provides more information about the bounty.

## Bounty Application Event

The `.content` of these events should be a simple plain text string explaining why the creator should choose the applicant.

The following tags MUST be present:

- A `e` tag to reference the **Bounty Event**.

The following tags MAY be present:

- A `timeline` tag to provide a date and time when the applicant expects to complete the bounty by.

## Bounty Assignment Event

The `.content` SHOULD remain empty.

The following tags MUST be present:

- A `e` tag to reference the **Bounty Event**.

- A `p` tag to reference the `pubkey` of the applicant chosen to complete the bounty.

- A unique `d` (could be the same as the `e` tag).

## Bounty Lifecycle

The following is a description of the lifecycle of a bounty:

1: **Open:** The bounty is created and published by the creator and accepting applications.

2: **Assigned:** The bounty is has been assigned. 

3: **Completed:** The bounty has been completed by the applicant and the creator has accepted the work. This can be inferred my the client by looking up a zap receipt referencing the **Bounty Event** and the assigned user's public key.

## Motivation

Bounties will provide social incentive to complete tasks related to the development of Nostr and allow developers to get paid and build a reputation across the network.

## Intentional Limitations

The bounties are intentionally not replaceable. This is to prevent the creator from changing the reward or other details of the bounty after it has been assigned. If the creator would like to change the content they may remove the bounty with a kind 5 event and repost.

## In Progress

- This NIP may also provide a way for the creator and other users to pledge additional funds to the bounty after it has been created.

This would require at least 1 additional event to be published:

1. A **pledge** event of kind 8053 published by the creator of the bounty or any other user. (This may be another NIP entirely)

- This NIP may also provide a way for the creator and applicant to settle the bounty out of network if they choose to do so without a zap event.

This would require 2 events to be published:

1. A **settle** event of kind 8054 published by the creator of the bounty with an `e` tag referencing the bounty and a `p` tag referencing the applicant.
1. A **settle** event of kind 8054 published by the applicant of the bounty with an `e` tag referencing the bounty and a `p` tag referencing the creator.

A rejection event may also be published by the creator of the bounty if they choose to reject an applicant. This could be useful if the applicant is not qualified to complete the bounty. This could potentially be merged with the assignment event maybe by using the content field to "accept" or "reject".