The key for any Web3 system is to achieve sustained growth initially and then maintain a certain scale so that significant network effects can occur.

Original title: "Simple Tokenomics for a Proof-of-Stake Utility Token"

Written by Noam Nisan (StarkWare and Hebrew University)

Compiled by: Starknet Chinese Community

This document explores "Web3 Platform with Proof of Stake and Utility Tokens", which is a fairly common platform type in the "blockchain world". We will explain the meaning of these terms in detail, Table 1 shows the largest such platforms as of early August 2023, and their key "financial" indicators¹.

Table 1: Proof-of-Stake systems and their utility tokens with market caps of at least $3 billion

(Data source stakingrewards.com*, data as of August 7, 2023)*

We aim to propose some concise and general principles for analyzing such systems and their token economics, known as “token economics”. We strive for extreme simplicity, but any particular system will require a more complex analysis based on its specific goals, constraints, and circumstances. Nonetheless, we expect that these perspectives will serve as a useful starting point for understanding and exploring these issues and may provide guidance for preliminary design approximations.

1. Type of system we discuss

***In this section, we will explain what we mean by a “Web3 platform with proof-of-stake and utility tokens” and argue why such a platform must provide some kind of utility to users, must grow to a large enough scale, and Its operators must be rewarded. ***

1.1. Web3 platform

We define a "Web3 platform" as any computing platform that provides online services that achieve consensus and trust without relying on any trusted central party. Typical examples include cryptocurrencies such as Bitcoin, digital economic platforms such as Ethereum, various decentralized L2s that add value to Ethereum, and specific decentralized financial application platforms (DeFi). A core feature of these systems is that they can remain operational in a trustworthy manner without relying on the existence and functioning of any company, institution or government. Essentially, a single trusted party is replaced by a consensus among a large number of smaller parties.

Of course, some may question the feasibility and importance of such a system, as it eschews traditional, tried-and-true mechanisms like banking and finance, but this article argues that many would like such a system to exist, And believe that for some applications, not relying on a central entity is a worthwhile and important feature.

The level of trust provided by a Web3 platform will obviously depend on the size and quality of its partners, which are the cornerstone of trust in the system. Therefore, this type of platform presents a significant positive feedback network effect: the better the platform develops, the higher the trust it gains and the larger the value page it can provide, which in turn attracts more participants, thus Further promote the development of the platform³.

***As with any Web3 system, the key is to achieve sustained growth initially and then maintain a certain scale so that significant network effects can occur. ***

1.2. Proof of Stake

The security of Web3 systems relies on the cooperation and consensus of many small-scale participants. Therefore, a key challenge that every Web3 system must face is "Sybil attack defense": that is, how to ensure that a seemingly large group of participants is not controlled by a single entity. Camouflaged. After the Bitcoin system, early systems adopted a "proof of work" mechanism to address this challenge, which requires participants who support system security to demonstrate their computing power. As Bitcoin becomes more popular, the computing power required continues to grow, resulting in the required electricity accounting for a large portion of the world's total electricity consumption and having a significant impact on global warming.

While there have been proposals for other types of Sybil defense mechanisms, such as “Proof of Humanity,” which identifies real humans, it’s fair to say that the only alternative currently widely considered effective is “Proof of Stake.” In this type of system, participants must hold a certain amount of system "tokens", and the number of tokens they hold determines their "identity" and influence in the system. Specifically, consensus in the system is defined by the agreement reached by the participants holding a majority (or perhaps more than a majority) of the interests.

There has been a large amount of literature discussing the comparison between proof-of-stake and proof-of-work systems. Here, we explore how a typical proof-of-stake system operates from an economic perspective. Initially, the platform “mints” a certain number of tokens and distributes them in some way. To participate in the operation of the platform, operators must purchase tokens in the token market and "pledge", that is, locking the tokens in the platform as collateral for its legitimate operations. In return, stakers who stake their tokens and continue to participate in platform operations typically receive platform rewards in the form of more tokens (which they can sell on the market). Depending on the platform protocol, these rewards may come from fees paid by platform users or may be newly minted tokens. If rewards come from newly minted tokens, then obviously the total supply of tokens will increase, i.e. tokens will inflate⁴. Another way to reward operators is to give them the power to extract certain value from users of the system, known as Miner Extractable Value (MEV).

***In a proof-of-stake platform, stakers can earn rewards in several ways or a combination thereof: fees paid by users, minting of new tokens, value extracted from users. ***

In the table above, we see the “token economics” data of Ethereum, which has a market capitalization of over $20 billion, and eight other large staking platforms with a market capitalization of billions of dollars. (As of this writing, there are also many smaller platforms, with about 50 of them having a market capitalization of over $100 million.) As we can see, the nominal rewards offered to stakers (on an annual basis, based on their staked amount) percentage) changes ranged from 2% to 20%, with a median of just over 5%. Taking into account token inflation, actual rewards fluctuate between 0% and 10%, with a median of approximately 3%. In these systems, not all tokens are staked, with the percentage staked ranging from 15% to 70%, with the median closer to 50%⁵. One of the goals of this article is to propose a principled way to think about these data.

