Menu Open

search result

Frequently Searched Words
Menu Close


Latest News

Stay updated with the latest news and event on RIZON

Developers’ Journal

From token economy to codes

Apr 17th, 2020
Image for post

Understanding formula type design with codes

Our previous posts have looked at our philosophy to design a token economy. In this post, I would like to explore the details on how the philosophy is implemented.

Smart contracts for the new mainnet system contract (hereinafter system contract) are written in Rust. It compiles Rust’s binary with WebAssembly rather than executing it right away using Contract SDK of Casperlabs. Our codes are published on https://github.com/hdac-io/CasperLabs/tree/master/execution-engine/contracts/hdac-system/pop. Feel free to send us feedbacks on our https://discord.com/invite/cuqdZn or https://forum.hdac.io/  if the codes do not match our design, not reflect our philosophy or if you have opinions to further develop our philosophy. Your valuable opinion will help us improve our project.

Actions that a holder can take after staking: Delegation and dApp vote

Holder can delegate and vote to dApp after staking.

A part of delegation logic

Let us look at the delegation codes first. Once executed, delegation finds a wallet holding staked tokens in the system and sends out tokens to stake. (Bonding is basically the same thing as staking.)

A part of applying delegation with staking(bonding)

This part reflects staking application in snippet’s logic.

  1. It calls out staking and delegation tables
  2. Updates parts that need an update
  3. Records updated tables in the system again.

Votes are similar to this.

A part of voting logic

Those who designed a smart contract would know, but the part that practically carries out vote() is below.

The simple but core part of voting logic

But the codes become longer due to the part that tests and processes several conditions before executing this logic.

  1. Does the user votes with 0 token?
  2. Does the user votes more than the staked amount? (Current logic designates a delegated validator for delegation, which becomes the amount to be staked. That is why delegation information shows the staked amount of the current user.)

Validator selection through delegation: PoP score calculation methods and rewards

A holder delegates a validator and selects the 100 most delegated validators. Selected validators receive rewards for each block by maintaining networks.

  • Rewards for each block are based on 5 percent inflation per year.
  • The rate of rewards is decided based on the ratio of a validator PoP score and top 100 validator PoP scores.
  • PoP score = (Profession score) X (PoS factor)
  • A profession score is a score decided based on the contribution of validators for network stability and ecosystem development. The score can be decided on legislation, participation in voting on bills, errorless network maintenance, ecosystem dApp development and more. But currently all scores are 1 as score categories, ratio and acknowledgment methods can only be decided after gathering the genesis validator’s opinion.
  • PoS factors are as below.
Image for post

x: [ (delegated amount that the validator received) / (delegated amount that top 100 validators received) ] X 100

We use the PoS factor to stand against monopolies while acknowledging capital. Our method acknowledges the delegated amount but drastically slows down the delegation power increase rate when it reaches the point of monopoly. This would prevent votes from being disproportionately concentrated, spread them to validators, allow validators who reached the point to save unnecessary marketing costs and focus on other activities in the ecosystem.

First, we defined ‘monopoly’ as ‘a status where more than 15 percent of the total staking is delegated.’ If the percentage is too high, our intention is not reflected, and if it is too low, copied accounts could cut off opportunities of other validators as validator accounts could be mobilized for more volume (Sybil attack). We thought six to seven validators would let us trust the network, which was why we set it at 15 percent.

We used the natural log at first to weaken the delegation power. It is a well-known method which continues to increase the power but drastically decreases the speed. That is why we used the formulas below.

Image for post

Some might think they are based on complicated logics as the numbers look complex. But it is fairly simple. It was derived from the point where the natural log formula continues at x=15 and the slope continues without an inflection point (so that its differentiate is also continuous). The result is complicated even though the principle is simple. We tried to apply this formula to the actual system contract. But we cannot directly use float operation such as ln() in a smart contract. What would be the reason for this?

It is due to the characteristics of blockchain that needs to guarantee the same result in any environment. If nodes operating in 64-bit Ubuntu and those operate in CentOS have different results, it would be against the principle of blockchain. But float could lead to slightly different decimal points in different environments, which could end up in different results. Therefore, smart contracts prevent the use of floating points. (It is explained in our previous post and will be mentioned again in upcoming posts.) Rust development environments set restrictions using the #![no_std] attribute. This attribute imposes restrictions on the use of the standard library to eliminate the risk of environmental dependency blocking execution. (We plan to develop a decimal point operation library using integer operation to break away from this restriction.)

We looked at Taylor’s theorem to implement ln()as a method to circumvent this issue even though it would not be a perfect solution. But it was only valid in the 0 < x < 1 range and the direction was decided based on the sign that the term of the maximum degree adopted in the 15 < x <= 100 range. In the end, we decided to change the formula. We used sqrt()(often referred to as a square root) instead of ln(). We have no choice but to use float as square roots are usually a decimal, but we implemented the https://en.wikipedia.org/wiki/Integer_square_root for this. This multiplied the result by 1000 times and represented three decimal places, which resolved the issue of not being able to use decimal places. We found that the alternative formula was almost the same as the original.

Image for post

