From token economy to codes

Published in

hdac_rizon

7 min readApr 17, 2020

Understanding formula type design with codes

Our previous posts (Ecosystem, PoP) 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 GitHub. Feel free to send us feedbacks on our Discord or Forum 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.

It calls out staking and delegation tables
Updates parts that need an update
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.

Does the user votes with 0 token?
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.

Where
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.

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 Data types on blockchain 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 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.

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.

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

Below is a graph of the formula above.

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.

Conclusion

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.