This debate between Beeminder and CommitPool is transcribed from Twitter and lightly edited to be more coherent and linear.
BEEM: Let the decentralization debate commence! Aka: “Beeminder-but-on-the-blockchain: smart or silly?” We’ll await an opening salvo from CommitPool. We suggest a concrete as possible use case that Beeminder’s centralized approach doesn’t work well for.
BEEM: Ha, horrible example. The complaints the Pact app got were users saying that they wanted their money back because of technicalities. Exactly the thing they’d be entirely SOL on with a commitment contract implemented as a smart contract.
Of course anyone opting in to a smart contract 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 FTC article about how many unhappy users Pact had is a case in point for centralization if anything!
Here’s our old blog post from when Pact shut down. 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.
Support issues being things like “I got charged because my phone’s battery died and didn’t record my workout”. Beeminder makes sure not to charge you in such cases and, if we understand correctly, CommitPool absolutely would. The code is the law, etc. Which has advantages!
Btw, we’ve been talking about adding a “No-Excuses Mode” cuz we kinda 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!
CPOOL: 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.
BEEM: (Astute point! We have a feature called ratcheting that lets you get rid of excess safety buffer.)
CPOOL: 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.
BEEM: You are hitting so many nails on the head here. We’re impressed! We talk about the adverse selection problem in an ancient blog post from when Pact was new.
And to clarify, there will be no appeals in CommitPool? As for the question of cheating, we have thoughts on that in a previous Twitter thread (blog post version: Combatting Cheating).
CPOOL: Currently there are no appeals. But we can certainly envision a decentralized appeals process where the community decides if a given user should be forgiven.
BEEM: Good and fair point!
BEEM: We should also emphasize that, contrary to the impression that article may give, Pact definitely did not go rogue and steal people’s money. That would be obvious corporate suicide. Rather, they grew too fast and couldn’t keep up with support issues.
BEEM: So Pact couldn’t keep up with users’ appeals when they had technical (or nontechnical) issues preventing them from fulfilling their commitments. CommitPool is immune to this because there’s simply no such thing as appeals and users embrace that? We confess that that’s… appealing.
If we’re understanding your decentralization argument, couldn’t Beeminder also 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 in that case?
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.
CPOOL: So the big thing is user trust. If you take appeals off the board, then the only thing a user can do is trust that you won’t screw them over.
Obviously, there are significant legal and reputational forces preventing the latter.
But relying on those forces limits the growth and power of the incentives that can be used to help users stay on track for their personal goals.
The other part is the source of the user activity / progress data. As long as users can enter that manually, their commitment will be very difficult to enforce and they won’t get as much out of the service.
Clearly, some activities have no source other than self report.
But some do have 3rd-party options whose reputation can be leveraged.
Strava is a prime example.
BEEM: (This debate is awesome, btw; thank you!) We think that any prospective Beeminder user will rationally put the probability of Beeminder going rogue as pretty negligible. But there’s the principle of the thing; that’s fair. Next questions…
CPOOL: (Agreed, this is super fun! Thank you for engaging with us in good faith [fist-bump-emoji].)
BEEM: (1) Does CommitPool collect any of the forfeited money? (2) Does CommitPool manage the Strava connection?
CPOOL: (1) CommitPool currently does collect forfeited money, but that is only temporary. In our next version, all user penalties (lost stakes) will be funneled back into the protocol and distributed to users completing commitments (the protocol may itself take a small cut).
Also, the funds we do currently collect we are manually putting back into the protocol.
(2) We do currently manage the Strava connection (as a Chainlink external adapter), but our goal is 100% to relinquish control of that as soon as our tech (or general oracle tech) is able to handle that while respecting user privacy.
BEEM: All making sense! Maybe at this point we call a truce on the debate until CommitPool has demonstrably lower probability of going rogue than Beeminder does? (Assuming our understanding is correct that that’s at the crux of the debate.)
CPOOL: Sounds good 
And to be clear, by no means do we think that CommitPool should replace Beeminder! Different users will have different preferences/needs in different contexts, so a range of solutions will always be relevant 