Let’s how this is written in codes. Below is a part calculating the PoP score.

PoP score calculation

Some might ask why we chose complicated implementation without using x after declaring x above. It is because division eliminates decimal places in an integer environment. For instance, we get 3 instead of 3.5 by dividing 7 by 2. That is why division is carried out after multiplication to represent numbers as much as possible.

Inflation calculation

The block reward inflation rate is 5 percent. Five percent of the currently issued amount is calculated before calculating block rewards and recording it in variables in the system contract.

Validator rewards are decided by calculating the sum of top 100 delegation validator scores and the stake of each validator. Validators get 30 percent of the total rewards, while users who delegated get the remaining 70 percent. The part given out to users is as below.

Benefits of receiving dApp votes: Discounted gas fee

Let’s look at the discount formula of gas fees arising from dApp votes. Just like validator delegation, the optimal discount point was used here.

Example of discount rate research

I came across a marketing research case on discount rate while doing research on the optimal point of discount rates. It showed discounts became ineffective when they were 50 percent or higher because they put too much focus on discounts. That is why we set the optimal point at 30 percent and the maximum at 50 percent.

How many votes are valid?

We still need to decide on the number of votes to reach the optimal point of 30 percent. We assumed it was 28 million token votes and used logarithmic functions. We tried to implement a logic that makes discounts valid only when they gather a certain amount of support and prevents the discount rate from going above a certain level. The formula we derived after research is as below.

Image for post

x = the number of votes received
m = 87,000,000

Below is a graph of the formula above.

Image for post

We will present codes for this after finding workarounds that can implement decimal points through integers as the log cannot be implemented in smart contracts.

There is an unstaking period that changes based on the ratio of staking, but I will leave that part for those who implemented it.


Those who are not good with numbers or have no background in development wil have a hard time understanding codes and formulas. But it is impossible to explain the economy without those. I tried to explain it with words rather than numbers to facilitate comprehension. I hope it was helpful. If you managed to read through this point, it worked.

As I said above, your opinion would be greatly appreciated for us to improve our projects. Please leave comments on this post or tell us your opinion in the Discord or Forum community.

Please look forward to our next post.

Special thanks to

Token economy TF: Steve KIM, Bryan RHEE, and Yeon HWANG

Team Future tech: Derek MOON, Joonho YEOM, Seunggoo YOON, Joowon YUN, Bryan RHEE, Sooyoung HA, Jiyong HA, and Yeon HWANG


[1] The economics of Money, Banking, and Financial method, Frederic. S. Mishkin (2017)

[2] https://en.wikipedia.org/wiki/Integer_square_root

[3] https://rust-embedded.github.io/book/intro/no-std.html

Official Channels
Website - https://www.hdactech.com
Medium(Global) - https://medium.com/hdac
Medium(Korean) - https://medium.com/hdackorea
Facebook - https://www.facebook.com/hdacrizon
Twitter - https://twitter.com/hdac_rizon

Official Communities
Newsroom(Global) - https://t.me/rizon_atolo_news_en
Community(Global) - https://t.me/rizon_atolo_en
Newsroom(Chinese) - https://t.me/rizon_atolo_news_cn
Community(Chinese) - https://t.me/rizon_atolo_cn
Newsroom(Korean) - https://t.me/rizon_atolo_news_kr
Community(Korean) - https://t.me/rizon_atolo_kr

For Developers and Validators
GitHub - https://github.com/hdac-io
Discord - https://discord.gg/K77bGc6


1. Introduction.

Hdac Technology AG respects the privacy of its Members, Contributors, Users or Clients and is dedicated to controlling the use and disclosure of information provided by Members, Contributors, Users or Clients using the Site. This Privacy Policy (the “Privacy Policy”) sets forth Hdac Technology AG’s policies regarding collection, storage, access, use and disclosure of information relating to a Member’s, Contributor’s, User’s or Client’s registration and use of the Site. Any terms not defined herein shall have the meaning set forth in the Terms & Conditions, the Transaction Terms & Conditions or the User Agreement.

2. Information Collection, Use And Disclosure Activities.

2.1 Registration Information.

To ensure that only legitimate entities and individuals are able to access the non-public areas of the Site and enter into transactions, we require each potential Member, Contributor, User or Client to, by using the Registration Page on the Site, provide (i) information regarding themselves (including name, e-mail address, job title, work address and work phone number), and (ii) information regarding their Company (including Company name and parent Company’s name and address). Upon receipt of Your registration data, Hdac Technology AG may contact You or Your Company to obtain other background information used by Hdac Technology AG to evaluate an applicant's qualifications for Membership, Contribution and/or Participation. Other than as specified in this Privacy Policy, the registration information will be used only internally by Hdac Technology AG and will not be disclosed to third parties without the applicable Member’s, User’s or Client's prior written consent. Notwithstanding of the before mentioned, Hdac Technology AG is obliged to report suspicious transactions and facts about individuals including Contributors to the relevant authorities without further notification and without becoming liable for any damage such action may cause.

2.2 References.