1.3. Utility Tokens

There are many types of tokens and different classification methods. This article is primarily concerned with classification based on economic purposes. That is, tokens are divided into payment tokens, utility tokens and security tokens. The purpose of payment tokens is to act as "currency" and are typically used as a medium of exchange and store of value. Bitcoin is a classic example of a payment token, as are many stablecoins⁶. A security token is a financial instrument, similar to financial securities such as stocks or bonds, that provides the holder with certain legal rights or claims against the issuer.

Utility tokens can be used to automatically ⁷ obtain specific services from the platform, providing users with actual utility of the platform. Utility tokens are most typically used to pay for platform usage in exchange for services provided by the platform. The Ethereum blockchain is a classic example, providing the service of running transactions on the public ledger of Ethereum, the “computer in the sky,” a service for which many users are willing to pay large sums of money. Ethereum's native token, ETH, is the only way to pay for these services, so potential Ethereum blockchain users must buy some ETH tokens from someone willing to sell them and then use those tokens to pay into the Ethereum blockchain.

When we analyze a Web3 platform from a purely "utility" perspective, it becomes obvious that the key goal of such a system is indeed to provide as much utility as possible to the user. Naturally, in order to provide utility on the Web3 platform, sufficient trust and openness must be maintained, and other platform-specific requirements must be met. Owning tokens is actually a key factor in enabling the trustless collaboration needed. From the perspective of our platform providing utility, the purpose of the token and its token economics should also serve the goal of providing utility. We will conduct this purely “microeconomic” analysis of tokens here.

Obviously, most utility tokens may have other functions, such as being payment tokens to some extent. One might well question that ETH's current value stems not just from its utility in running transactions on the Ethereum blockchain, like Bitcoin, but also from its functionality as a store of value and a means of payment. Our analysis is only plausible when a large portion, or at least a significant portion, of a token's value stems from its role as a utility token.

2. Micro-Token Economics: Fees and Social Welfare

***This section describes the micro-tokenomics of the token, focusing on the transaction fees that users need to pay to use the platform. We believe that the optimal transaction fee should be the marginal cost incurred by the platform in running transactions, including the congestion cost when congestion occurs. ***

As the name suggests, a platform with a utility token will provide a certain service to users, so it will inevitably establish a market for this service. This market will determine who can obtain the service and how much they need to pay for it. This section will provide a basic analysis of this market.

In keeping with our goal of simplicity, we have kept our discussion as simple as possible while we believe we still capture the basic economics of utility-based Web3 systems. In particular, we insist on "static" analysis to avoid involving more complex time and dynamic issues. Although these problems are generally more difficult to handle, we believe they should be solved using the same principles as the static case.

2.1. Platform goals and social welfare

The first thing we need to clarify is the goal that the platform should strive to optimize. Although people's first reaction is to "make the builders of the platform rich," this view ignores the behavior of the expected participants in the platform ecosystem and does not propose any decision-making recommendations. Our view is exactly the opposite: the goal of a platform is to maximize the total value that the platform brings to “the world,” what economists sometimes call maximizing social welfare.

Let’s start from a normative perspective: What should the platform optimize for? If the platform is viewed as a company and its tokens are treated as company shares, then one would naturally try to optimize the returns for “shareholders.” But this view is not in line with the philosophy of the Web3 community. The Web3 community does not like to think of its infrastructure as a company, but rather as a public service provided to users. The Ethereum blockchain is a good example. Unless ETH is pledged, ETH holders do not directly receive any profits from the operation of the Ethereum blockchain. Going back to our previous discussion of distinguishing between security tokens and utility tokens, the former is concerned with maximizing returns for token (stock) holders, while with the latter – our focus is on maximizing the value of the entire platform ecosystem Consistently, this mainly includes (most of) its users.

If the above normative discussion seems too idealistic or too lofty, we can also start from a more practical perspective. Suppose some participants have other, less charitable goals, such as maximizing their own personal income as token holders. How can they do this in the long term? Since network effects are an intrinsic driver of any Web3 system, the platform's primary goal is growth. The faster a platform develops, the more likely it is to survive and bring more “social benefits” to the ecosystem, creators, and token holders. The main way to achieve growth is to ensure that the platform actually provides as much utility as possible. This not only attracts users to use the platform because they receive direct value, but "optimizing for users" also provides better public information, which is very important in the Web3 community. An apt metaphor for the goals of a platform might be that it might be more like a country than a company: the goal is not to grow shareholder value at the expense of other interests, but to grow the entire economy, ultimately improving the lot of all participants⁸. Translating this perspective into the day-to-day operations of the platform, we end up working towards maximizing social welfare.

