If you did not receive the initial airdrop and have been waiting for Hardfork 24 to correct your balances, you were probably surprised to notice that a portion of the tokens remained undelivered. Liquid funds in the form of HIVE and HBD were corrected, but the function that restored the funds didn't properly take into account the tokens that were powered up and VESTS were omitted in the distribution round.
You can view the hardfork code here: https://gitlab.syncad.com/hive/hive/-/blob/master/libraries/chain/database.cpp#L2031
The accounts who have been waiting on the error correction have been incredibly patient through a frustrating period, and completing the airdrop as quickly and as safely as possible without another hardfork is a top priority.
Possible Solutions
Witnesses and developers have spent time since HF24 activation discussing all of the plausible solutions. There are two main ways to solve this, which would be to either have another hardfork to correct the balances, or to make a proposal. Since these funds are being held in the DHF, we could convert the received HBD to HIVE and power up the remaining outstanding tokens to the impacted users.
The advantage of doing another hardfork would be that the balances will be restored instantly and trustlessly. However, there are a number of issues that don't make this a good choice: it's very expensive in terms of developer hours, it involves creating, reviewing, and testing more code (testnets etc), synching the witnesses for deployment...and most importantly, it requires additional downtime for exchanges. All in all, it would take far too long for these users to have their funds corrected this way.
By making a proposal, we can ask for the remaining funds held in trust easily, without any code changes at all. There are a few downsides to solving this with a proposal: it may not reach payout for funding, and the outstanding VESTS will require roughly 117k HBD to cover, which means it will take about a month of payouts to gather. To manage the security of the large amount of funds in a transparent way, there would be a need to create a custodial multisig account. There is also the risk of fluctuations to the HIVE and HBD price that may result in the 117k not being enough. All of this would take extra time and coordination that would continue to impact these users.
After some debating, @blocktrades proposed that he would bear the risk and leverage his own funds and account to distribute immediately, while being remunerated over time. This solves a lot of the problems around making this a top priority for speed, and streamlines the process to make it easy to follow and account for. It's a huge offer that allows for a very quick, one time resolution for the users who have been waiting patiently, but it also is a large burden of trust for @blocktrades to take on and shifts the wait time for the payout on to his personal account.
The Plan for Correcting the Airdrop Vested Funds
This proposal is asking for 142.6k HBD, which is 4750 HBD per day for 30 days. These are the funds held in trust for airdropped HP, and not part of the original development fund.
There is a wide margin included in this proposal to take price fluctuations of HBD into account. Once the proposal is approved, @blocktrades will use his personal funds to vest the outstanding HP directly to each of the accounts still waiting on correction all at once. The proposal will pay out HBD to @blocktrades over the next month, and as soon as enough HIVE has been converted to cover off the cost of the distribution, the proposal will be removed and no further payouts will occur. Any extra funds that remain after accounting for returning his personal funds will be returned directly to the DHF.
@Howo has created the distribution script and encourages you to review it: https://github.com/drov0/restore-hf23-balances. If you are an impacted user, you may have gotten a test memo while preparation for this has been going on. This proposal truly is the best of both worlds for correction. It recognizes the importance of an immediate solution for these users with no security impacts on the ecosystem at large, but for it to happen we do need to support this proposal and @blocktrades for stepping up to make it possible. Please vote on this proposal using the links below:
- https://peakd.com/me/proposals/133
- https://wallet.hive.blog/proposals (#133)
- https://hivesigner.com/sign/update-proposal-votes?proposal_ids=%5B133%5D&approve=true (Hivesigner direct approval link)
A note on the daily amount chosen:
The 4750 HBD amount was calculated using the daily budget, which is the amount distributed daily to funded proposals. It was very important to make sure that no currently funded proposals would be be bumped out by this one, but also to pay @blocktrade's trust back as quickly as possible. Part of hardfork 24's new code is the slow conversion of the DHF's liquid into available proposal funds over time, so there is an increasing amount available daily. This will allow us to strike a balance on speed of repayment while making sure that there is still room for all other proposals to continue unimpeded.