I have been thinking a lot about bounties over the past few weeks, how to systemize it, and how to imbue the spirit of steem directly into it's core. This document focuses on technical requirements, systems and the user experience. I am not the best designer in the world, so I didn't take a stab at the ui/design aspects of the project. Those are secondary to the actual systems behind it anyways.

This is what I came up with. It's huge, so I broke it into 3 major parts:

• A technical/ux concept for an MVP bounty system
• Further analysis of specific concepts
• My personal thoughts on this system

If you're planning on diving into this entire post, I'd recommend setting aside an hour or two to fully comprehend it's design.

This post is in direct respond to Milestone #1 from Hive account@ned's post, It's time for a steem bounty system.

---

Part 1: The Bounty Website - MVP Edition

Terminology used in this document

Briefly, here's some of the terms I will be using throughout the document.

• Bounty Creator: The originating user who submits and funds the bounty
• Bounty Hunter: A user who is submitting work to claim the bounty
• Bounty Backers: A user who votes on the bounty announcement post
• Bounty Contributors: A user who contributes additional funds to the bounty
• Bounty Hunter Claim: Submitted work by a Bounty Hunter to claim a bounty.
• Bounty Reward: The total reward pool built around a bounty (funding, post rewards, etc).
• Bounty Website: The specific website that powers this system. I don't have a name for it, so I'll refer to it as such.

Theoretical requirements for submitting a Bounty in the MVP system

• A task that consists of a single phase & reward.
• A task that in which a reward will be given to a single Bounty Hunter.
• An initial funding of at least 10.000 SBD (arbitrary minimum amount).

The internal life cycle of a bounty

A bounty, as an entity, will have the following lifecycle to flow through. This concept should also be further elaborated into a flow chart with all labeled decisions.

1. Bounty Submission
2. Bounty Creation
3. Bounty Hunter Claims
4. Bounty Conclusion
   a. Completion
   b. Cancellation
   c. Abandonment

1. Bounty Submission

The Bounty Submission phase is a process performed by someone who has initial funding and wishes to pay someone to complete a task. This person will be the Bounty Creator and associated as the primary point of contact behind this task.

1. Bounty Creator visits the Bounty Website
2. Clicks "Create New Bounty" (no registration necessary)
   • fills out task title
   • fills out an introduction/background for the task
   • fills out the tasks that need to be completed
   • fills out any additional requirements
   • fills out contact information
   • submits form
3. Submission creates a database entry and a unique identifier for the bounty
   • Bounty is not yet active
   • Bounty now has a lifespan of 24 hours, in which unfunded bounties will be deleted
4. User is redirected to a confirmation page
   • User is given the opportunity to review/change the bounty before it's finalized
   • User is given instructions on how to fund the bounty using SBD/STEEM
     • Multiple options can exist here, steempay.io/shapeshift/cli_wallet commands
5. Bounty Creator transfers initial funds to Hive account@bounty with the identifier provided in the memo field of the transaction.
6. Upon receiving of initial bounty deposit (meeting the minimum bounty requirements):
   • The first account to deposit is now associated to the bounty as the Bounty Creator
     • Future versions of the Bounty Website could include controls for the Bounty Creator to manage the bounty into the future.
   • The confirmation page dynamically updates and shows completed, with a link to the appropriate pages.
     • Link to view bounty on the Bounty Website.
     • Link to view the announcement post on steemit.com.
     • Link to documentation on how you should promote your bounty.
   • The bounty information can no longer be edited (also due to the 24h lock on posts).
     • A future version of the Bounty Website could allow the Bounty Owner to "amend" the bounty, showing a full changelog of how the bounty has evolved.
7. The system moves onto the next phase, Bounty Creation.

2. Bounty Creation

Upon a successful funding and creation of a bounty, the Hive account@bounty bot will create a post on the blockchain with an announcement of the bounty.

1. The Hive account@bounty bot will create a post:
   a. Using the #bounties tag (or whatever tags deemed by the community)
   b. The post will contain:
   • A summary of the bounty, as filled out in Phase #1
   • A bit of information about the Bounty Creator
   • A large prominent link to visit the Bounty Website to view the live status
     • This will be important because after 24 hours, the information in the post will be locked
   • Instructions for Bounty Hunters on how to submit a claim to this bounty (details below)
   • Instructions for Bounty Contributors on how to add additional SBD to the reward pool (details below)
     c. If the bounty has been funded with 100 SBD or more (arbitrary amount), the Hive account@bounty bot will also vote on the bounty post, contributing to the reward pool and visibility.
     d. All SBD rewards from the post (24h + 30d) are automatically allocated to the reward pool for the bounty.
   • This allows a form of non-monetary contributions from the community to support
   • Any post rewards will be distributed once they're available and the bounty is complete.
