nips/43.md

NIP-43

Bounties

draft optional

Abstract

This NIP defines a standard for creating, applying to and assigning 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 regular event of kind 8050. This event is published by an applicant and should reference the Bounty Event.

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>" ],

• A c tag to provide the currency of the reward example: "sats" or "usd".

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

• An s tag to track the current status of the bounty: open, assigned, canceled.

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 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.

• An arbitrary amount of t tags to provide a list of tags that can be used as categories to filter bounties.

The following tags MUST be present when the bounty is updated to assigned status:

• A p tag of the applicant public key to track who is currently assigned to the bounty.

• An e tag to reference the Bounty Application Event.

• An application tag with the stringified Bounty Application Event.

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 d tag to reference the Bounty Event.

• A description tag describing what the applicant is applying to containing the stringified Bounty Event.

The following tags MAY be present:

• A p tag to notify the creator of the bounty that the applicant has applied.

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

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. The bounty MUST be created with an s tag of open.

2: Assigned: The bounty has been assigned. The bounty MUST be updated with an s tag of assigned and a p tag of the applicant public key.

3: Completed: The bounty has been completed by the applicant and the creator has accepted the work. This can be inferred by the client by looking up a zap receipt referencing the Bounty Event and the assigned user's public key. The Bounty Event content MUST match the content found in the description of the Bounty Application Event. The reward MUST match in the zap receipt, Bounty Event reward tag and the reward tag found in the description of the Bounty Application Event.

4: Canceled: The bounty has been canceled by the creator. The bounty MUST be updated with an s tag of canceled.

Solution Submission

Solutions to bounties may be submitted via a nip-04 encrypted message to the creator of the bounty. Or however the client chooses.

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.

Why is the Bounty Event Replaceable?

So that we can track the status of the bounty which provides a way for the client to filter out bounties that have already been assigned.

We can work around this by making sure that the content and reward of the bounty event is the same as the content and reward found in the stringified Bounty Event in the Bounty Event Application. No Bounty Event without a matching reward across these three fields (including the zap receipt) will be considered complete. (Unless both parties agree to settle outside of the network)

If the creator changes the content or reward in an effort to scam the applicant, the applicant has a record of the original content and reward in the Bounty Event Application. And the bounty will not count as complete which will at the very least not improve the creators reputation.

If the applicant puts a fraudulent Bounty Event in the description of the Bounty Event Application the creator can choose not to pay.

Without an agreed upon 3rd party there will always be a way to scam the system. This is the best way I can think of to discourage scammers. If the bounty was not replaceable, the creator could just delete the event anyway and skip paying after the applicant has submitted their work.

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.
2. 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 note can also be published along with the creation of the event referencing the bounty with an arbitrary list of p tags for users the creator thinks may be interested in reviewing or applying the bounty.

Potentially make currency it's own tag so you can filter by currency.