Let us start by saving you a lot of time: No. Beeminder does not need to or want to be on the blockchain.
Are you still here? We figured we’d write about this now because a new Beeminder competitor called STEPN has been getting lots of buzz lately. The idea with STEPN is that you ante some hundreds of dollars (this involves buying an NFT of a shoe?) and then get paid some fractions of cents (depending on what their cryptocurrency is trading at) for every step you take. Granted we are very old and uncool but we find this all semi-excruciating. The actual commitment device involved there is hopelessly buried under all the wild crypto speculation.
(The non-crypto version of this, if we understand correctly, would be like our other competitor, StepBet. Very roughly, you contribute money to a pool and then divvy it up in proportion to how many steps you rack up on your step counter. This version is fine and good.)
But what if we’re all wrong and commitment contracts implemented as so-called smart contracts are in fact smart and not dumb?
We debated this on Twitter a while back with another Beeminder-but-on-the-blockchain upstart called CommitPool and we present to you now a run-through of that debate. [1]
CommitPool’s opening salvo was a link to an FTC press release about Beeminder’s old competitor, Pact. CommitPool’s point is that you can’t trust apps like this, ergo trustlessness.
(If you’re not up on cryptocurrency concepts, that’s a key selling point of decentralized protocols: not having to trust any single entity, and being robust to attempts, even by governments, to shut the thing down.)
In the case of Pact, the FTC shut them down because too many users complained that they couldn’t get refunds. A user would get charged money for missing a workout but it was just that the user had a bad internet connection or something and the workout didn’t get reported. This is an ironic thing for CommitPool to point to because that’s exactly the kind of thing that a CommitPool user would be entirely out of luck on with a commitment contract implemented as a smart contract.
Of course anyone opting in to a “smart” commitment contract has their eyes wide open that there’s no one to appeal to if they don’t think they should’ve actually been charged. But that’s the irony: the FTC article about how many unhappy users Pact had is a case in point for centralization if anything!
We’re avoiding Pact’s problems by scaling up very gradually so if a user has a problem, they will definitely be able to talk to a human workerbee about it. These are problems like “I got charged money for missing my workout because my phone’s battery died and didn’t record the workout”. Beeminder makes sure not to charge you in such cases and CommitPool absolutely would. The code is the law, etc. Which has advantages!
In fact, we recently introduced a No-Excuses Mode because we kind of like the code-is-law mentality and think the most impressive Beeminder users are keen to opt in to that. But this is not us conceding any points in the debate. We can have best of both worlds with our approach.
Here’s CommitPool’s response:
Issues/mistakes like phone batteries dying will always exist. As we see it, there are two ways to deal with them:
- Allow users to appeal missed commitments
- Encourage users to give themselves a buffer by under-committing
Approach #1 takes care of the mistakes problem, but only at the high cost of undermining the core value prop of a commitment by introducing a vector for users to cheat. And any user that cheats isn’t getting what they want out of the product: they’re just cheating themselves. Approach #2 has similar issues, at least on its face: under-commitments lead to users reaching their commitments early, which removes the incentive to complete the rest of their actual goal. But can we re-add that incentive? Yes, and again there are two paths.
Path A (the weaker form) is to create an incentive to “get ahead” by have rolling commitments. This is roughly what Beeminder does, and we like it quite a bit! But we call it the weaker form because eventually the user is far enough ahead to relax and the incentive goes away again.
(Astute point from CommitPool! We have a feature called ratcheting that lets you get rid of excess safety buffer.)
Path B is to introduce a positive incentive correlated with the percentage of the goal the user achieves. The best way to do this is with a pooled model, where money lost by users who fail is split among users who succeed as a reward. This is what CommitPool is building towards, and it is most effective in a decentralized context. Why? As Pact found out, adding a reward is one hell of a growth drug. Best to prevent yourself from even accidentally cheating your users by giving up control. Rewards also attract people who are inclined to cheat, so it’s important to ensure that users have no vectors for cheating. Decentralized activity reporting is just as crucial as decentralized incentive execution.
CommitPool is hitting plenty of nails on the head here. We talk about the adverse selection problem in an ancient blog post from when Pact was new. As for the question of cheating, we have thoughts on that as well.
But the crux is trust and decentralization, according to CommitPool, like a centralized entity accidentally cheating its users. CommitPool’s smart contracts require no trust — at least in the way that Pact did — because there’s no such thing as appeals or refunds. But that’s easy. Beeminder could also, hypothetically, just say “no appeals” and make that crystal clear as part of signing up and then, what possible accidental cheating of users could we do? I mean, we don’t say “no appeals” and so being able to appeal is in fact part of the agreement and so we could, hypothetically, accidentally cheat our users by failing to keep up with the appeals. But it doesn’t require decentralization to fix that. It requires taking the possibility of appeals off the table.
It turns out CommitPool actually does hope to support appeals. They envision “a decentralized appeals process where the community decides if a given user should be forgiven.” This may be our lack of imagination but we don’t think that will work at all. It’s far too much friction to have a committee make decisions like that. But the proof will be in the pudding and we’ll be fascinated to be proven wrong on this.
At this point the debate turned to the question of verification that you’re doing what you committed to.
I believe that CommitPool is kind of hitting a brick wall on this. Their goal, they say, is to 100% relinquish control of their data source for your steps. That’s just Strava currently, for CommitPool, but it could be any wearable gadget like Fitbit or Garmin — Beeminder integrates with all of these.
But (a) how does CommitPool relinquish that control? and (b) even if they do, what good does that do? If it’s about the user cheating, there’s ultimately no way to prevent that. You can always put your Fitbit on your dog and CommitPool and Beeminder can’t tell the difference. Similarly, there’s no way to fully eliminate the need to trust some central entity in the chain that starts with you taking steps, to your gadget recording those steps, to the steps getting recorded on a blockchain, to the smart contract paying out.
The blockchain’s trustlessness and code-is-law-ness only applies to the last step, once your steps are recorded on the blockchain.
In any case, we didn’t go down that rabbit hole in the actual debate because it’s currently moot. CommitPool is currently just as centralized as Beeminder in this regard, having full control of the link between the data on Strava and your money. (This is a common disparity between the theory and practice of web3.)
We agreed to pause the debate until CommitPool has implemented its decentralization vision to the point that users are less susceptible to CommitPool going rogue than they are to Beeminder going rogue. Because currently that susceptibility is identical, not that either of us are likely to go rogue!
Footnotes
[1] In case we’ve accidentally been unfair, the full transcript is in the Beeminder forum.