2. The Bounty Website will begin displaying the bounty
   a. All of the information submitted by the Bounty Creator will be displayed on the page of a specific bounty. More details about this page below.
   b. The bounty will show up on the homepage and the pages which allow you to browse bounties.

3. Bounty Hunter Claims

For the MVP of this product, we would create Bounty Hunter Claims using the steemit.com posting interface. As the Bounty Website continues to evolve, this process could be internalized within the Bounty Website for ease of submission.

1. Each bounty has a unique identifier associated to it, displayed prominently on the Bounty Website and on the steemit.com post. To submit a claim for the bounty, the user must:
   • Create a new post using the bounty-submission tag as well as a tag with the unique ID of the project, e.g. bounty-57ccca17c0c84a002b704b71.
   • This post will contain the required information to complete the bounty:
     • Images if it's an image task
     • Content if it's a content task
     • Links to external files if it's a development task
   • The Bounty Hunter could also earn a reward for writing this post and potential tips for the effort.
2. Each Bounty Hunter Claim submitted will be reviewed by the Bounty Creator.
   • The Bounty Creator could be notified via email/slack/etc of new submissions
   • The Bounty Creator will provide necessary feedback on entries as needed.
3. All of the Bounty Hunter Claims that are tagged with the bounty-{id} tag will be aggregated and displayed on the Bounty Website as potential claims to the bounty.

4.a Bounty Completion

Once a suitable Bounty Hunter Claim has been submitted, and the Bounty Creator is satisfied. The Bounty Creator can signal the end/award of a bounty. For the MVP of this product, it will be done through the issuing of a specific command from the originating account.

In essence, we will have a single command that needs to be issued:

bounty-{id} award account_name

This command can be issued in a number of ways:

• Sending a transfer of 0.001 SBD to Hive account@bounty with the command as the memo.
• Replying to the bounty announcement post with the command as the body.
• A future private messaging system with the command.
• Creating a new post with the command as it's body and a specific tag.

Currently this system is designed in that the Bounty Creator picks an entry to award the bounty. Future "types" of bounties could be created that also allow for voting of the winner or multiple users deciding.

4.b Bounty Cancellation

If for any reason the bounty owner wants to cancel a bounty, the bounty owner can issue a special command (using the methods above) to halt a bounty. Bounties may need to be canceled due to lack of participation, or failing to reach a specified amount.

bounty-{id} cancel

Once a cancellation is started, it will enter a 3 day period in which funds are released from the time locked savings. During this time, a cancellation can be challenged by anyone to halt the withdraw and dispute it. A user may be in the middle of working on something and wants an opportunity to display their work. Human intervention and moderation will be required at this point for the MVP to ensure no abuse of the system is occurring.

After the 3 day cancellation process, all funding to this bounty will be distributed back to the Bounty Contributors who contributed at the exact amount they contributed. Any remaining SBD (from post earnings) will then be powered up by the Hive account@bounty bot.

4.c Bounty Abandonment

If a bounty is abandoned, currently the team behind the Bounty Website would have to reconcile things manually. Questions remain about what constitutes an "abandoned" bounty and efforts should be made to contact the Bounty Creator should this situation arise. Developing an automatic system for this aspect should wait until further evaluation is done.

---

Part 2: Further analysis and elaboration of specific concepts

Bounty Contributions

There are two ways anyone can contribute to a bounty and it's reward:

• Large impact: by contributing liquid SBD/STEEM into the bounty pool
• Small impact: upvoting the announcement post of the bounty

Both of these classes of users will be highlighted on the Bounty Website as users who are helping contribute to the success of the platform. This idea could then morph into leaderboards and profile pages, giving people a place to proudly show their support. Most of this concept should remain outside of the MVP of the product, but can easily be grown into.

Disputes

All disputes will be handled by humans in the beginning. Any part of transferring funds or awarding Bounty Hunters can be disputed and handled by hand.

Arbitration Council (potentially) - A team of volunteers could be assembled/voted on to handle all disputes that require human intervention.

Disputes and the 3 day saving account withdraw

The bot during it's distribution of rewards has a built-in 3 day dispute period, thanks to the time-locked savings accounts. During that 3-day window, any disputes can be surfaced and the transaction can be halted. This should provide a sufficient oversight window.

Multiphase bounties (aka milestones)

Multiphase bounties should be broken up into multiple bounties for the MVP of this product. The additional complexity it causes should be moved to a later date to avoid release of the initial product.

Promoted Posts

The promoted post system could be used to promote bounties to larger audiences. Anyone using the current system could promote a bounty if they choose to do so.

Multi-sig Bounty Creator

Bounty owners could technically be groups of users who are in control of a multi-sig account. A Bounty Creator could set their posting key to multi-sig to require the modification of a bounty.

Community voting for bounty awarding

This currently can't work, there's a number of reasons as to why we shouldn't use voting on posts/comments as a mechanism to choose who to reward. This could be an entire post about the mechanics of voting and why it wouldn't be the best fit.

