Toasted Money, Part 2

Further Success with Burnable Payments

A Brief Recap:

In March, I developed the first version of a Burnable Payment contract — see the current version here. I gave the contract a public test run, and the results were promising enough for me to develop an interface to Burnable Payments: Toastycoin. In November I invited the community to try it out, and opened up several more BPs for various tasks — some serious, some silly.

Again, the results were promising. Without any coordination work on my part, several services got rendered, some of which would have been extremely difficult to procure in any other way. In this post I’ll go over what worked and what didn’t with this batch of BPs, and make some conclusions about the unique utility of BPs for certain types of tasks.

Results

I had just over a dozen BPs open when I exposed them to the community via the Ethereum subreddit. Follow the links below to see the detailed history of each BP (Metamask required, for now).

What Worked:

Using BPs, I was able to contract the following services from the Internet:

• Deposit USD into my bank account. I included 0.6 ETH in the BP, and asked for 0.5 ETH worth of USD to be deposited. For an (albeit high) fee of 0.1 ETH, this allowed me to pseudonymously engage in a crypto/fiat trade, without using a marketplace or meeting anyone in person.
• Record a “satanic”, game-theory-worshipping video. See the video here.
• Draw the Ether symbol on a body part. Image here.
• Fix a bug on Toastycoin.
• Create an infographic. Image here.
• A friend asked for $2 USD to be literally burned. Video here.

What Sort of Worked:

A few BPs met with a sort of half-success:

• Create a haiku about Burnable Payments. The first submission didn’t qualify as a haiku, and even after this was fixed I was in the uncomfortable position of translating a subjective judgement for a piece of poetry into a harsh burn/release decision.
• Spraypaint an “Ethereum Wizard”. This was an odd one, and resulted in a complete burning of the BP even though the worker later delivered the service as requested (after the deadline). With more communication from the worker, this could have been avoided. Images here, here, and here.

What Didn’t Work:

Some BPs flat-out failed:

• Create a favicon for Toastycoin. An icon was delivered, but it was not satisfactory. I released the service deposit plus a small amount for the effort.
• Create an email notification server for BPs. After commitment, the worker never gave an update, so I burned the payment.

What can Burnable Payments be Used For?

For certain tasks (more on this below), Burnable Payments can boast two distinct benefits over any other method of outsourcing work.

Outsourcing Small Tasks “Magically” (i.e. with no coordination effort)

During the first Burnable Payment stunt, I had a technical issue verifying the source code of the contracts on etherscan. I opened a BP to solve the issue, and less than 24 hours later a worker had committed verified the code.

During this latest batch of BPs, I noticed a bug involving sanity-checking inputs for the burn/release commands on Toastycoin. I couldn’t figure it out, so I opened a BP to fix the bug. Again, less than 24 hours later, a worker had committed and solved the issue; I only needed to review and accept the pull request.

In both cases, all I had to do was put money into a BP, specify what I needed done, and wait. I didn’t need to field several proposals from hopeful workers, judging the capability and trustworthiness of each. Conversely, workers didn’t need to apply to several jobs hoping for only one — as soon as the worker knew he could solve the problem, he committed and started working. In short, there was no coordination effort necessary for me or for the worker.

Trying to solve either of the above issues via upwork or similar sites wouldn’t have made sense: the amount of coordination work I’d need to do would defeat the purpose of opening the job in the first place. The game theory involved in BPs completely eliminates such coordination effort. Because so much friction is removed from the process, payers and workers can pay or get paid for much smaller, short-term tasks.

Using Burnable Payments, I was able to take these pieces of work that I’d otherwise have to personally deal with, and remove them from my life completely. Once my money was out in the BPs, game theory “magically” did the work for me. This accelerated my project in both cases, allowing me to skip over these unexpected problems almost as if they never existed at all.

Easily Rendering Highly Specific Services from a Global Market

If there exists a single user watching for new BPs who can provide the service you want, your BP will find him and, assuming the payment and service deposit is attractive, incentivize him to commit to the job.

My BP asking for a deposit of fiat into my bank account was fairly specific: my banks only exist in certain states in the US. But I knew that as long as the BP was exposed to just one worker in these states, he’d be incentivized to commit. Indeed, in three days a worker committed and provided the requested service. If I’d included more of a bonus, a worker would likely have committed sooner.

Another user commissioned the literal burning of $2 USD. This is specific in that it requested an explicitly illegal service, which implicitly required that the worker be comfortably pseudonymous.

This ability to request nearly any service or product will become even stronger as other tools are built around Burnable Payments. Advanced search/filter tools will allow workers to not only find specific types of BPs via keywords or categories, but even get notifications when a BP is created that matches certain keywords or patterns.

There are a lot of exciting possibilities here. A payer might commission a local report on a disaster or political coup, minutes after the relevant development. A traveler could request 20 minutes of translation service. Someone suddenly bedridden with a bad flu could request the ingredients for chicken soup to be bought and delivered, and possibly cooked as well.

Burnable Payments Only Work For Certain Types of Tasks

As exciting as the above points are, they only apply if the payer is requesting a task that meets certain criteria.

The task must be simple, small, and discrete

The largest failure of this last batch of BPs was a request to create an email notification server for BPs. A worker committed but never made any updates, so I burned the payment, which had 1.05 ETH (0.75 from me, and 0.3 from the worker’s service deposit). I suspect this is because the task seemed much simpler before commitment, and turned out to be more effort than it was worth for the worker.

