Tokenomics Beta1

From Meson Labs

Since the launch of the Meson Testnet, we have gone through several major iterations. The level of miner participation and network usages have far exceeded our expectations, and we are grateful for it. 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 utility supply/demand of the token and speculation(speculation is a neutral term here, expressing situations outside of supply and demand of utility).

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 have taken place consistently. However, the mechanism is designed in such a way that market speculation is directly reflected in the ether price, and the users still have to pay ether, the native currency, to use the service, resulting in users being forced to pay higher fees for the same service.

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 usage demand, which in the long run causes the network to lose value and leads to lower token prices.

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 would like to pay for the service, including ether and various ERC20-compatible tokens. In the future, we will gradually support more 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 service, let's first look at the types of allocation methods. The first kind is direct allocation to the service provider. 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% goes to the platform revenue 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 used to buy back and burn outstanding $BNB every quarter. The second approach is the ETH 2.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. $DCs are generated by destroying the same amount of $HNTs.

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 fees 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 with 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 nodes 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 usage 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 paid by the demand side will be reflected in the appreciation of the token price. At this time, for the supply side, only tokens can be good enough. It can be seen in the two edge cases that 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 context 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 to only 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

We address service pricing in two phases.

In the first phase, a fixed price regime 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 phase, 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 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 operators 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 methods, 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 starts to grow, 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 vote. 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.