Bounty to Develop Delegation Manager for Hiveonboard


Hiveonboard has created an open standard for Hive account referrals that has streamlined the new user sign-ups on Hive. Anyone can now request an account and have one made instantly for no upfront cost. This makes the process seamless for new users and allows them to begin using our platform instantly.

If a user was referred by another person, there is an incentive for the referrer to support the new user with guidance or a small Hive Power delegation. This is because the referrer will receive 3% of the new user’s posting rewards as a beneficiary on supported sites, so long as the new user doesn’t opt out. There may be other interested parties as well like dApp owners – in the sake of simplicity we will call this group of people the referrer.

Since it’s an open standard – the system can be used by any other account creation service, so the system is designed to always be truly decentralized and doesn’t require Hiveonboard as a requirement.

The Issue for Referrer and Users

While this system makes it simple for new users to receive an account there’s still a bit of work on the backend for the referrer to support these new users for the long term. When a user signs up via Hiveonboard they are given a 10000.000000 VESTS delegation from @hiveonboard for 7 days to have enough resource credits to interact. For any additional resources or after that initial period it’s on the referrer to support users with additional delegations.

To date there has not been an automated system to handle this. This means that a referrer will have to manually monitor for memos from @hiveonboard and then manually apply delegations to users. Additionally a referrer will need to track those users manually to determine when they need to revoke delegations in favor of supporting newer users.


We’ve determined the best solution to this issue is the creation of an MIT licensed program that any referrer can run for themselves to manage delegations to new users. This program will listen to events on the HIVE blockchain and apply delegations to new users created via the open standard based on the referrer’s rules for delegation. Additionally the program will manage these delegations to ensure they are revoked if a new user decides to opt-out of the beneficiary system or if the user falls outside of the referrers rules for delegation.


First and foremost this program will need to be open sourced with an MIT license so that anyone can run it or modify it for themselves. Additionally we believe the program needs to be as lightweight as possible to be ran on commodity servers to encourage all referrers to run it and support new users to the Hive ecosystem.

The system will need to do the following activities:

1.) Have a simple config.json allowing referrers to define their metrics for delegation. This configuration should support:

delegationAccount = Account Delegator
adminAccount = Account that monitors program
delegationAmount = Amount of delegation to apply to new users
delegationLength = Number of days a delegation lasts by default (0 for infinite)
beneficiaryRemoval = Should program remove delegation if user revokes beneficiary (boolean)
minPostRC – Total number of comment operations that you’d like to ensure new users can access before delegating
muteAccount = Bot will check muting against to automatically remove delegation to abusive users
hpWarning = The level of HP available in delegationAccount that should notify adminAccount
maxUserHP = Level of HP a referred user will be considered able to support themselves.
notifyUser = Should program notify users of delegation updates? (boolean)
delegationMsg = Default message sent to users about new delegation
delegationLengthMsg = Default message for users who’s delegation revoked after delegationLength expires
delegationMuteMsg = Default message for users who’s delegation is revoked due to being muted
delegationBeneficiaryMsg = Default message for users who’s delegation is revoked for removing beneficiary under open standard
delegationMaxMsg = Default message for users with enough HP to support themselves

2.) Program has to listen for account create events on the HIVE blockchain and parse the json_metadata if the created account was referred by the delegationAccount.

Bonus: Program may query the hiveonboard API ( with dappAccount replacing sportstalksocial) or query a Hivemind server on first startup in order to retrieve historical referred accounts this way it could prevent parsing the whole blockchain history to gain all data.

3.) When new user is detected then program will need to store user in the state file of accounts that have been referred by delegationAccount

4.) Program will need to listen for users muted by muteAccount and ensure that those users are removed from state of referred users. If notifyUser = true, send new user delegationMuteMsg as a 0.001 Hive transfer memo.

5.) Program will need to listen for account activity (posts, votes, transfers, json) from accounts within stored state. If activity is detected from users then check user account for current RC state. If RC is lower than defined RC minimum for program (referred user’s RC < current witness cost for resource credit cost * minPostRC) then issue delegationAmount to user. If notifyUser = true, send new user delegationMsg as a 0.001 Hive transfer memo.

6.) If delegationLength is > 0, program will need to review “timestamps” from the delegation transaction to determine if any are past delegationLength. If they are the bot will need to revoke delegation for that user. If notifyUser = true, send user delegationLengthMsg as a 0.001 Hive transfer memo letting them know delegation has expired.