Multiple Bounty Hunter Rewards - reward splitting

In an initial capacity, this should be considered a "nice to have". It creates additional layers of complexity in the automation of rewards distribution, and because of this, shouldn't be considered for the MVP.

In the future, being able to state "3 rewards" during the creation of our bounty would be ideal. This would then cause the system to split the rewards 3 ways based on the 3 accounts the Bounty Creator has chosen to award.

Bounty Time Limits

The concept of time limits on bounties should be explored outside of the MVP. Determining appropriate lengths and the parameters for abandoned projects will be learned over time.

Transfers and Testing

To start out with, I'd recommend that all transfers actually use multi-sig and someone overseeing the program day to day would ensure the bot is distributing funds correctly. I doubt the volume would be high enough to make this an incredibly burden, but people would need to know that there's a human blocking some transactions so it may take days for approval.

Weekly Bounty Recap

Each week, the Hive account@bounty bot could create a recap post of all active and recently completed bounties. This would serve as a health-check to the community and as additional visibility about active bounties to the community.

It's another method for the Hive account@bounty bot to grow in power and use it's influence to promote bounties.

• All active bounties will be displayed in the post with their current information
• All bounties completed in the last week will then be listed with results
• The SBD earnings of this post could be redistributed into all active bounties or used to fund development of the service
• Encourages new users to submit bounties + votes on active bounties

Hive account@bounty bot concept

• Acting as a "whale"
  • The bot could act as a sort of whale account to help bounties with visibility and rewards. Specific criteria would likely have to be enforced to disallow gaming of it's power.
  • The bot itself grows in power based on SP rewards by it's posting and curating activity.
  • It could be used to "tip" people who submit meaningful, but not finalized work to a bounty.
• Helping self-fund it's own development - paying for infrastructure and development costs.
  • The bot could author non-bounty posts (maybe patch notes for the program?) to earn SBD + STEEM, then used to pay for services.
  • The bot could be powered down for a weekly contribution to costs.

Hive account@bounty bot behavior

• Incoming Transfer Operations
  • Any transfer sent with a matching bounty ID will be automatically pooled with other matching IDs
  • Any transfer sent that has an invalid memo will automatically be send back to it's source.
• Outgoing Transfers
  • Once the specific conditions (smartcontract someday?) are met, the bot distributes the awards accordingly.
• Time Locked Savings
  • All funds received by the Hive account@bounty bot will store funds in a the new savings protocol
  • All funds within the Hive account@bounty bot will take 72 hours to release due to this
• Potential Escrow Usage
  • It's possible the bot could use the new escrow feature in some way, but it yet unknown. Currently with the crowdfunding nature of this proposal, escrow may or may not make sense.

Cost of maintaining the service

• The initial development of this project isn't a small feat, especially when you're talking about holding and escrowing funds for projects. Security and monitoring should be considered in every aspect of the development of this system's automation.
  • I would put roughly 2-3 months of development time on the MVP of this project to build the foundation right. It may go a lot faster than that, but it's a comfortable timeframe to not feel rushed and cut corners.
  • High level components:
    • The frontend Bounty Website
      • Submission of Bounty
      • Viewing of a Bounty
      • Browsing, searching, filtering of Bounties
    • The Hive account@bounty bot(s)
      • A process to monitor and handle automated transactions
      • A process to create and monitor posts
    • Support System setup and considerations
    • Infrastructure Setup
• Ongoing/future development
  • Maintaining APIs with the changing steem blockchain
  • Implementing native solutions and creating a single site experience
  • Integrating new payment methods for funding
  • Adding user/management interfaces
  • Mobile implementation
• Monitoring
  • Post monitoring for spam/abuse
  • Daily Reports to keep tabs on if any attempts to game the system occur
  • Vigilant monitoring of the bots and wallets
• Infrastructure
  • This setup requires a multi-server infrastructure. Estimating ~100 USD a month.

---

Part 3: My personal thoughts on the bounty system and going forward

TLDR: This project, done right, really isn't as simple as it sounds.

As you can see from the above outlines and thoughts, building a system that embraces the reward structure and ideology of steem isn't as simple as customizing a CMS. I've spent a non-insignificant amount of time already exploring the concepts behind it, and I didn't even scratch the surface of an effective user interface/design.

I am incredibly happy to share this thought experiment with all of you and hopefully some of the concepts and ideas will help spark new thoughts. There are a number of concepts here that could be expanded upon for the bounty system or potentially for other applications.

To close this out - I am uncertain currently of how much further I will be pushing this project in a development capacity. The bounty system is a large undertaking that I could see myself spending the next few months absolutely focused on. It's also a huge responsibility to take on, especially regarding the security and integrity surrounding the system. I'll be exploring this idea further over the coming week or so to really decide how to proceed.