***The goal of a Web3 platform with utility tokens should be to maximize the social benefits it brings. ***

2.2. How to maximize social welfare?

So, assuming that we do want to optimize social welfare for normative or practical reasons, what should we do? First, the platform obviously must provide some truly useful service, so for the remainder of the discussion we will assume that it does this.

Let's be a little more specific and let's get into an economic model. When we say a platform does something useful, that means it must be useful to someone. We refer to these "certain people" who can gain value from the platform as (potential) users. We abstractly refer to the "service" unit provided by the platform as transaction. The operation of the platform may require some resources and energy. We call the person (or company) who provides these resources and energy the operator.

At this model level, the basic question of maximizing social welfare boils down to which transactions the platform should serve. Even if a transaction brings value to users, we may have two reasons not to serve it. First, the cost (the effort and resources required) of servicing a transaction may be higher than the value the transaction brings to the user, in which case the total benefit of servicing the transaction is negative. Secondly, the platform may have certain capacity limits⁹. If the demand for transactions exceeds its supply capacity, the platform will have to select the most "valuable" transactions and ignore other transactions. To continue our analysis, let's delve into a very simple economic model of this situation.

2.3. Basic economic model

We try to construct a basic economic model that captures the essence of the situation we discuss: Suppose there are multiple transactions i=1,2,…,N wishing to be served by the platform. Each transaction i has an initiating user who has an associated value vᵢ for this transaction. At the same time, each transaction also incurs an associated marginal cost cᵢ, which is the cost that the platform (through its operator) must bear in order to process that transaction (in addition to other transactions already being processed). In traditional economic theory, the marginal cost of a product unit usually depends on the number of other units that have been produced (marginal cost increases or decreases), but in our case it may be safer to treat transaction costs as fixed costs (after being borne after some fixed costs to start operations until some capacity limit of the platform is reached). Maximizing social welfare means selecting the service transaction set S among all possible transaction sets that meet the platform capacity to maximize ∑ i∈S (vᵢ-cᵢ).

So, in this model, which transactions should we serve? If the platform has not reached its capacity limit, we should process all transactions with a positive net value (vᵢ-cᵢ), that is, transactions with vᵢ > cᵢ. So how to do it? While we might assume that platforms can calculate (or at least estimate) the costs *cᵢ* associated with service transactions, the value vᵢ of each transaction is subjective in the eyes of interested users and only the users themselves can know for sure. There is a basic economic trick here: charge the user a transaction fee equal to cᵢ to process his transaction. In this case, the user will choose to execute his transaction if and only if his personal value vᵢ is higher than the cost, i.e. vᵢ > cᵢ. This is called "marginal cost" pricing, and it is a basic fact presented in the "Economics 101" course: in order to maximize social welfare, the price of a unit should equal the "marginal cost" of providing the unit¹⁰.

***To optimize social welfare, transaction fees should be set to their marginal cost. Doing so aligns users' net utility with social welfare. ***

In the event of congestion, the relevant "marginal cost" should also take into account the impact of processing our transactions at the expense of other transactions that are not processed. In this case, transaction fees should consider not only the direct cost of the transaction cᵢ, but also the “congestion cost”: the net loss of social welfare caused to other users. Let's see how this is calculated in the simplest and most common case.

Single-dimensional gas model: This is the simplest and most common model to describe the capacity limitations of Web3 systems. Each transaction has a certain size si, which is used to describe how much system resources it consumes (Ethereum terminology calls this the "gas" used by the transaction), and the total resources of the system (i.e. gas) have a certain Capacity K. Therefore, if ∑i∈S si ≤ K, then a set of transactions S is feasible, and maximizing social welfare means maximizing ∑i∈S(vi-ci) under this constraint. Furthermore, in this model, the associated cost of running a transaction is considered to be proportional to the size of the transaction, i.e., cᵢ=αsᵢ (where α is some global constant). Although this optimization problem is essentially a classic knapsack problem, there are usually no efficient algorithms to solve it directly. But there is a well-known greedy approximation algorithm: arrange transactions in descending order of vᵢ/sᵢ, and process transactions from the top until processing the next transaction would exceed the capacity limit (or until vᵢᵢ). The "gas price" is set to g=vi/si in the last accepted transaction i, or in the absence of congestion, to the lowest price g=α, and the fee will be proportional to that gas price, i.e. fᵢ =gsᵢ¹².

The models discussed above are very simple and ignore many aspects that will occur in actual platforms. But its main economic implication remains universal: in order to maximize social welfare, we should charge transaction fees equal to marginal cost. When congestion occurs, transaction fees should also include "congestion costs."

2.4. Transaction fee mechanism