7.) If beneficiaryRemoval = true, the program will need to check users with an active delegation to ensure they’ve not opted out of beneficiary rewards defined in the open standard by removing beneficiaries json. If user has revoked beneficiary then bot will need to remove delegation to user. If notifyUser = true, send new user delegationBeneficiaryMsg as a 0.001 Hive transfer memo.

8.) If maxUserHP is defined, check users with delegation for their current HP. If their HP is > than maxUserHP then remove delegation. If notifyUser = true, send user delegationMaxMsg as a 0.001 Hive transfer memo.

9.) Check dappAccount against hpWarning to ensure there’s enough HP available for future delegations. If HP is below amount defined in hpWarning send adminAccount a 0.001 Hive transfer with memo notifying them to add more Hive Power.

10.) If delegation fails for any reason then bot should notify adminAccount of the issue as a 0.001 Hive transfer memo.


To support the creation of our proposed solution we are creating a bounty for this work that we will offer to the first user who provides a working program that meets the design qualifications listed above. To claim this bounty you will need to leave a comment on this post that links to a public, MIT licensed GitHub that meets all of the design metrics above. The GitHub should feature a README with simple instructions on how users can install on a VPS as well as how to edit the .config to match needs. After submitting we will be reviewing the code and once confirmed will send the bounty to that user.

The current bounty for this completed work is 875 Hive. This includes donations from the following users:

250 Hive from @sportstalksocial
250 Hive from @theycallmedan
250 Hive from @leofinance
100 Hive from @aggroed
25 Hive from @dbuzz

If you would like to help sponsor this work please send any Hive to @sportstalksocial along with a memo stating it’s for “Hiveonboard bounty” and we will update this post to include your bounty inclusion.

We reserve the right to decline any submissions based on our needs and any evolving discussions.


Open Standard for a HIVE Account Referral System by @hiveonboard

Default @hiveonboard delegation API Documentation

Thank you

We'd like to take a moment to thank everyone who's contributed to making this project happen. The community's backing for building tools is like none other and is one of the many reasons why Hive is so special. We'd also like to thank @roomservice for all of their work on @hiveonboard and helping us with the revision of these guidelines. As a very small token of our appreciation we've assigned a 20% beneficiary to this post to go to @roomservice.


you can find my solution for a delegation manager for onboarding on github:

  • I added referrerAccount to the config, so that delegationAccount can be different from the dapp account
  • delegationAccount sends out the transfers (so that only one active key is necessary)
  • beneficiaryRemoval is only applied on posts and not on comments
  • account activity is only checked for new activity (beginning from time when the bot is started)
  • Owned HP is used for maxUserHP
  • The hiveonboard API is used to initialize all referred accounts
  • Active delegation is checked by database_api.list_vesting_delegations
  • Active key is stored in the beem wallet
  • If notifyUser is false, a user will never receive a transfer memo

Please let me know if something does not work or when changes are necessary. I will also prepare a post about this and publish it later today or tomorrow.

Thanks for the initiative and detailed design.

The delegation service for referrers / DApps would be helpful for the communities.

Here is a delegation manager implemented in JavaScript:

To launch the project:

  1. git clone the project to your machine and install dependencies with yarn or npm;
  2. configure config.json and .env for settings and active key of delegator account;
  3. launch the project with yarn run execute

Some design details that might be worth reviewing:

  1. The service comprises three sub-modules for monitoring the status of (a) new and inactive users, (b) the users who have received delegations and (c) the delegator accounts.
  2. referred accounts data are stored locally in a users.json file
  3. new user status are defined as { inactive, delegated, muted, expired, beneficiary_removed, graduated }. Here graduated means the account has sufficient HP to graduate from Hiveonboard.
  4. Hiveonboard referrer API together with outgoing delegations are used to fetch the latest referred accounts status.
  5. Two extra settings referrerAccount and checkCycleMins are added for referrer account, and user status check cycle in minutes.
  6. RC cost estimation for publishing post/comment is implemented based on the reference from beem package Thanks @holger80 for sharing the implementation. I did some research but didn't find an implementation in JS, and the implementation in beemis really helpful.

Happy to contribute to the initiative, and please kindly let me know for any questions or suggestions.

The beem-based solution by @holger80 is a very solid and great work. Glad to provide a solution in JavaScript which might be helpful for some developers, DApps and communities.

Very interesting to see that SportsTalkSocial community is now getting involved in the build of the main HIVE chain. I am anticipating more new users on the Sportstalk Dapp with this renewed engagement. Congratulations to us.