In today’s post, we will provide you with a summary of the changes in the Velocity Hardfork (i.e. Hardfork 20). The goal of this post is to be the definitive guide for all of the changes included in the Hardfork which is scheduled to take place on Tuesday, September 25, at 11:00am EST. The changes in the Velocity Hardfork are dependent on the approval of a super-majority (17/21) of the witnesses voting in favor of the Hardfork.
One of the major changes in the Velocity Hardfork is a change from our existing Bandwidth system to a new-and-improved system based on Resource Credits (RCs).
Steem is one of the only freemium blockchains in the world. The new RC system will make it the most advanced freemium blockchain in the world without compromising the existing features and functionality that make Steem such a powerful platform for building DApps.
The details of how this new RC system will work are described in our recent post Blockchain Update 4: Resource Credit Implementation Details.
GitHub Issue 2457, GitHub Issue 2511, GitHub Issue 2512, GitHub Issue 2521, GitHub Issue 2549, GitHub Issue 2563, GitHub Issue 2600, GitHub Issue 2621, GitHub Issue 2624, GitHub Issue 2625, GitHub Issue 2626, GitHub Issue 2627, GitHub Issue 2631, GitHub Issue 2546, GitHub Issue 2547, GitHub Issue 2648, GitHub Issue 2649, GitHub Issue 2650, GitHub Issue 2679, GitHub Issue 2685, GitHub Issue 2694, and GitHub Issue 2703
The primary goal of the Velocity Hardfork is to change the account creation system in order to lower costs and improve the new user onboarding process.
The Velocity Hardfork will give users the ability to create new accounts at a discounted rate, potentially without having to pay any STEEM or delegate any Steem Power in order to create the account. When creating a new account, users will be able to use RCs instead of a portion (or all) of the STEEM account creation fee.
The RCs that get spent when creating discounted accounts are the same RCs that get consumed when users interact with the blockchain. This limits users’ abilities to interact with the blockchain when they run low on RCs. Users (especially ones with a moderate-to-low amount of Steem Power) should be careful not to spend too many of their RCs on creating discounted accounts, otherwise they won’t be able to interact with the blockchain until their RC mana recharges.
GitHub Issue 1771, GitHub Issue 1772, GitHub Issue 2651, GitHub Issue 2700, and GitHub Issue 2710
The blockchain will have a global pool of Discount Account Creation tokens that will represent the amount of discounted accounts that can be created. Every time a user creates a new account by paying a portion (or all) of the fee with RCs instead of STEEM, one of the tokens will be consumed. If there are no tokens left in the pool, then no additional discounted account creations will be allowed.
The number of new Discount Account Creation tokens created each day will be controlled by the witnesses. The reason that the supply of account creation tokens is entrusted to the witnesses is because they are incentivized to ensure that the rate at which new accounts are created does not place an undue burden on the blockchain.
The total number of tokens allowed at any one time will also be controlled by the witnesses. This is to prevent an excessive amount of tokens from accumulating if there is insufficient demand to use them up.
GitHub Issue 1770, GitHub Issue 2628, and GitHub Issue 2688
In keeping with our preference to leverage markets to manage the complexities of resource allocation, the cost of creating discounted accounts (using RCs) will vary based on an internal market.
When the available supply of discounted accounts is low and/or the demand for them is high, then the amount of RCs that will need to be used in place of the STEEM account creation fee will be high. When the available supply of discounted accounts is high and/or the demand for them is low, fewer RCs will be needed to replace the STEEM account creation fee.
It should be noted that based on the supply and demand of available discounted accounts, it may only be possible for Power Users (those who hold a lot of SP) to be able to afford to create a discounted account.
GitHub Issue 1767 and GitHub Issue 1769
Instead of powering up the account creation fee to new accounts, it will be "burned" by transferring it to the null account.
After the Velocity Hardfork, it will no longer be possible to create accounts using a delegation of Steem Power, since the account creation fee will be burned. Therefore, the account_create_with_delegation operation will be deprecated.
Users will still be able to delegate SP to other users via the standard delegation procedures.
When we originally added support for creating accounts with delegated SP, we changed the way that the witness account_creation_fee was used to allow for a portion of the fee to be paid with a 5x delegation of Steem Power. With this change, the price of creating an account without delegated SP became 30x the account creation fee. For example, currently the account creation fee is 0.1 STEEM, and it costs 3.0 STEEM to create a new account.
Since creating accounts with delegation will no longer be supported, there is no longer a need for the additional complexity of multiplying account creation fees. We will be rolling back the change to multiply the fee by 30x. For example, if the witnesses set the account creation fee to be 3.0 STEEM, it will cost 3.0 STEEM to create an account.
At the time of the Hardfork, there will be a one-time, 30x change made to each of the witness’s account fees, so that the price of creating an account will not drop by 30x when the Hardfork occurs. For example: if all of the witnesses have their account creation fee set to 0.1 STEEM at the time of the Hardfork, they will all be changed to 3.0 STEEM when the Hardfork takes place, so that it will still cost 3.0 STEEM to create an account. After the one-time 30x update occurs, the witnesses will be able to update their account creation fees normally from then on.
The Dust Vote Threshold is a rule that prevents the occurrence of extremely weak votes and was implemented to combat blockchain bloat. Currently, accounts must possess about 1 SP for a 100% Voting Power vote to successfully post to the blockchain. If a vote below the required threshold is placed, it is rejected by the blockchain. This can create a bad user experience for new users, as their votes can fail for seemingly no reason.
The Velocity Hardfork will change how the Dust Vote Threshold works by allowing users with any amount of SP to cast votes as long as they have sufficient RCs. Votes that are below the threshold will be posted to the blockchain but they will have no impact on rewards. This will allow users to have a better user experience on all Steem-based applications by enabling them to vote any time they choose (regardless of the size of their vote), provided that they have enough RCs.
This change will make very weak votes become worth nothing. In order to treat all votes (big and small) equally, all votes above the threshold will have the equivalent amount of rewards removed from their vote. This effectively establishes a baseline voting strength that applies to everyone. In addition to making it more fair, there is also the benefit of introducing a slight non-linear rewards curve at the lower end of the spectrum (to discourage spam), while still maintaining a linear rewards curve for votes above the baseline.
GitHub Issue 1764 and GitHub Issue 2515
Currently, accounts with less than 10x the current account creation fee (in SP) are prevented from powering down by the blockchain. This was designed to prevent people from creating new accounts only to immediately power them down.
After the Velocity Hardfork, the account creation fee will be burned instead of powered up to the new account. Because the new account will not be receiving any SP, there will be nothing to power down other than any SP the account creator purchases. For this reason, the 10x requirement will be removed.
Steem account holders (including bot accounts) are currently disincentivized by the Steem blockchain from voting on a post within the first 30 minutes. The earlier a vote is made within the initial 30-minute window, the less curation rewards the voting account receives. This was originally introduced to even the playing field between human curators and bots during a time when the majority of the content on Steem was long-form written content.
While successful, much has changed on Steem since that time. Steem now hosts all kinds of content, and powers hundreds of decentralized applications which dramatically expand the types of content that can be consumed on Steem. Because of this, the community and the witnesses have come to a consensus that the 30-minute rule is taking curation rewards away from human voters who are actively consuming content and voting on material they like. For this reason, the Velocity Hardfork will reduce the curation window from 30 minutes to 15 minutes.
According to the current blockchain rules, if authors vote for themselves immediately, they get their author rewards, 100% of the curation rewards from their vote, and a portion of the curation rewards coming from everyone who votes for the post after them. Any other curator voting at the same time as the author would get 0% of the curation rewards. This gives the author an unfair advantage over other curators, because the author can earn additional curation rewards through self-voting.
In order to eliminate this advantage, the portion of curation rewards that is not given to the curators due to the early voting penalty will be returned to the rewards pool instead of being awarded to the author, thereby increasing the overall percentage of rewards paid to curators. This will better serve the original mission of the curation rewards budget: to ensure that the Steem blockchain distributes rewards to the most valuable content.
The current implementation of the internal market dictates that limit orders are never forced to expire. This allows users to submit orders to the internal market which require long-lived consensus bandwidth, degrading the overall performance of the blockchain. After Velocity, the blockchain will require that all internal market orders expire after 28 days. This is consistent with the implementation of order books on many of the major exchanges. Existing limit orders will have their expiration capped to 28 days after the Hardfork.
These changes apply primarily to the witnesses.
The Velocity Hardfork will make an update to the requirements for witness price feeds. Price feeds will now require the base to be SBD and the quote to be STEEM. Price feeds that report the base as STEEM and the quote as SBD will be rejected.
A new witness_set_properties operation will be added. It will allow witnesses to update individual parameters instead of needing to do an update_witness call with everything all at once. The operation will support: account creation fee, max block size, sbd interest, signing key, and witness URL. Witnesses will also be able to submit price feeds using the new method.
This new operation will authenticate against the witness’s signing key instead of their active key. This means witnesses who submit their price feeds using the new operation will now be able to to submit them using their signing key. This provides a security benefit to the witnesses, since they will no longer need to store their active key on any of their servers.
The current witness update operation will remain functional, but new witness parameters will not be added to it. It is important for this operation to remain functional as it provides a method to update the witness signing key with the account's active authority.
GitHub Issue 352 and GitHub Issue 1620
Witnesses will be able to set the maximum block size for blocks accepted by the Steem blockchain. The Peer to Peer (p2p) protocol, however, will have a 2MiB limit on the size of a block that the p2p network can process. Witnesses should not be able to set the value higher than what is allowed by the p2p network.
In order to prevent witnesses from allowing blocks above this 2MiB limit, we are adding a maximum 2MiB limit on the maximum block size parameter submitted by the witnesses.
GitHub Issue 1655 and GitHub Issue 2642
Witnesses will have two new witness parameters to submit. The account_subsidy_daily_rate will control the amount of discounted account creation tokens that are added to the global pool daily. The account_subsidy_pool_cap will control the maximum number of discounted account creation tokens allowed in the pool. These values will be submitted via the new witness_set_properties operation discussed above.
GitHub Issue 1765 and GitHub Issue 2688
The 20-second limit on comments will be removed as part of the Velocity Hardfork. The blockchain will now allow a new comment every block (once every three seconds), which is the same restriction placed on voting. Special thanks to community developer 
Two users reported exploits where an account could gain extra voting power by using all of their voting power, and then delegating their SP to another account, or powering down and powering up again into another account. We will be including fixes for these exploits as part of Velocity. More technical details on the fixes can be found here.
GitHub Issue 2428 and GitHub Issue 2539
As part of the changes we will be making for the double voting exploits, we will be able to decrease the cooldown period for SP delegations from seven days to five days. This means that after a user undelegates SP from another user, it will only take five days for the SP to return to their account and become available for use again.
As part of the fixes we are making for the double voting exploits, we will also be increasing the precision of voting power (now voting mana). This will increase the number of votes that an account can make with less than 2% voting power, since the blockchain will now be allowing more granular votes.
Even though the account creation fee is burned, accounts created after the Velocity Hardfork will still be able to transact with the blockchain with zero SP, because the burned SP will still be counted towards their RC balance calculations.
GitHub Issue 2488 and GitHub Issue 2595
In Hardfork 17, a change was implemented to prevent upvote abuse by creating a twelve-hour lock-out period at the end of a post’s payout period. During this time, users are no longer allowed to upvote the post. This prevents users from hiding a self-vote at the end of the payout period and exploiting the rewards pool. However, users retained the ability to downvote as a safeguard against the scenario where a user self-votes immediately before the beginning of the 12-hour lockout period. Though uncommon, this created an opening for malicious users to wait until the lockout period to issue punitive downvotes so that they couldn’t be countered with upvotes.
Velocity will address this potential scenario by modifying the lock-out to a cool-down. After Velocity, upvotes and downvotes will both be allowed during the last 12 hours of the payout period, but their strength (for the same amount of voting power) will decrease linearly from 100% to 0% over that 12-hour period. In other words, it will take twice as much voting power to have the same impact on a post’s payout if the vote is done with only six hours left on the payout window instead of twelve. An upvote or downvote cast during the last minute would have virtually no impact on a post’s rewards.
This change will help ensure that no matter when a post receives an upvote or downvote, users will be able to counter-vote. This will also help to stabilize the potential payout of posts during the last 12 hours by decreasing the strength of votes as it gets closer to the payout time.
Community developer 
In Hardfork 14, rules were added to reduce the SBD print rate when the “debt ratio” (amount of SBD tokens in existence / the STEEM market cap) was above a certain percent.
Under the new rules, SBD tokens will continue to be printed unless/until the debt ratio reaches 9% of the STEEM market cap. Between 9% and 10%, liquid payouts will shift linearly from paying 100% SBD and 0% STEEM at 9%, to paying 0% SBD and 100% STEEM at 10%. This works the same as the shift that occurs today between 2% and 5%.
When an author chooses the “50/50 payout” on their post, they will receive 50% of their rewards as SP, and the other 50% as “liquid payout”. The liquid payout is typically in the form of SBD, but it will sometimes pay a portion (or all) in liquid STEEM if the debt ratio is sufficiently high. The author also has the option to select being paid 100% in Steem Power.
Currently, if an author adds beneficiaries to their post, the beneficiaries will be paid in 100% Steem Power, regardless of which selection the author made for their rewards. After Velocity, beneficiaries will be paid using the same payout setting as the author.
To solve transaction malleability, Steem enforces “canonical” ECDSA signatures. The canonical ECDSA signatures that Steem uses are a subset of a more widely used BIP-0062 canonical signature system.
We will update our canonical signatures to use the BIP-0062 method, so that our signatures can be more easily understood by outsiders, and to make integration with the Steem blockchain easier for third-party developers who may be reusing code from other blockchains that use the BIP-0062 method. This also opens up the rest of canonical search space, which increases the entropy, and therefore security, of our signatures.
Velocity will not support the creation of accounts via mining. Instead, Velocity will include the changes necessary to enable account mining on Steem via softfork at a future date. The reason for this is that the many attempts at “ASIC resistant” algorithms have failed to curb ASIC implementations. Until we can come up with a reasonable PoW scheme that is accessible by end users without being easily exploitable, we felt it would not be a good idea to include PoW for account creation. We decided it was much more important to get the Velocity Hardfork completed and add support for discounted accounts ASAP. Since the feature can be added at any time in the future without a hardfork, we have the flexibility to add it once we find an acceptable algorithm.
One of the main things that will be changed in Velocity so that mined accounts can function properly once implemented, is preventing mined accounts from having a default account recovery partner. Because a second-party is not involved in the account creation process, there is nobody to designate the account recovery to if the account is stolen. If a user with a mined account wants to take advantage of the account recovery process, they can designate a willing party as their recovery partner after the account is created.
These are highly technical changes to improve the maintainability of the Steem code base. Those interested can read the details in the corresponding GitHub links.
GitHub PR 2692, GitHub PR 2693, and GitHub Issue 683
Community developer 
at least one account must be specified.
Challenging Authorities was a system devised in the summer of 2016 that was never fully released. The proposal would enable a user to pay a small fee to challenge the authority of another user— forcing them to sign a transaction with a higher level authority to prove they continued to have control of a key. Were this feature implemented, it could have led to a scenario where an innocent account holder was forced to remove their keys from cold storage by a malicious actor. For this reason, Velocity will remove the extraneous code related to this feature.
We will be launching a Velocity Hardfork testnet prior to the mainnet Hardfork date, which will give developers the opportunity to test the upcoming changes in a non-production environment prior to launch. We will provide the details on this testnet once it is ready for public use.
A majority of the development for the Velocity Hardfork has been completed and can be reviewed under the project/hf20 tag in the Steem GitHub repository. The issues are also being tracked via our project board here.
The Hardfork is scheduled to take place on Tuesday, September 25, at 11:00am EST. The changes in the Velocity Hardfork are dependent on the approval of a super-majority (17/21) of the witnesses voting in favor of the Hardfork.
We will be tagging the Hardfork release on or prior to August 25, which will give witnesses and node operators at least 30 days to review and test the changes, and apply them to their nodes prior to September 25.
We are confident that these changes will be major improvements to the Steem blockchain, making Steem even better than before.
Steem on,
The Steemit Blockchain Team