While we have identified the fees required to ensure maximization of social welfare, we still need to define a specific mechanism that will enable our platform to actually collect these fees. Such a mechanism must take into account that both users and operators of the platform behave rationally and "strategically", each trying to optimize their own utility, and that operators may interact with multiple users (whether real or false) there is collusion. Although we generally assume that users behave strategically, only in specific circumstances do we need to worry about operators’ strategic behavior. This situation occurs when the operator has a certain degree of freedom, and its non-protocol behavior is difficult to be "caught" by other operators. For operators who do not have free authority, they only need to be encouraged to continue participating through large payments, "block rewards", etc. When there is some degree of freedom, such as when an operation can decide which transactions to accept, the platform protocol needs to ensure that the operator has an incentive to act in accordance with expectations. Perhaps surprisingly, even a simple mechanism can charge the required fees in its equilibrium state.

Bid-to-pay mechanism: Taking the simple "bid-to-pay" mechanism used in Bitcoin to decide which transactions to accept as an example, let's explore why this mechanism can approximate charging marginal costs (including congestion costs), and thus approximate Optimize social welfare. The basic mechanism works as follows: at a specific point in time - within a block - there is an operator (miner) who decides which transactions can enter the block. For us, it doesn’t matter how the operator is selected. The important agreement is to ensure that this operator’s decision is most likely to become a consensus. Users bid for their own transactions, and the selected operator can accept any subset of bids he wishes within a given capacity and charge a fee for his bid on any accepted transactions. So, what happens in the long run at equilibrium? If we think of our situation as an economic market (i.e., a trading space), we would expect the market to reach equilibrium in which fees equal marginal costs and social welfare is maximized.

Equilibrium in the Gas model:* Let's return to our one-dimensional resource model, where each transaction i* has a value of *vᵢ*, a size of *sᵢ*, and a cost of Proportional to its size, i.e. *cᵢ=αsᵢ*, the total capacity of a block is limited to *K*. Now, the owner of each transaction bids *bᵢ*. Looking back at the operator who decides which transactions will be accepted, it is clear that the operator, if he is compensated for bidding bᵢ, will accept the set of bids that maximize ∑i∈S bi*S *, which means (ignoring integer constraints) that he will accept the set of bids with the highest bᵢ/sᵢ ratio until the block capacity limit is reached. We expect the bidding dynamics to enable bidders to find and bid at a minimum bᵢ value that (presumably in the long run) makes their transaction acceptable (requires *bᵢ≤vᵢ*, otherwise they are unwilling to pay bᵢ). The equilibrium state reached under this assumption will cause those bidders with sufficiently high unit size value bᵢ/sᵢ to bid at the "equilibrium gas price" p, while bidders with lower value will bid less than this One price. That is, every bidder with *vᵢ≥p*sᵢ will bid *bᵢ=p*sᵢ, and *vᵢα* (recall that *cᵢ=αsᵢ*), then *∑i∈S (vᵢ – cᵢ)*, thus maximizing welfare. In order to handle non-congested situations, where transactions with vᵢ≥cᵢ=αsᵢ do not fill the block capacity, the system must specify a minimum gas price *p*≥α*¹³ as part of the protocol.

Incentive Compatibility:* There may be concerns about how quickly and to what extent bid-pay mechanisms will reach (at least approximately) this equilibrium state, and how users will figure out the magic parameters they need to bid appropriately. p*. More complex fee mechanisms (such as the EIP-1559 mechanism used in Ethereum) can make the bidding process more transparent (“incentive compatible” in mechanism design terms), thereby directly guiding the system to achieve an effective balance, which will make Maximizes social welfare and equals expense to marginal cost¹⁴. There is a lot of research¹⁵ on how to design such mechanisms, and this research can be generalized to more complex and realistic scenarios.

Extracting Value from Users (MEV): When mechanisms allow operators to extract some value from user transactions, it may be wise to consider charging "hidden fees" from users. The nature of this extraction depends on the services provided by the platform, but a typical example in blockchain is that the validator who creates the block can add their own transactions, causing it to "preempt" certain user transactions, thereby transferring value to In your own hands. This opportunistic value capture has nothing to do with transaction service costs or congestion, so these hidden MEV fees are not consistent with the economic health of the system and may, for example, scare away users whose transactions may be exploited. Therefore, although it is sometimes impossible to completely eliminate this possibility, the relevant mechanisms should minimize this possibility.

2.5. Conclusion: Micro-Token Economics

Therefore, the core idea of this section is that Web3 systems with utility tokens should aim to maximize the social welfare (i.e., added value) they provide. This is achieved when the fees charged are equal to the marginal cost of the transactions served (including congestion costs). In fact, there are some economic mechanisms to achieve this. While the details may be complicated by the complexity of the platform, the basic principles still apply.

3. Macro Token Economics: Staking Costs and New Token Minting

