Hubcoin - Mapping Pico-Economies With Cryptocurrency - Part Two
![](https://steemitimages.com/640x0/http://dragosroua.com/wp-content/uploads/2017/02/logo-hubcoin.png)
Community Rules and Governance
As a currency, Hubcoin is fungible and anyone can buy and sell at market price. Holding Hubcoin is like holding Bitcoin or Ethereum.
But the real value of Hubcoin is observed when it maps processes inside of a pico-economy. In order to do that, a Hubcoin holder must implement the special root interface "membership". A community may be founded by a single person, but it needs at least 3 members to implement subsequent interfaces and become governable.
Governance in a specific community is established by an initial vote on a specific issue for at least 3 members. In order to speed up the seeding of a community, the first issue should be the membership payment interval (monthly or yearly, see below).
If there is no voting activity, and there are more than 3 members in the community, the community is still valid, but it won't trigger the "hot" Hubcoins creation mechanism (it will be considered "dormant"). Only when a community gets out of the "dormant" state and it becomes "seeded", it triggers the "hot" Hubcoins creation mechanism (see below).
All voting processes are transparent in the Hubcoin ecosystem.
The governance rules are based on supermajority: a decision is taken with at least 2/3 of the votes, regardless of the number of the members with voting rights. That's why we need at least 3 members to properly seed a community.
Voting rights may or may not be a specific interface implemented by a community (members of a community may or may not be voters, according to what the first implementor decides).
By implementing the root interface "membership", a Hubcoin owner accomplishes a few things:
broadcasts around the Hubcoin ecosystem the fact the he created a new community
pays a fee for the name rights which is immediately redistributed evenly towards all Hubcoin owners (the "interface fee")
blocks collateral in order to prevent spamming and to indicate his personal commitment to the community. The collateral is not capped (at this time, but this may change) and it's publicly visible. Collateral is blocked and can't be used by the interface implementor for the entire duration of the community. It becomes available only after the owner does one of the following actions:
willingly renounces the interface by announcing this publicly and the community disappears from the ecosystem (in this case the name becomes "orphan" and it may not be used again).
the interface fee is not renewed (see below)
Interface names are unique and immutable (non-editable), but they can be transferred between community owners (see below).
The naming structure for the community names follows the TLD reverse notation, allowing for sub-communities derived from a "mother community". There is a single root TLD called .hub, form which all the other communities are named. So, a "mother community" could be: "connect.hub" and a sub-community could be "bucharest.connect.hub". Each sub-community owner must pay the standard "interface fee" and must follow the governance rules established by the "mother community", including the amount of collateral needed to seed the sub-community. The "mother community" has the rights to refuse the affiliation for a specific sub-community.
The right to use the interface names is renewable on a yearly basis, by paying the "interface fee", which value is set up every year by the community owners, following a transparent voting process.
If a "mother community" fails to renew the interface fee or the founder(s) are publicly renouncing the community, then all sub-communities are destroyed as well.
The right to use interface names is transferrable to other community owners, via a public transaction. The price of this transaction is established directly between buyer and seller, and it's public. The transaction enforces the transfers of both the rights to use the name and the collateral. In other words, if somebody wants to "transfer" a community, he will also transfer the collateral which will become available to the new owner as per rules stated above.
A transferred community cannot be renounced earlier than the next "interface fee" interval, i.e. the collateral will remain blocked until the next yearly payment cycle for the "interface fee", when the new owner may choose to stop payments and receive the collateral.
As the ecosystem grows, the collateral may be an indicator of the potential growth of a given community, mapping the size of it to the involvement of the founder(s).
Once a mother community is founded, other Hubcoin holders may join it, by implementing its "root interface", a.k.a. membership. It's up to the community founder(s) to choose the renewal period of this implementation, ideally in the first governance voting transaction, by choosing between monthly or yearly. Once a member implement the membership interface he is considered to "belong" to that community and he may start to implement the rest of the interfaces exposed by that community. A community can hold an indefinite number of members, but if the number goes below 3, it's automatically taken to the "dormant" state and it will stop producing "hot" Hubcoins.
Hubcoins and Hot Hubcoins
Once a community is established with a minimal governing structure (a minimum of 3 members) it may start to produce "hot" Hubcoins.
"Hot" Hubcoins are tokens with a modified value, following a multiplication scheme. The simplest multiplication scheme is to devise a specific percentage multiplication for each community, based on the 3 most important metrics described in the first article:
- belonging
- contribution
- age
So each community will have its own multiplication rate, which will be applied to the tokens obtained by the members while they are belonging to a specific community.
Let's try to illustrate this with an example.
Alice is a member of community A. Bob is a member of community B.
During her membership in community A, Alice receives 10 tokens from a specific source (for the simplicity of the example, will consider she gets them from another member, but sources may vary). The A community has a specific multiplication rate of 0.95, which means 0.95%. So her tokens will actually be worth 10.095 Hubcoins.
During his membership in community B, Bob receives 10 tokens from a specific source. The B community has a specific multiplication rate of 3.45, which means 3.45%. So his tokens will actually be worth 10.345 Hubcoins.
The difference in Hubcoin value from the 10 tokens of Alice and Bob comes from the difference in the value of the two pico-economies. This value, mirrored in the "multiplication rate" changes constantly.
The "hotness" of the "hot" Hubcoins comes from the fact that they must be spent before the next payment of the membership interface (usually a month). So, in order for Alice to spend 10.095 Hubcoins worth of tokens, she must do this before the end of the month, otherwise, her Hubcoins will lose their extra value. At the end of the month, if she decides not to spend them, she will have only 10 tokens.
The "hotness" of Hubcoins accounts for the following facts:
- the value of a token is tied to a specific economy (just like the dollar is tied to the dollar-using-economy, euro to the euro-using-economy, etc)
- the value of a token in a specific economy is tied to a specific time interval
Pico-economies are fast changing communities and the underlying currency mapping these processes should constantly adapt to these changes. By locking the value inside a specific time interval we make sure the actual worth of a hot Hubcoin is correctly referring the current value of the mapped pico-economy.
Please note that the extra-value of a hot Hubcoin is recognized across the entire Hubcoin ecosystem, i.e. if Bob wants to spend his hot Hubcoins inside Alice's community, he will spend 10.345 worth of Hubcoins, as long as he does this before the ending of the membership renewal interval.
In the next part I will add some final thoughts on the technical implementation.
Looking forward to hear your comments on this second part. Thank you.
Links to the previous article(s) in this series:
Significant parts of these articles are taken from the Hubcoin whitepaper, which is a work in progress now, and are published with the intent of gathering feedback, suggestions and criticism. The official Hubcoin whitepaper could be available in the second half of February 2017.
I'm a serial entrepreneur, blogger and ultrarunner. You can find me mainly on my blog at Dragos Roua where I write about productivity, business, relationships and running. Here on Steemit you may stay updated by following me @dragosroua.
![Dragos Roua](https://steemitimages.com/640x0/http://dragosroua.com/wp-content/uploads/2014/05/bamf-e1448824881306.png)
https://steemit.com/~witnesses
If you are involved in development of a Hubcoin, here is an advice: make it simple. More complicated it is, less you can count on success.
Thanks for the advice. Using a Hubcoin should be really simple, but I'm afraid the underpinnings of it are a bit more complicated. It's like with any other cryptocurrency: 99% of people using Bitcoin never heard of a Merkle tree before.