Tokenomics Beta1

From Meson Labs

Since the launch of the Meson Testnet, we have gone through several iterations for the version. The number of miners and network usages have far exceeded our expectations. As a result, we are ready to release the Tokenomics-Beta1 and apply it on the Meson Testnet. The following contains information on several key modules and issues. Since the crypto world is still relatively early and rapidly progressing, our model may be subject to further improvements and parameter adjustments based on actual data collected throughout the testing period. Enjoy.

Decouple the supply/demand and the speculation

We have noticed some design problems in the existing economic system, which we will discuss in further details here.

Problems in Ethereum

The Ethereum token model is designed while taking into consideration the two major factors that can influence a token economy — the supply/demand of the token and the level of market speculative activities (speculation is a neutral term here, expressing situations outside of supply and demand, such as secondary market operations).

When we use a service, the pricing of the service should be primarily determined by supply and demand. However, when using Ethereum’s services, we find that the price (in stablecoin terms) is very cheap in the early days of use. As Ethereum’s popularity grows and its applications become more popular, the price (in stablecoin terms) that users pay for the same service rises dramatically. If we only look at the supply and demand aspect of the service, the magnitude of the price impact should be much smaller than the actual price fluctuations that users now perceive. However, the mechanism is designed in such a way that a large amount of market speculation is directly reflected in the ether price, and the demand side uses the service in ether as the local currency, resulting in users being forced to bear the price premium to the services.

From this we can see an interesting phenomenon. When Ethereum is not well-known, the service price is very cheap. When Ethereum became more famous, the token price rose sharply. At this time, users found that they could not afford the service and were forced to look for alternatives (e.g., Polygon). When the usage and popularity of the alternatives increase, users find that they cannot afford to use the alternatives anymore and are forced to continue this counter-productive cycle.

More applications and more market acceptance can lead to higher token prices, but higher token prices drive up the price of services and, to some extent, suppress demand, which in the long run causes the network to lose value and leads to lower token prices. The paradox is thus formed.

How to pay for the fees

Regarding the question of how users pay, we tend to be product and service-oriented with two custom-designed characteristics. First, the product is denominated in stable currency, and users do not need to worry about drastic changes in service prices due to currency price fluctuations. Second, users can use any token they like to pay for and use the product, including ether and various ERC20-compatible tokens. In the future, we will gradually support more non-ERC20 standard tokens as well. When users use Meson native token to pay, they can be granted a discount on service.

How to distribute the fees (demand side)

Regarding the question of how to allocate the fees being generated from the demand side, let’s first look at the types of allocation methods. The first one is allocated to the direct provider of the service. The second one is to convert the revenue and token in a certain way.

For the first approach, we can look at a platform like Uber. The passenger pays the fare, of which about 80% goes to the direct service provider (driver), and 20% flows to the platform and is reflected in Uber’s share price to some extent. For the second conversion method, several existing models can be referred to. One is the BNB token model, where the revenue from the product (the bulk of which is the exchange fees) is bought back and burned every quarter. The second is the ETH2.0 token model, where the system calculates the number of tokens required for users to use the service, burns them in real-time, and then gives certain tips directly to the service provider. The third is the approach adopted by Helium, where the $HNT assumes the role of a channel fee. Users pay stablecoin $DC to use Helium services, and $DC can only be exchanged by $HNT. The number of generated $DCs and the destroyed $HNTs have the same value in the stablecoin niche.

The method we adopt is based on the Burn & Mint mechanism, combined with the characteristics of the Tips from ETH2.0. For the demand side, users’ basic fees are denominated in stablecoins, and the system calculates in real-time. Users can use a variety of tokens to pay, and this part of the fee will be converted into Meson Token and destroyed to generate equivalent Meson Credit. Meson Credit and USD have a fixed conversion ratio. Users can get a 5% discount if they pay Meson Credit directly. At the same time, users can also choose to pay a certain amount of Tips in exchange for more benefits from the service provider (e.g., higher processing priority, longer cache time, etc.), and the Tips are paid directly to the node hosting the service.

How to decouple the supply side with native token

In Meson’s system, we further discuss the type of currency paid to the supply side (node). All payment fees, all token payments, or a certain mix. We first consider two edge cases: 1) If there is no use on the demand side, then only tokens may be valuable to the supply side, similar to the situation of Ethereum in 2015–16. 2) If the demand side is enormous, then under a reasonable economic model design, the service fee on the demand side will be reflected in the token price. At this time, for the supply side, only tokens can be good enough. It can be seen that in two edge cases, it’s possible to pay no fees. For the middle part, is it necessary to do a certain mixing ratio, such as 50% token and 50% fee?

We can change our thinking on this problem. Under the background of the above mechanism, if we need to achieve the goal of a 50% fee, we can actually solve it through the inflation rate. If the total amount of tokens issued to miners after convergence equals the number of tokens in the genesis block, miners will get 50% token + 50% fee in disguise. Therefore, the solution we adopt is only to pay tokens to the miners and add a small part of the tips mechanism in exchange for additional services (such as longer cache time, higher priority cache queues, etc.).

The price for the Service

The pricing of services, we address the issue in two phases.

In the first stage, a fixed price is adopted. Similar to mainstream cloud vendors, we will provide a price based on bandwidth usage and volume in different regions. We expect the price to be less than 1/10 of mainstream manufacturers.

In the second stage, market matching is adopted. This method is more similar to the orderbook, where both parties in the market quote on demand and match on the Meson side. There are significant benefits to be gained from using the orderbook matching model. For example, we cannot accurately calculate the cost price of users on the supply side. When the demand side quotes 100 units, all supply nodes can benefit from it and provide services; when the demand side quotes 50 units, some supply users are forced to leave but the cloud Manufacturers can continue to make profits; when the demand side quotes 10 units, most users cannot cover the cost but operators (Telecom) can still continue to make profits. Thus, the model essentially provides a free market where prices for services are matched by supply and demand. In view of the performance factors and user convenience of existing on-chain matching, we first adopt a fixed pricing model in this version.

One token or two tokens model

We use the scheme of the single token model.

The inflation rate for the supply side

Regarding the inflation rate, the network will issue a certain percentage of tokens to miners every year. We have observed that the inflation rate sometimes has problems deviating from actual development. For example, some projects issued most of the tokens to miners in the early stage. As a result, when the actual adoption of the project broke out, due to the small proportion of tokens to be distributed, it was not easy to increase the volume of supply-side nodes. Therefore, we decided to match the inflation rate with the actual network conditions and modify the rate in due course. Then how to modify the inflation rate becomes the next problem.

A relatively simple solution is to do a governance poll. The token holder participates in voting according to certain rules and modifies the parameters regularly. This program looks democratic at first glance, but ‘Where one stands depends on where one sits.’ For example, miners will choose to increase the inflation rate, while other token holders will decide to reduce the rate. Another solution is that we set the rules for the change, just enter the parameters regularly and modify the inflation rate. For example, the token price and burn rate are used as parameters, and the fixed function Func(token price, burn rate) = K * burnRate / tokenPrice is modified yearly according to the calculated value. We will adopt the latter scheme, which combines the inflation rate with the actual development on the one hand and avoids the concentration of rights on the other hand while making the rules fairer.