Decentralized Developer Reward: Completing the Incentive-Circle

Miners own their hardware.

Why should developers have any say in what miners do with their hardware?

Likewise, developers own their repos.

Why should miners have any say in what developers do with their repos?

Cryptocurrency development is difficult. It requires a high degree of technical competence and 24/7 readiness in order to respond to any issue.

Mining cryptocurrency is expensive. It requires big investments and constant maintenance.

Fingers hurt from clicking all day? Try Auto Mouse.

Want to use Notion as a CMS for your website? Try Local Notion.

Both development and mining consume time, labour and material and both are necessary to maintain the cryptocurrency ecosystem.

When Satoshi launched Bitcoin, he added a mechanism to reward miners for their contribution. However, no such reward was added for developers. It was assumed development would be contributed for free on an altruistic basis.

Since no cryptocurrency can yet support a global adoption scenario, it’s clear that development is still required in order to achieve the global adoption vision. Also, due to constant innovations in cryptography, it’s clear that development will be required after the global adoption vision is achieved, if at all. It stands to reason that a successful cryptocurrency will require constant development. But how is this development to be funded, if only the miners are receiving a reward? Well, there’s a few options:

1. Don’t reward developers: In this model, developers are expected to contribute their time, material and labour altruistically for the benefit of all without compensation. This may work initially, but as miners become billionaires and developers become homeless, an obvious dilemma arises. At some point, the developers will choose to reward themselves by monetizing the source-code repository they own, since it is their property. Such monetization schemes could include selling access to the repository to 3rd parties for the benefit of those 3rd parties. These 3rd parties could then cripple the system for their own business-case, forcing users onto proprietary 2nd-layer solutions which are monetized. Love it or hate it, this is consistent with Libertarian/Voluntarism principles since the repository is the private property of the developers. Just in the same way that developers have no right over what miners do with their hardware, miners have no rights over what developers do with their repo’s. This follows from the principle of private property ownership.
2. Funded by miners: developers are paid by miners as a form of charity. This may also work to an extent, but can it fund Microsoft-scale teams? Can it cover the onslaught of legal fees from competitor litigation intended to bankrupt developers? Perhaps. But, as with all charity, the receiver is at the mercy of the giver and such a model is fragile and not sustainable long-term.
3. Funded by 3rd Parties: developers are paid by 3rd party companies who re-purpose the project for their own business case. This model can arise from genesis or resulting from (1). Whilst it can pay for Microsoft-scale teams, the development furthers the interests of the 3rd party, not the miners or users. This leads to inevitable hi-jacking of the protocol and centralized development.
4. Funded by a pre-mine: developers are paid by premining a bunch of coins at genesis, and spending slowly over-time. This is the model for most ICOs and some crypto-currencies today. Even if you ignore concerns of “monetary soundness”, the inevitable outcome here is that development is always centralized. Any centralization is an attack-vector for a cryptocurrency, so whilst this may work for utility tokens, etc, it’s unlikely such a project could achieve global currency status .
5. Funded by the protocol: the block reward contains a developer reward as well as a miner reward. Inflation doesn’t need to change, only how that inflation is distributed. For example, miners could recieve 90% of the reward whilst developers receive 10%.

The rest of this article explores option (5) and how it can be used to fund decentralized development teams, like are present in a cryptocurrency such as Bitcoin Cash (BCH).

In a cryptocurrency like Bitcoin Cash, there are several competing development teams. These teams have their own implementation of a protocol defined by consensus rules. If any implementation breaks these rules, the blockchain splits and so does the value of the coin. This has happened already when BTC split into BTC/BCH, and then when BCH split into BCH/BSV.

Competing development teams have a natural adversarial relationship since they compete for user-share. Paradoxically, these teams also have to agree on future changes so as to avoid out-of-consensus failures between their implementations. To make things more difficult, they are currently funded by miner charity, as per (2).

Given this situation, it stands to reason that social consensus between these competing teams is fragile, at best. At any point, any development team could act unilaterally on their implementations and cause a network-wide fork, resulting in loss of value and confidence in the cryptocurrency. More nefariously, a competitor project could compromise a team in order to cause disruption.