***This section will explain the macroeconomics of tokens, focusing on the relationship between the rate of new token minting, staker rewards, and the security gained through staking. Our main point is that staking rewards should cover the staker’s cost of funding, preferably paid out via newly minted tokens, and be the primary factor in determining the minting rate. ***

The previous section focused on transaction costs, the microeconomics of the Web3 platform that provides utility to its users. We now turn our attention to the *macroeconomics* of the platform: how funds are managed throughout the system and how token distribution is managed. Again, we will focus on simplicity and generalizability. Of course, actual systems may need to consider more complex factors, but hopefully our analysis can still serve as a useful starting point. First, let us start with the main differences between the above-mentioned microeconomic analysis and the necessary elements to ensure the operation of the system economy.

3.1 Fixed costs

The formula for charging transaction fees based on marginal cost ignores a core issue, namely "non-marginal cost". Let's be more precise. In all our discussions above, the only cost associated with servicing a transaction i is the additional marginal cost, that is, how much more it costs to service that transaction in addition to other transaction costs already incurred. Effectively, this determines whether we should service this additional transaction (assuming we have already decided which other transactions to service). For example, the cost of servicing N transactions is $100+N(1\*, then the cost of servicing 9 transactions is 109, and the cost of servicing 10 transactions is 110. Here In this case, we would consider that there is a fixed cost of 100 and a marginal cost of 1. Although the marginal cost is 1, the average cost of servicing 10 transactions is 11. If we only Charging marginal cost, then we can only charge )1 from each transaction, but where does the missing $100 fixed cost come from? When the marginal cost is lower than the average cost, the deficit problem caused by charging only the marginal cost will become apparent, which seems to be a typical problem in blockchain¹⁶.

In the real world, any fixed costs must ultimately be borne by the users themselves, so marginal cost pricing is not feasible¹⁷, whereas in a tokenized platform, fixed costs can be paid for by minting new tokens. The advantage of this is that fixed costs and marginal costs can be kept equal. Of course, there are still “people” who need to pay fixed costs, and this “people” is the collection of all token holders. That is, minting new tokens means that the token will experience inflation, potentially reducing its value, so each token holder effectively loses a small portion of the token's value.

One might question the extent to which placing this burden on token holders is reasonable or desirable. In our opinion, this is the least bad option out of the many. First, it allows us to maximize system usage by charging users only marginal costs, which is in line with our fundamental goals. Secondly, once the usage of the system is maximized, the total value of the platform will increase, thereby increasing the value of the tokens. This increased token value can compensate token holders who have paid the fixed costs.

**To enable marginal cost pricing, any fixed costs associated with operating the platform are best paid for by minting new tokens. **

Looking at existing blockchain projects, the current common practice is that new tokens are minted to pay "block rewards". These rewards have nothing to do with the specific transactions in the block, but to reward miners, stakers or sorters. device. These block rewards basically cover the associated fixed costs, while the transaction fees paid by users are an additional part paid to the operators.

Skeptical readers may question the sustainability of this process: Is it justified for token holders to continue to subsidize the platform? Where will the "end" go? There are several possible "endgames": First, there is the possibility that the platform will achieve sustainable growth as part of the sustainable growth of the world economy¹⁸. Another possibility is that demand for platform services grows faster than platform supply grows. In this case, congestion charges will continue to grow (for reasons detailed in the micro-token economics section), and since these are not actual costs borne by the system operator, the congestion charges can cover fixed costs¹⁹. There is also the possibility that as platform usage grows, fixed costs may become insignificant compared to increasing marginal costs and can be charged as a small add-on fee without causing significant market distortions. If none of the above solves the problem, we can expect that in the long run, * after experiencing sufficient growth*, the platform will indeed gradually increase fees beyond the stated marginal cost, just as in the "real world" as done.

3.2 Pledge cost

In a proof-of-stake system, the most important fixed cost is usually the financial cost of staking, sometimes called the "security cost", "capital cost" or "opportunity cost". Specifically, stakers hold and stake a certain amount of tokens in the system, giving up other ways to use those funds. Either using it directly or selling the tokens in exchange for fiat currency (such as US dollars) and then using them in other ways. These costs are essentially financial costs, the size of which is determined both by the external financial environment (e.g. current interest rates) and by the platform-specific properties associated with the staked tokens (including real and perceived risks) and other possible uses of the tokens (e.g. Providing liquidity in automated market makers) decisions. Specifically, if the total staking amount is *S* (in USD), and the staker earns an annualized rate of return of *r%*, then the total annual cost of staking is *r%*S *.

