Note: the images in this page are a bit out of date; they refer to Burnable Payments as "BPs" and show a slightly different interface.

Aside from these superficial discrepancies, the information below remains accurate.

Programmers are invited to follow along in the full Burnable Payment source code, but the leading comments in the source code sum up the basic rules:

...
//In the Open state,
//Payer can logPayerStatement() to add additional details, clarifications, or corrections.
//Anyone can become the Worker by contributing the serviceDeposit with commit();
//this changes the state from Open to Committed. The BP will never return to the Open state.
//After this state change, Worker will never be changed.
//In the Committed state,
//AutoreleaseTime is set to (now + autoreleaseInterval).
//Payer/Worker can logPayerStatement() or logWorkerStatement(), respectively.
//Payer can at any time choose to burn() or release() to Worker any amount of funds.
//Payer can delayAutorelease() setting the autoreleaseTime to (now + autoreleaseInterval), any number of times.
//If autoreleaseTime comes, Worker can triggerAutorelease() to claim all ether remaining in the payment.
//Once the balance of the payment is 0, the state changes to Closed.
//In the Closed state,
//Payer and Worker can still log statements.
//If addFunds() is called, the contract returns to the Committed state.
...

A Simple Example

Let's imagine the payer needs a transcript written for an audio recording. He is willing to pay 0.5 ETH for the service, and sets a service deposit of 0.1 ETH. He also sets an autorelease timer, which is explained later.

For more guidance on what values to choose, see Creating Effective BPs. This page is more of an overview of the entire life cycle of a BP.

After clicking "Create BP," it will be created within the next few Ethereum blocks and will be publicly viewable via the interact page:

The above image shows the payer's view of the BP. Other users don't see the "recover" button or the payer statement input form at the bottom.

Until and unless a worker is found, the BP is in the "Open" state. In this state, the payer can cancel the payment and recover the entire payment. He can also add more funds or log additional Payer Statements if he likes.

Meanwhile, other users are browsing through Open BPs looking for jobs they can do with service deposits they can afford.

If one of these users is confident they can do the work, they can pay the service deposit to become the BP's worker. The BP will now show a "Committed" state with the worker locked in. Additionally, the worker will see a "Worker Statement" form to begin communicating with the payer.

The BP is now in the "Committed" state. In this state, the worker is locked into the contract, and the payer can no longer recover the payment. Note that the committed BP is holding not only the payer's original payment, but also the worker's service deposit (in this example, 0.6 ETH in total).

The fate of this 0.6 ETH is decided by the payer. Although he cannot directly recover it, he can still choose whether to release the payment to the worker or burn it (as in destroy). He can burn or release in parts or all at once.

As you can see, the auto-release timer has already started counting down. This is really just protection from a "lazy payer." The payer can reset this as many times as he wants, up to the amount he specified upon BP creation (5 days, in our example). If the timer reaches 0, the worker will see a "Trigger Auto-release" button. This will release all remaining ether to the worker.

While in the Committed state, the worker and payer begin communication using the Worker and Payer Statements respectively. Because these statements are stored on the Ethereum blockchain, they are reliable, signed, permanent and unhackable. They are also a little expensive and public, so payers and workers may negotiate a private place to chat instead. In either case, the event log below the BP information will show their public actions:

If the worker provides the transcription, the payer can release the payment. If not, the payer can burn it. Once the entire payment has been either burned or released, the BP moves to its final state, "Closed."

BPs utilize game theory to strongly guarantee the following, assuming an appropriate service deposit is set:

If you're interested in the details, see our more rigorous exploration of the game theory involved.

Otherwise, feel free to check out the list of BPs or open up your own BP!

Finally, let me point out that because BPs are nothing more than a specific kind of smart contract, anyone else can create other kinds of interfaces or tools for BPs. As long as these other tools follow the same BP Factory contract, the pool of BPs will be shared as well: a BP created by any one interface would be reflected on all of them.

For example, one could create: