Decentralized Developer Reward: Completing the Incentive-Circle
By: Herman Schoenfeld
Tags: Bitcoin, Bitcoin Cash Fork, Cryptocurrency, Crypto, Pascalcoin

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.

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:

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. 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. 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. 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 . 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.