It is very difficult to judge the effort that will be involved in large projects. Software developers in particular are familiar with this fact, and even for seasoned, expert developers, creating an accurate deadline is extremely difficult. This dynamic is particularly visible and familiar in software development, but it applies to any large project.

The larger the project, the harder it is to predict the effort it will require. The less able a worker is able to predict this effort, the more the game theory of BPs breaks down. A worker might find the task to be magnitudes more complex than they originally expected, to the point where they’d rather just give up the service deposit than continue the work.

Completion must be easily judged

The game theory of BPs relies on the final decision of the payer to release only in the case of satisfactory work, and burn if the work is not satisfactory. If the payer cannot or does not make this judgement effectively, the BP can no longer be relied upon.

My BP for drawing an ether symbol on a body part was effective partially because it was so easy to verify the work. Conversely, a particularly bad example might be to request feedback on a piece of writing, because a worker could simply say they looked the whole thing over and found no flaws. How could the payer confirm or deny this? Because he can’t, such a BP could easily attract workers that intended to do no or very little work.

One consequence of this is that BPs can’t be worked into a higher-level interface unless the user is involved in this burn/release decision. For example, an app that offers real-time translation services, using BPs behind the scenes, must present the user with feedback mechanism and ensure the user can identify and punish bad translations. Otherwise, scammers would target the application and provide bogus translations for easy money.

Tasks Should be Objective, Not Artistic or Subjective

Part of the frustration with the Haiku BP was that I wasn’t a huge fan of the Haiku, and I had to convert this rather subjective judgement into a harsh burn/release decision.

Subjective judgments are another thing that render game-theoretical predictions difficult or impossible. A worker could commit, believing they have a good piece of art, and the payer could easily disagree. This makes a BP for art a bad idea for both the payer and the worker: the payer could easily receive work they don’t like, and the worker could easily produce work they’re proud of only to see the payment burned.

What’s Next?

In one sense, the project is finished: Toastycoin remains online, and will remain functional unless github pages or the Ethereum network fail. (That’s one of the great things about building a system that relies entirely on simple smart contracts: I could move on, knowing the tool will remain functional without any further support! Thanks Ethereum!)

(EDIT: Wait, this isn’t true anymore! What happened? I’m not sure and I don’t want to go down the rabbit hole — but let this be its own lesson: to make an unkillable dapp, one must solve the issue of making an unkillable interface. The contracts and records of all of this are of course still online on Ethereum… Somewhere. But in terms of end-users? Toastycoin was not actually unkillable!)

There’s very little traffic, of course, but if the payer has some way of getting exposure to his BPs (as I did with a few r/ethereum posts), the system will work just as well for him as it did for me.

But I feel my work here is just beginning. There are two distinct but parallel branches of work I want to pursue, building on what I’ve learned and proven thus far.

Develop Additional Tools for Burnable Payments

There are many simple peripheral tools for Burnable Payments that would make the system easier to use for both payers and workers. Just off the top of my head:

• An email notification server could notify users when BPs they’re involved with receive some action, or when an auto-release timer is almost up.
• An advanced search/filter utility could be developed, so workers can narrow down BPs by specific keywords, patterns, or tags.
• The above two tools could be combined, so workers can be notified when a new BP is created that matches some search criteria.
• A reputation viewing tool could collate information on all the BPs a given user has been involved with. How much has a given payer burned or released?

Each of these could be developed as a standalone tool/website, or as another feature on Toastycoin. Because BPs are non-proprietary, there isn’t really a distinction between the two options. In fact, my hope is that as BPs gain traction, the community will start organically growing the set of BP tools themselves, without needing my involvement at all.

Develop New Simple, Effective Smart Contracts

The success of the Burnable Payment contract is exciting, but there’s something more general that shouldn’t be overlooked: Using only a smart contract of about 250 lines of simple code, I was able to conduct real business over the Internet with strangers, with no supporting infrastructure other than a Javascript interface and some reddit posts.

I’m convinced that Burnable Payments are only the first of such simple, “self-sufficiently effective” smart contracts. Invariably, we will find more, and I intend to lead this charge as much as I can. I’ll start by slightly iterating the existing Burnable Payment contract in two ways:

First, the existing BP contract will be modified to support an additional “Open” state, where the worker has started the BP and is waiting for a payer, rather than the other way around. When opened this way, the BP will already contain the worker’s service deposit and a description of the service they’re offering, and an interested payer is the one who must commit (with a “minimum payment amount” set by the worker). The Committed and Closed states will retain their current behavior, where the payer controls whether funds are released or burned, and the worker is the only possible beneficiary of released funds.

This will allow workers to offer services to the general public by putting their deposit on the line, similar to how payers can already offer jobs to the general public by supplying the payment up-front. And just as a worker can already browse and commit to BPs that interest him, with this change a payer could browse services in the same way and commit to paying for ones they’re interested in. Toastycoin’s browse page would then show not just tasks that need workers, but also services that need customers.

Second, a Crowdfunded Burnable Payment will be developed. This “CBP” will function exactly like the current BP, but will additionally keep track of where all funds came from. Each user can then decide whether to burn or release their contribution, or (possibly) choose to follow some other contributor’s choice. If the CBP is cancelled before commitment, funds will return to their rightful owners.