**Take Ethereum as an example: **Based on the data in early August 2023, calculate the staking cost of the largest staking platform, the Ethereum network. According to Table 1, approximately 19% of the Ethereum platform tokens were pledged at that time, and the total value of all tokens was $224 billion, so the total value of pledged tokens was $42 billion. As the table shows, the annual return on these tokens is approximately 5%, resulting in a total annualized staking cost of over $2 billion. Ethereum's annual transaction volume is approximately 400 million transactions (approximately 12 transactions per second), so each transaction costs more than $5, which is likely to be a major part of the total cost of operating the Ethereum platform.

3.3 Staking rewards

Although the platform needs to mint new tokens to cover operator costs, this is undoubtedly a burden on token holders, so it is best to mint only the required number of new tokens. The protocol needs to ensure that the rewards distributed are sufficient to incentivize operators to participate and behave correctly, so a balance must be found between fully rewarding operators and minting the minimum amount of new tokens. We believe that incentives are generally tractable at a microeconomic level, relatively speaking, and therefore the primary factor in determining minting rates should be the cost of capital to reward operators.

As an example, let's look at the "standard" model of blockchain. In each block there is one operator, the leader, who is responsible for building the block and bearing most of the costs, while the other operators basically just use Some kind of consensus protocol "signs" the block. In order to keep the system functioning properly, the leaders who build the blocks must be heavily compensated, as well as other operators who "remain active". The latter is usually easy to achieve because they have no significant agency rights and so from a macroeconomic perspective there are no obvious incentive constraints²⁰. Rewarding block leaders is often a tricky problem because leaders have very broad autonomy, so we need to get the incentives "just right." However, the transaction fee mechanism can directly solve this problem by using the correct marginal cost pricing method, while also taking into account the incentives of the leaders, and incentivizing them to include the correct transactions into the block "just right". In addition to properly handling the incentives for marginal costs, we only need to compensate the leader for its fixed costs, and a sufficiently large fixed "block reward" can do this.

**The main factor determining the minting rate should be the capital cost of the reward operator. **

In the following analysis, we will assume that the platform reward rate required by the operator is determined by stakers in different ways based on their financial calculations. A staker's financial considerations may relate to the financial environment, the perceived risk and potential of the platform and token, and the fungibility of the token. While various financial models can be applied to estimate how the required reward rate is affected by other financial parameters such as external interest rates or the historical volatility of the token exchange rate²¹, we do not require such an estimate and will continue to treat the required reward rate as regarded as an established fact. According to experience, on the different large platforms listed in Table 1, the annual reward rate for stakers is between 2% and 20%, and usually the reward rate will be between 3%-7.5%, with the median being approximately 5%. This huge difference likely depends on a range of factors, and there's no doubt a lot of "noise" in what exactly these numbers mean. Still, we can agree on a reasonable rate of return that puts it in the same category as typical bond or stock yields.

3.4 New minted tokens

The platform must provide sufficient pledge rewards to operators, otherwise operators will be unwilling to participate in platform operations. As mentioned above, the concept of "enough" is determined by the stakers themselves, which is mainly a financial issue. So, how should the platform be designed? That's what we're trying to solve now. Our basic analysis will identify fixed costs and staking costs, and assume that the source of staking rewards will be newly minted tokens, which will be distributed equally among subscribers in proportion. We will only focus on the total amount of minted tokens and rewards, not their specific composition, assuming that the transaction fee mechanism can handle these issues appropriately.

For the sake of a simple analysis, let us focus on the following parameters: (1) the ratio of annual token minting to the total current supply of tokens, (2) the ratio of annual staking rewards to the total staking amount, (3) the staking rate, which has The ratio of staked tokens to all circulating tokens. The overall equation that governs this relationship and affects the platform’s macro token economics looks like this:

(% of new minting per year) = (% of staking rewards per year)*(Staking rate)

We’ve discussed the staking reward rate, now let’s take a closer look at the minting rate of new tokens. This ratio is determined by the protocol, which should dictate when new tokens are minted (or when tokens are destroyed). As per our assumptions, newly minted tokens are used to pay for staking rewards, which is the net sum of all rewards distributed by the protocol annually²². Specifically, in a blockchain protocol, if the protocol stipulates that the total reward per block is R tokens (on average, this refers to the sum of all operators, net of the destruction of tokens), The total number of existing tokens is S, and there are N blocks every year, then the annual minting rate of new tokens is RN/S.

Note that the staking rewards in this formula are "ideal", that is, they do not take into account any inflation in the value of the token. That is, any inflation in the value of the token is not taken into account. This formula is for stakers who believe that newly minted tokens will not truly dilute the value of their tokens (because the platform is growing faster than it is being minted). But skeptical stakers might be more interested in the actual or adjusted reward rate, which is calculated by subtracting the minting rate from the reward rate to get the corresponding number:

*(adjusted reward rate) = (minting rate)/(staking rate)-(minting rate). *

3.5. Pledge rate and security