As Bitcoin Cash grows towards a global adoption scenario, the pressure on developers will become stronger, the risk of social consensus failure higher and the demand for miner charity unsustainable. Also, since the miners are not sharing the charity burden uniformly, it’s unlikely miner charity will last forever.

As a result, a long-term solution is needed.

Decentralized Developer-Reward

A simple update to the Bitcoin Cash protocol is proposed in order to ensure developers are funded directly by the protocol without any additional inflation to the existing supply-curve.

The developer reward being proposed is basically an apportionment of the existing block reward but split 90% for miners and 10% for developers. The funding is paid out by the same coinbase transaction that currently rewards miners, but now contains N outputs instead of 1. The outputs are structured as follows:

Output 1: this is the miner reward, but now only 90% of the total block reward.

Output 2 .. N: these are rewards for the individual development teams, accounting for the remaining 10% of the total block reward.

The exact apportionments of the individual developer rewards are left to negotiation between the competing development teams. Since they would all be hard-coding the indivdual rewards into the consensus-rules, they are game-theoretically incentivized to:

• Agree on a fair reward distribution among themselves, in order to ensure implementations don’t split (this maximizes their reward value).
• Agree on a common roadmap of features without differing technical details. They need new features to incentivize miners/users to upgrade, so they can receive their reward.
• Agree to implement each others changes in their own implementations in a reasonable manner, and co-operate with technical details, so as to avoid out-of-consensus bugs and forks, to maximize their reward value.
• Overall improvement in development efficiency and productivity, since all teams are maximally sharing and co-operating on code (to avoid bugs).

But what about the miners?

What happens if the developers become abusive? What re-course would miners have to stop an abusive cartel of development teams extorting their hard-earned reward? The following game-theoretic strategy can be employed by miners, without too much difficulty:

• Not upgrade.

Simple as that. If developers become abusive, miners won’t upgrade. However, the competing incentives between all these parties results in a natural win-win homeostasis between all the parties. They will work to upgrade reasonably, since everyone is getting a reward. The biggest beneficiaries are the users, who now can rely on a cryptocurrency that is upgrading but not splitting, over and over.

But isn’t this a communist take-over? Well, not really. Technically, this conforms to Libertarian principles since all participation in this is system is 100% voluntary. Any party is free to split at any time, just as they are now. The only difference is that now all parties are incentivized to not split, which is not currently the case.

However, let’s get real. Can a change “this big” really be rolled out? Won’t it lead to all sorts of disagreement, FUD, and drama? Aren’t the rules of Bitcoin Cash set in stone, like a fossil from another era? Well, no.

PascalCoin Already Did It!

As a developer at another project called PascalCoin, we have some experience here. In fact, we’ve already solved and implemented all this, albeit at a smaller scale. At PascalCoin, we rolled out a 20% developer reward as a hard-fork about 12 months after the initial launch. The proposal was not even made by the founder. How was this achieved? Community consensus via coin-signaling, that’s how.

The community voted using their coins, each coin was 1 vote. A cryptographic proof of the vote was provided, which could be audited by anyone and disputed by no one.

It’s hard to argue against community consensus, so the founder agreed to implement the consensus of the community. To this day, the founder does not receive the funding directly. The founder is paid a full-time salary from the foundation receiving the developer reward, and this has allowed our project to survive the crypto-recession and advance rapidly towards new technology not possible on traditional UTXO-model blockchain. Win-win for everyone, including the miners who earn less but who’s yield is worth more.

Big changes are possible, even in the unlikeliest of circumstances.

So could such an update be rolled out for Bitcoin Cash? Possibly, and here’s how:

1. Limit the developer reward to a fixed number of blocks, such as 10 difficulty-adjustment epochs (approx 5 months).
2. This ensures developers are only funded for a limited time.
3. If the experiment goes horribly wrong, miners will never repeat again, and no big long-term loss is suffered by eco-system.
4. If it goes well, and miners see a real benefit to the value of their yield (even if earning 10% less), then they will signal to support a future developer reward.

By simply following the path empirically shown to be safe and sound by PascalCoin, Bitcoin Cash has the opportunity to signal to investors and the world at large that it is serious about solving the global adoption problem, and not just for scaling.

It would show that Bitcoin Cash is willing to adapt to the Darwinian pressures of cryptocurrency evolution both in the technical code and economic code.