In addition to the information specified in Section 2.1, Hdac Technology AG may require Members, Contributores, Users or Clients or prospective Members, Contributors, Users or Clients to provide Hdac Technology AG with Company references to allow Hdac Technology AG to verify a Company’s capacity, legitimacy and reputability. Hdac Technology AG may provide such references to parties with which a Member, User or Client enters into a Negotiation to assure such parties that Company can meet its prospective obligations thereunder.

2.3 Member, Contributors, User or Client Profile.

Each Member, User or Client will create a Member, Contributor, User or Client profile that includes, among other things, information about this Member, Contributor, User or Client. Information in a Member, Contributor, User or Client profile are accessible only by the applicable Member, Contributor, User or Client, the Member, User or Client’s Group Administrator and Hdac Technology AG. Certain Member, Contributor, User or Client profile information will be provided to the parties engaged in a Negotiation in accordance with Section 2.5. Other than as permitted under this Privacy Policy, Member, Contributor, User or Client profile information will not be disclosed to third parties without the applicable Member, Contributor, User or Client's prior written consent.

2.4 Member, Contributor, User or Client Information.

(a) Hdac Technology AG may collect, use and disclose both on and off the Site, for marketing and other purposes, certain general, demographic and statistical information regarding Site usage and transactions. (b) To assist Member, User or Clients in selecting companies they may do business with through the Site, Hdac Technology AG may make available to Member, Contributor, User or Clients and non-Member, Contributor, User or Clients certain performance statistics of all Companies, provided that such statistics shall not include any Company-identifiable pricing information.

2.5 Technical and Usage Information.

To operate the Site, enhance its functionality, and ensure that Members, Contributors, Users or Clients Negotiations and communications are convenient, dependable and secure, Hdac Technology AG may collect, store and use technical and Site usage information relating to a Member, Contributor, User or Client's activities on the Site. Such information includes the Internet Protocol (“IP”) address from which a Member, Contributor, User or Client accesses the Site, which is used only internally by Hdac Technology AG as required for server operation and other technical uses, and is not disclosed to Members, Contributors, Users or Clients or other persons. Hdac Technology AG may also track the pages of the Site accessed by Members, Users or Clients.

2.6 Member, Contributor, User or Client Communications.

Hdac Technology AG may use Member, Contributor, User or Client contact information, such as e-mail addresses, to communicate with Members, Users or Clients regarding registration and transactions, to notify Members, Contributors, Users or Clients of changes in Site functionality and features, product and service updates, policy changes, billing and other activities relating to a Members, Contributors, Users or Client's use of the Site, and for marketing purposes.

2.7 Legal Compliance.

In addition to the disclosures permitted pursuant to this Privacy Policy, Hdac Technology AG may provide Member, Contributor, User or Client information in connection with legal, administrative or judicial inquiries, claims or orders to the extent necessary to comply therewith or to enforce a User Agreement.

3. Collection And Use Of Information Using Cookies.

As with many state-of-the-art Internet sites, the Site uses “cookies” to enhance the functionality of the Site and to make transactions and other activities more convenient and efficient for Members, Contributors, Users or Clients. A “cookie” is a file stored locally on computers used to access the Member, Contributor, User or Client account that contains information relating to a Member, Contributor, User or Client's past use of the Site. For example, a cookie may contain information previously entered on a Site form, which may be recalled as default information when that form is accessed at a later time. This prevents re-entry of frequently used information each time a Member, Contributor, User or Client account is accessed. Cookies are also useful in streamlining log-in and in preserving transactional information between sessions. Cookies will likely play an increasingly important role as we enhance the ability of Members, Contributors, Users or Clients to customize the functionality of the Site to better meet their needs and preferences. Most Internet browsers include preference settings that allow users to be notified and control whether cookies are transferred to their computers. Please review Your browser's documentation or “help” feature for more information on that functionality. Although disabling cookies will not affect a Member, User or Client's ability to transact business on the Site, it may make such activities more time consuming.

4. Linked Sites.

The Site may contain hyperlinks through which other Internet websites may be accessed by Members, Contributors, Users or Clients. Hdac Technology AG is not responsible for and cannot make any assurances regarding privacy, or other policies or practices of the operators of such websites. Such links are provided only for the convenience of our Members, Contributors, Users or Clients, and the presence of any link does not imply that Hdac Technology AG endorses, approves or is responsible for such websites.

5. Security.

Hdac Technology AG is very concerned with the security of information relating to our Members, Contributors, Users or Clients' use of the Site and has implemented systems and procedures to prevent unauthorized access to that information including the use of Secure Sockets Layer (SSL) connection and password protection. Each Member, Contributor, User or Client will create its own username and password, the secrecy of which is the sole responsibility of the Member, Contributor, User or Client. In the event the integrity of a Member, Contributor, User or Client’s password is compromised, the Member, Contributor, User or Client shall immediately change its password.

6. Updates To The Privacy Policy.

Hdac Technology AG may update this Privacy Policy from time to time as new features and services become available on the Site and to keep pace with technological developments. The new terms shall be effective ten (10) days after they are initially posted on the Site. It is the responsibility of the Member, Contributor, User or Client to review the latest terms. If You do not agree with updated Privacy Policy, You should immediately cease use of the Site and the Services.