By definition, the security of a proof-of-stake platform relies on the way tokens are held to prevent Sybil attacks. In other words, the consensus implied by the system is formed by operators holding a large enough proportion of tokens. Let’s explore why we trust this type of consensus. The first reason is simply that we do not believe that any malicious party will have sufficient resources to control a majority of the staked shares, and that non-malicious stakers will faithfully follow the protocol²³. The second reason is that any parties that jointly own a majority of the tokens stand to lose significantly if the platform ceases to operate faithfully, as the token value is likely to decline significantly in such a scenario. The first argument is the typical "honest majority" argument in computer science, while the second argument is the game theory "incentive" argument common in economics.

Quantifying these two safety reasons is a rather imprecise exercise, as both depend on many factors. For the first reason, we must try to determine what proportion of the total pledge the platform must resist taking over by malicious parties. For the second reason, we should estimate the economic gain that could be achieved by a malicious party gaining a majority of staking power²⁴, and we estimate the economic loss that would result from such manipulation causing the token value to decrease. While precise quantification is difficult, in both cases it seems likely that the benefits from maliciously owning a majority of staked tokens would be of the order of some fixed proportion of the total value of all tokens. Therefore, achieving reasonable security against malicious players requires staking at least a fixed proportion of the total tokens. The exact fixed ratio required by different platforms will vary depending on the possibility of manipulation, the value of the token and its liquidity, the ratio locked and the nature of its lock. Nonetheless, for any given platform, the proportion of tokens staked can be considered a proxy indicator of the security gained. Based on experience, as can be seen from Table 1, the pledge rate of the major platforms is approximately between 20% and 70%²⁵, with the largest platform usually having the lowest pledge rate.

**The proportion of tokens staked in a proof-of-stake platform should be at least some platform-related constant, and as the staked proportion increases, security increases. **

Given an estimate of the required security level and an estimate of the current required rewards for stakers, we can calculate the required minting rate²⁶. Take the median in Table 1 as an example: Assume that stakers require a 5% annual return, and the staking rate we want to achieve is 50%. Then the required annual casting rate calculated according to the formula is 2.5% (50%*5%). This type of calculation is static, assuming both the required staking reward and the required staking rate are fixed.

Let's see how this calculation is implemented in the protocol. Generally speaking, the protocol determines the minting rate by setting a "block reward." Stakeholders can then decide whether to stake their tokens, and then the newly minted tokens are essentially distributed among the stakers, providing them with staking rewards. We can certainly assume that the higher the staking reward rate, the more stakers will decide to stake their tokens. Therefore, the staking rate will adjust itself until the above equation is met: if the staking rate is lower than the equation requires, each staker will receive a reward higher than the "demand", so more stakers will participate in staking. If the staking rate is too high, the rewards are too low and stakers will leave. Balance is only possible when the staking rate brings the staking rewards up to market demand.

Additionally, if the financial environment changes while the protocol remains the same, the staking rate will adjust itself. For example, if external interest rates rise, or other financial uses for tokens within the platform become more attractive, stakers may demand higher rewards, which would be achieved by reducing the staking rate. Likewise, if confidence in the future of the platform increases, stakers will demand fewer rewards and therefore the staking rate will increase.

Of course, the platform does not have to choose a fixed casting rate "once and for all." Instead, the platform can observe the current staking rate and use this information to determine the minting rate. This dynamic minting rate mechanism allows for more granular control of the balance between staking and minting rates as a function of the required staking rewards observed from staker behavior. For example, Ethereum defines a curve where the minting rate increases proportionally to the square root of the staking rate, thus causing the reward rate to decrease inversely as the square root of the staking rate. Another option is a dynamic protocol that increases the minting rate when the staking rate is below the desired level (and decreases the minting rate when the staking rate is above the desired level). In both cases, equilibrium will only be reached when the reward rate equals staker demand.

3.6. Summary: Macro Token Economics

Therefore, the core idea of this section is that a proof-of-stake platform with a utility token should cover all fixed costs of the platform by minting new tokens. The major part of fixed costs may be the funding cost of the pledge, depending on the financial environment. Since the security of the platform depends on the staking rate, the protocol should mint enough new tokens to achieve the required security.

* [1] Readers may consult the * *stakerewards.com * * website for definitions of each column in the table. Due to various differences between platforms, these numbers may need to be taken with a grain of salt and should be considered indicative. *

• [2] These are the "real" rewards after taking into account token inflation (minting). For net minted tokens, the adjusted reward is lower than the original reward, while for net burned tokens, the adjusted reward is higher. *

• [3] One might try to specify more precisely what kind of development is needed to increase trust in a platform? And what are the limits to this effect? But for our purposes it is enough to assume that the relevant indicators will grow more or less together. *

• [4] Unless there is some other mechanism that reduces the number of tokens. *

• [5] All numbers should be taken with a grain of salt due to differences in platform details, measurement issues, the presence of locked tokens, and more. *

