Bounties contract

[JakeHartnell]

A bounty contract is special type of escrow that takes an owner and holds funds for an

• CRUD (only owner)
• Claim Bounty (only owner)
• List Bounty / Bounty query

On bounty creation the funds are taken, on update funds are added or removed and bounty details can be updated, on removal funds are returned to the bounties contract owner.

Typical usage would involve a SubDAO with open proposal submission. Bounty hunters would be able to see a list of bounties, work on one and make a proposal to claim it.

Managing the contract owner (handling updates, etc.) should be done via cw-ownable.

Example interfaces:

pub struct Bounty {
    /// The ID for the bounty
    pub id: u64,
    /// The amount the bounty is claimable for
    pub amount: Vec<Coin>,
    /// The title of the bounty
    pub title: String,
    /// Bounty description and details
    pub description: String,
    /// The bounty status
    pub status: BountyStatus,
}

/// The status of the bounty
pub enum BountyStatus {
    /// The bounty has been closed by the owner without being claimed
    Closed,
    /// The bounty has been claimed
    Claimed,
    /// The bounty is open and available to be claimed
    Open,
}

pub enum ExecuteMsg {
    /// Claims a bounty (only owner)
    Claim {
        /// Bounty id to claim
        id: u64,
        /// Recipient address where funds from bounty are claimed
        recipient: String,
    },
    /// Creates a bounty (only owner)
    Create {
        /// The amount the bounty is claimable for
        amount: Vec<Coin>,
        /// The title of the bounty
        title: String,
        /// Bounty description and details
        description: String,
    },
    /// Updates a bounty (only owner)
    Update {
        /// The ID of the bounty
        id: u64,
        /// The amount the bounty is claimable for
        amount: Option<Vec<Coin>>,
        /// The title of the bounty
        title: Option<String>,
        /// Bounty description and details
        description: Option<String>,
    },
    /// Closes a bounty (only owner)
    Close {
        /// The ID of the bounty to close
        id: u64,
    },
}

pub enum QueryMsg {
    /// Returns a single bounty by ID
    Bounty { id: u64 },
    /// List bounties
    ListBounties {
        /// If true returns only bounties with an open status
        only_open: Boolean,
        /// Used for pagination
        start_after: Option<u64>,
        /// The number of bounties to return
        limit: Option<u64>
    },
}

V2 could include milestones in the bounty, which would allow for breaking up bounties into claimable parts.

[JakeHartnell]

It's possible to have this be usable with out ExecuteMsg::Update { .. }... so maybe that isn't a requirement.

[TrevorJTClarke]

hey @JakeHartnell couple Q's:

• Wouldn't it need to handle received funds? So amount ideally needs to be able to keep track of funds received, likely a map. (Think hackathon pool, or USDC + JUNO)
• Agree with update not being required, but nice for the metadata (typo's happen). Ideally only init or cw20 receiver can update funds. I'm assuming Execute::Close would return/withdraw all remaining funds. Execute::Claim would also need to forward all funds to bounty recipient
• I think one major thing missing is the definition of recipient, needs to be set by the owner at some point. Potentially there can be a "commit" method where multiple individuals can start work toward a bounty, (V2 could require staking :D ) that puts their address in the ring. Then the owner simply approves the claim upon completion.

Thoughts? I'm down to help on this

[JakeHartnell]

hey @JakeHartnell couple Q's:

• Wouldn't it need to handle received funds? So amount ideally needs to be able to keep track of funds received, likely a map. (Think hackathon pool, or USDC + JUNO)
• Agree with update not being required, but nice for the metadata (typo's happen). Ideally only init or cw20 receiver can update funds. I'm assuming Execute::Close would return/withdraw all remaining funds. Execute::Claim would also need to forward all funds to bounty recipient
• I think one major thing missing is the definition of recipient, needs to be set by the owner at some point. Potentially there can be a "commit" method where multiple individuals can start work toward a bounty, (V2 could require staking :D ) that puts their address in the ring. Then the owner simply approves the claim upon completion.

Thoughts? I'm down to help on this

Great questions! Forgot about recipient, updated it accordingly.

It would need to handle funds. They would be mapped to the bounties and sent when the bounties are created. Perhaps a fun thing to add in a V2 would be the ability for others to add more to the bounty (for example, if 1337 makes a bounty that would also be useful to the Osmosis team, they could add extra funds on top).