Open Standard for a HIVE Account Referral System

In this post, I would like to cover a proposal for an open standard for a HIVE account referral system which was designed in a team of very experienced developer and entrepreneurs.

Member of the working group: @cardboard, @asgarth, @jarvie, @sisygoboom, @roomservice

The goal of this open standard is to achieve higher growth for the HIVE ecosystem and addresses different problems which aren't solved yet when it comes to account creation.

Rationale

The intrinsic value of a blockchain like HIVE is determined by the market. One important factor for this valuation is the user-base. A higher demand on HIVE will lead to a higher market prices for it's cryptocurrency. On the flip-side HIVE comes with a inflation of cryptocurrency with different mechanisms like proof-of-brain author rewards, the HIVE proposal system or rewards for witnesses.

A key successor for HIVE:
Grow it's user-base and increase demand on it's cryptocurrency in a higher rate then inflation happens. If this cannot be achieved, it will ultimately lead to a loss of value for all stakeholders.

This Open Standard for a HIVE Account Referral System is trying to address this issue and will rise or fall with adaption in the HIVE ecosystem.

Current Situation

Let's take a look on the current situation and community efforts when it comes to grow the user-base.

Incentives to bring people to HIVE

People who care about on-boarding new user, act in good faith and for the greater good of the platform eventually get rewarded by up-votes when posting on his/her efforts. Funding requests for proposals which would support on-boarding did not receive nearly enough stakeholder support in the past.

Lack of Resource Credits

From my experiences I made with @hiveonboard a lot of issues in the process of account creation could be fixed (like scalability, funding resource credits, user-friendliness) but there is still a major problem yet to be solved. Take a look what an account with zero HIVE POWER can do:

• 2 comments
• 44 votes
• 17 transfers

We want to get new people engaged into HIVE and when they like what they see - there is a good chance that those user get investors which lead to an increased demand of our cryptocurrency.

It's pretty much obvious that 2 comments won't be enough to achieve a good starter experience.

Let's face it: New accounts require a small delegation of HIVE POWER

From my point of view, it won't make much sense to loose those people a few hours after on-boarding because they can't broadcast any transaction. They wan't to try out the Web 3.0 and experience the future of social media - but in most cases they aren't ready for an investment at this stage. Let's convince them!

HIVE Account Referral System

Involved Entities on Account Creation

When a new user join the HIVE ecosystem there are usually up to three entities involved:

• The referrer who brought the new user to HIVE
• The creator who funded the account creation operation
• The provider who provided a software solution to make it happen

These entities are important roles which will be used in the details of this open standard. It's also important to mention that it is totally possible that not all of these entities have to be involved.

Creating Incentives

Entities involved in on-boarding new user will be suggested as default beneficiaries, when a post is created on a HIVE interface, which wants to support this open standard. Bringing in new user on HIVE could be rewarded, when the new user starts using dApps, brings in value and receives up-votes. This way, on-boarding new user, will come with a long term motivation and will lead to growth of the platform.

The referrer should be motivated to care about the new user, help him to get started and consider sending out a small delegation to provide enough resource credits for a nice starting experience.

The referred user on the other hand will be glad, somebody takes care of him, so there is a good chance that there is an agreement on the beneficiary default settings. If the new user doesn't agree, he will always be able to adjust or remove this setting at any time but there is also a risk that this will come with the lost of the support from the referrer (which could be help or delegation for example).

Implementation

In order to create incentives for all entities described above, a meta-information is passed in the act of account creation into the json_metadata of the new account. Since all account creation operation of HIVE support an optional json_metadata parameter, this can be done on-chain and no off-chain solution is required in order to store this information.

Sample:

{
   "beneficiaries": [
      {
         "name":"roomservice",
         "weight":300,
         "label":"referrer"
      },
      {
         "name":"tipu",
         "weight":100,
         "label":"creator"
      },
      {
         "name":"hiveonboard",
         "weight":100,
         "label":"provider"
      }
   ]
}

Properties for each entity:

• name: valid HIVE account name
• weight: suggested fee percentage (100 means 1%)
• label: label of the entity (referrer, creator, provider)

Mandatory rules:

• Put at least one entity into the beneficiaries array
• Only the property keys described above may be used, the values are variable

Since the information is an array of objects, it's not a requirement to use all three entities:

• Let's assume you are running a account creation service for a fee of 3 HIVE - in this case it would make sense to to leave out the creator entity since the user has funded the account on his own.
• Let's assume you create an account on a blockchain level without any frontend support - in this case it would make sense to leave out the provider entity since no other software was required.

Ability to change those values:

• The owner of the account created can always change or remove this meta-information with his key.
• The beneficiaries array could also be used to persist beneficiary settings across all HIVE dApps

Let's talk about Abuse

Bad Actor is creating multiple referred accounts

Since no posting rewards are created or given out on top of the existing HIVE rewards mechanics, bad actors won't have any incentives to create multiple referred accounts and make use of the system. They could try to abuse the beneficiary system and disguise their activity with multiple referred accounts, but that's an issue, which HIVE has already to handle since the beneficiaries system was introduced.

Bad Actor is creating accounts with inappropriate fees

As already mentioned before, the beneficiaries meta-data on account creation is a suggestion to HIVE dApps. In the guidelines for dApps (next chapter) there is a recommendation that fees could always be hard-capped or removed entirely if inappropriate.

Even if that's not handled on a front-end-side, this will have consequences:

• The account creation service will quickly loose trust and it's user-base
• Referred user, will remove the beneficiaries meta-data from their account

So the risk vs. rewards ratio for this attack scenario is pretty low and there are counter-measures in place.

Guidelines for dApps

The whole system will rise or fall with dApp support. The more dApps will adapt this system, the better for the whole HIVE ecosystem. Here are a few guidelines for dApps.

• Use the beneficiaries information whenever a user creates a post.
• Allow the user to change/remove beneficiaries settings on each post or account-wide.
• Consider hard capping suggested fees on a limit or remove it entirely when it's feels inappropriate.
• Consider a notification for the referred user, recommending removing the beneficiaries from his json_metadata when you feel it is appropriate. For example if the referrer removes his initial delegation support, after a period of time and/or the referred user reached a cap of posting rewards.
• Create an interface where referrer can keep track of referred accounts, it's activity and available rc.
• If you offer account creation, create an interface where user can create a referral link.
• If you offer account creation, validate the referrer information and make sure it's a valid account.
• If you offer account creation, include information about those entities and fees into your TOS.

Feel free to add suggestions yourself, it's just a starting point.

Let's work together and make it happen

If you think a referral system like this could help the HIVE ecosystem to grow, reach out to your favorite dApp and ask for integration.

Since this post should stay as neutral as possible when it comes to dApps, I'd love to see statements from dApp developers if and maybe how they are going to use this open standard on their platform.

Regarding this topic a lot of stuff has happened on @hiveonboard behind the scenes in the last few weeks and all of it will be covered in an upcoming post. I've hard about dApps working behind the scenes as well.

Beneficiaries of this post are member of the working group mentioned in the first chapter.

This is @roomservice and when you like my work, I would be glad to be your witness: Vote here