• [6] While risky Bitcoin and stable “stablecoins” are very different in their goals and behaviors, they both serve a clear purpose as a “money” and are therefore classified in the same way here. *

• [7] As mentioned earlier, security tokens represent claims against a trusted issuer. The holder must trust that the issuer will honor the claim, or seek specific enforcement of the claim. In contrast, a utility token is not a legally enforceable claim against a trusted party; it is a scarce unit of digital property that, according to the rules of the protocol, can trigger the protocol to automatically provide some useful service. When these systems work as intended, token holders do not need to trust any issuer or court to receive services from the protocol. *

• [8] We often accept this kind of reasoning in macroeconomic models. If dollar holders were extremely selfish, they would not tolerate any inflation rate. However, given the common understanding that stable inflation rates generally encourage consumption and grow the economy, dollar holders would tolerate and even support inflationary policies because In the long run, these policies lead to better individual and social welfare outcomes. *

• [9] The "capacity" of the platform is usually defined by the agreement to ensure that many operators with reasonable computing power can participate in the operation. *

• [10] If readers are worried that marginal cost pricing does not cover the fixed costs of platform operation and is therefore untenable, it is recommended that you make your decision after reading the macro-token economics section, which will propose the sources of covering these costs. *

* [11] More precisely, we might want to think of the first rejected transaction as i*, but our rough analysis here considers these transactions to be essentially the same. *

• [12] This algorithm can be viewed as an approximate treatment of the linear programming relaxation of the optimization problem. Its distance from the optimal value is limited by the proportion of the total capacity of the first rejected transaction, so it provides a good approximation as long as the transactions are relatively small compared to the total capacity. Gas price can naturally be regarded as a dual variable of this LP. Ignoring the integer constraint, when S contains the transaction with the highest vi/si value and the threshold is set at g, ∑i∈S(vi-ci)=∑i∈S(vi-αsi) when ∑i∈Ssi≤K Maximization under the constraints of does indeed occur. *

• [13] Our assumption here is that the system cost ci=αsi of a single transaction is not borne by the specific operator who decides the block, but is shared by the aggregation operators, and the cost of the specific operator is negligible. If not, there should be a "proper" mechanism to compensate the operators who decide the blocks. *

• [14] As a first approximation, the EIP-1599 protocol dynamically finds a Gas release price that is very close to the marginal congestion cost of the next block. *

• [15] If you want to start studying the literature in this area, Tim Roughgarden's paper "Transaction Fee Mechanism Design" is a good place to start. *

• [16] However, if the congestion costs are large enough, then these costs (as part of the fees, but not costs actually borne by the platform operator) may at least partially cover the fixed costs. To some extent, this is happening in Ethereum. *

• [17] Perhaps one controversial exception is public projects financed by the government, which may be financed by borrowing, which is effectively guaranteed based on a belief in economic growth and future tax increases. *

• [18] If we use r to represent the casting rate and g to represent the growth rate of the platform, then as long as r, paying fixed costs through casting is sustainable. *

• [19] Depending on the fee mechanism used, these congestion fees may be paid directly to the operator and cover their costs, or they may be burned, offsetting new minting fees. *

• [20] Nonetheless, we would typically expect that operators who "sign" blocks would actually check these leaders and verify that the blocks are correct, which we may need to incentivize, and in this regard we still need to effort. In some systems this may not be trivial at the microeconomic level, but from a macroeconomic perspective it does not appear to constitute a significant constraint. *

• [21] Just as a concrete example, the following calculation can serve as a very simplified starting point for such calculations: Assume that the platform is expected to grow by g% per year, the minting rate is expected to be r%, the external real interest rate is R%, and the risk premium for token staking is expected It is estimated to be y%, then we may expect that the required staking reward is (R-g+r+y)%. More realistic financial calculations would naturally emphasize the modeling of risk premiums and growth rates. *

• [22] When there are significant fixed costs in addition to capital costs, these should also be covered by newly minted tokens, and the agreement must provide for the means by which this is achieved. The above equation would be modified by adding appropriate terms so that the casting rate also includes these costs. *

• [23] When the "pledge pool" concentrates the power of many independent pledgers, this assumption may be a bit too optimistic. Although individual pledgers may not be malicious, the pledge pool itself may be a malicious existence at this time. *

• [24] In some platforms, a large proportion of malicious parties can simply "steal all the tokens from everyone", while in other cases, only more sophisticated schemes can bring such significant benefits. For example, even if a majority of malicious parties simply effectively shut down the system, this could result in significant gains by shorting the token outside of the platform (where possible). *

• [25] These numbers should be taken with a grain of salt, for example, because in some cases there are “locked” tokens that can only be used for staking. *

• [26] If the protocol also involves burning tokens, then this token burning needs to be taken into account when considering the net minting rate. *