White Paper
Search…
Marketplace Accounting: Neighbourhoods Credits (NH-Credits)
For the Low-Code Marketplace to work as an automatic decentralized market, it needs an automated crypto accounting system built on a relatively value stable unit of account. We call this unit of account NH-Credits.
The following presents our current progress toward the design of the low-code marketplace, and should be read with the understanding that particulars may be affected by its future governance and our efforts to share such governance amongst market actors described above.
Module Pricing and Economic Principles
The unit of account uses the representation of human-hours required for ideating, designing, implementing, critiquing, iterating, and maintaining modules. NH-Credits are measured in human hours, with each NH-Credit equaling one developer hour, where a developer is anyone that has worked on the module.
Accounts for ‘hours worked’, not ‘number of end-users’
NH-Credits measure hours worked, not lines of code on their own. This enables us to deliver a crucial benefit to neighbourhoods: when more users flock to a module, the cost for access to the module drops. This is a key difference that Neighbourhoods is bringing to the pricing of code. Traditional tech companies generate more revenue as users increase, with the same lines of code. Code is a non-zero-sum resource, which we are here taking advantage of to be able to spread more useful, distributed app code to more communities more cheaply.
Figure 7: Hours-contributed versus NH-Credits earned for a typical module-developer, in contrast to the need for upfront capital, by a community or VC, for development.
Our approach, enabled by the NH credit accounting system, can bring about a shift in the pricing of code that sets a precedent in the crypto space for the benefit of groups of users and the code commons. Because we expect that more people using a module may entail a greater number of required hours of maintenance, these hours may be reflected in the pricing in NH-Credits/week. This is a fair increase rather than a venture multiplier; NH's stance is that revenues to developers shouldn't increase on principle as a function of increased user count.
Figure 8: Declining costs per user for a module as number of users increases (assuming the number of hours required to maintain a module remains constant)
We envision that the standard of ‘1 NH-Credit = 1 Dev hour’ will be met through developers’ setting floor prices and the following process of payout and redemption:
- 1.Developers provide floor price for NH-Credits into a central Holochain DNA stewarded by the Neighbourhoods team. Neighbourhoods algorithm associated with this DNA aggregates prices and determines a weighted average which becomes the floor price; the price at which credits will be offered to community activators.
- 2.Community activators purchase NH-Credits at floor price, while placing $NHT in our reserves.
- 3.Devs price their modules in terms of NH-Credits/units of time (proxy for dev hours/unit of time)
- 1.Prices may change once weekly, with prices automatically rolling over every week if nothing else changes.
- 4.If Community Activators (neighbourhoods) are agreeable to the price, they accept the offer. The URL to the module is shared with them, after which they may download, install it to their Neighbourhood, and distribute it to members.
- 5.NH-Credit balance is debited from the community activator (or split across neighbourhood members, as per the economic agreements of each neighbourhood), and credited to developers’ account.
- 6.Devs can choose to redeem NH-Credit against $NHTs in the NH Reserves on a FILO (first in, last out) basis. They may then go on to exchange $NHTs in any ERC-20 compliant exchange.
Figure 6: Developer hours required to design and maintain a module and inflows through NH-Credits.
Last modified 7mo ago