Original author: Noam Nisan
Original compilation: Block unicorn
This article discusses Web3 Platform with Proof of Stake and Utility Tokens, a type of platform that is quite common in the blockchain world. We quickly explained what each term means, and Table 1 lists some of the largest platforms in this category and some of their important financial metrics as of early August 2023.
Table 1: Proof-of-stake systems and utility tokens with market caps of at least $3 billion (Data source: Retrieved from stakingrewards.com on August 7, 2023)
Our goal here is to present simple yet broad principles about such systems and their token economic aspects, known as tokenomics. While we strive for extreme simplicity, any specific system will require more complex analysis depending on its specific goals, constraints, and environment. Nonetheless, we hope that the ideas presented here serve as a useful way of thinking about these issues and perhaps as preliminary guidelines for design.
Types of systems we discuss
Here, we explain in detail the meaning of Web3 platform with proof of stake and utility tokens and discuss that such platforms must provide users with certain practical value, must develop to a large enough scale, and must reward them operator.
1.1. Web3 platform
We use the term Web3 platform to refer to any computing platform that provides some online services in a way that enables mutual agreement and trust without relying on any trusted central party. Basic examples include cryptocurrencies such as Bitcoin, digital economic platforms such as Ethereum, various decentralized L2 layers that add value to Ethereum, or specific decentralized application platforms dedicated to finance (DeFi). The point of these systems is that they should continue to function in a way in which you can trust them without relying on the proper behavior or even existence of any single company, agency or government. Basically, a single trusted party is replaced by a consensus among many small organizations.
Of course, one can question the desirability or importance of such systems that circumvent traditional tried and tested mechanisms such as banking and finance, but this article treats it as a reality that many people would like to have such systems and believe that in certain applications Not relying on a central party is worth taking and very important.
The level of trust provided by a Web3 platform will obviously depend on the size and quality of the large number of parties collaborating to support the systems trust. It can be seen that this type of platform has a significant positive feedback network effect: the more the platform grows, the higher the trust in it, and therefore the greater the value it provides, attracting more participation, thus further promoting growth.
A key requirement for any Web3 system is to initially grow and then maintain a scale that provides significant network effects.
1.2. Proof of Stake
Since the security of Web3 systems is based on the cooperation and agreements of many small parties, a key challenge that every Web3 system must solve is Sibyl (Sibyl attack) resistance: how do we ensure that what appears to be a large attack group on the surface, In fact, they are disguised as multiple attack groups, with only one control organization behind them. After the Bitcoin network system, early systems solved this challenge by using a proof of work mechanism, where supporters of system security needed to demonstrate computing power. As Bitcoin gained popularity, the amount of this computing power grew to the point where it required a significant portion of global electricity use and had a non-negligible impact on global warming.
While there are some suggestions for other types of Sibyl resistance, such as Proof of Humanity, i.e. identifying actual humans, arguably the only other option that has any significant use at the moment is probably Proof of Stake. In this kind of system, participants must own some kind of system token, and the number of tokens they hold is the basis for giving them their identity in the system. Specifically, the agreement in the system is agreed by the majority of parties (or perhaps more than a majority of organizations) with participating interests.
There is a vast literature on Proof-of-Stake vs. Proof-of-Work systems, but here is 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 a certain way. In order to participate in the operation of the platform, operators must obtain some tokens on the token market and pledge them, that is, lock them in the platform as collateral for their normal operation in the system. In return for staking tokens and continuing to participate in the operation of the platform, typically the platform rewards stakers with more tokens (which they can then sell on the open market). Depending on the platform’s protocol, these rewards can come from fees paid by platform users or from newly minted tokens. If the rewards come from new minting, then obviously the total token supply will increase (i.e. the tokens are inflationary). Another possibility to reward operators is to give them the power to extract some value from users of the system, this is often referred to as Miner Extraction Value (MEV).
Stakeholders in a proof-of-stake platform must be rewarded through user fees, the minting of new tokens, extracting value from users, or some combination of these.
In the table above, we see “tokenomics” data for the largest proof-of-stake platforms, including Ethereum, which is valued at over $200 billion, and eight other multi-billion dollar platforms (which, as of time of writing, still exist Many small platforms, about 50 of which are valued at over $100 million each). As we can see, the actual rewards offered to stakers (annual rewards as a percentage of their staked amount) vary within the range of 2% -20% (APR), with the median being just over 5%. By adjusting rewards to account for token inflation, actual rewards vary in the range of 0% -10%, with the median being approximately 3%. Not all tokens in these systems are staked, the proportion of stakes varies between 15% -70%, with the median closer to 50%, and one of the goals of this article is to propose a principled way of thinking about these numbers.
1.3. Utility Tokens
There are many types of tokens and many ways to classify them. In this article we are interested in their classification for economic use. This classification involves three types of tokens: payment tokens, utility tokens, and security tokens. Payment tokens are designed to act as money, typically as a medium of exchange and a form of store of value, typical examples being Bitcoin and many stablecoins. Security tokens are financial instruments that provide the holder with certain legal rights or claims against the issuer, just like financial securities (such as stocks or bonds).
Utility tokens can be used to automatically obtain some services from the platform, allowing users to derive some utility from them. Most commonly, utility tokens can be used to pay for the use of a platform, where the platform provides some kind of service to those users. Take Ethereum as an example. The Ethereum blockchain provides the service of running transactions on the Ethereum computer in the sky public ledger. This is a service that many users require, and they are willing to pay a considerable amount for it. Ethereums native token, ETH, is the only way to pay for this service, so potential Ethereum blockchain users must buy some ETH tokens from some seller willing to sell, and then use those tokens to pay for Ethereum blocks chain.
When we analyze the Web3 platform purely on a utility basis, it becomes clear that a key goal of such a system is to actually provide as much utility to the user as possible. Naturally, providing utility for the Web3 platform will require maintaining sufficient trust and openness while meeting other platform-specific requirements. Owning the token actually becomes a key factor in enabling the trustless collaboration required, and looking at our platform from the perspective of providing utility, the purpose of the token and its token economics should serve this goal of providing utility. We will conduct a clear “microeconomics” analysis of tokens here.
Obviously, most utility tokens may also have other functions and act as payment tokens to some extent, for example. One might well suspect that ETHs current value extends beyond its utility for running transactions on the Ethereum blockchain, to its use as a store of value and means of payment, much like Bitcoin. Our analysis would be appropriate when the majority of a coins value, or at least a significant portion of it, comes from its utility token aspect.
Microtokenomics: Fees and Social Welfare
In this section, we describe the microeconomics of the token, focusing on the transaction fees that users need to pay in order to use the platform. We believe that the optimal transaction fee is the marginal cost incurred by the platform to run the transaction, including the congestion cost (if there is congestion).
Since platforms with utility tokens by definition provide some kind of service to users, a market for such a service is bound to emerge. This market will determine who gets the service and how much they pay for it. This section provides an overview of such a market. Basic analysis.
Maintaining the goal of simplicity, we will keep the discussion as simple as possible while still covering what we believe to be the basic economic characteristics of a Web3 system based on practicality. In particular, our insistence on static analysis avoids timing and dynamic problems, which are generally more difficult to deal with, but which we believe should be handled using the same principles as the static case.
2.1. Platform goals and social welfare
The first thing we need to address is figuring out what the platform should be trying to optimize for. While the initial reaction may be to “make the builders of the platform rich,” this cynicism ignores the behavior of the intended participants in the platform ecosystem and does not suggest any decision-making. We defend the exact opposite view: that 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 you think of the platform as a company and its tokens as its shares, then it is natural to try to optimize the income received by the shareholders. This view is at odds with the Web3 community, which prefers not to think of its infrastructure as a company but rather as providing a public service to its users. The Ethereum blockchain is a good example. Ethereum owners do not directly receive any profit from the operation of the Ethereum blockchain when they do not stake their tokens. Returning to our distinction between security tokens and utility tokens, the former aligns nicely with maximizing income for token (share) holders, while the latter – which we are looking at – aligns well with maximizing the platform ecosystem values, including (primarily) its users.
If the normative discussion above seems too naive or conceited, we can also consider a more practical perspective. Suppose some participants have other, less charitable goals, such as maximizing their private income as token holders. How might they achieve this in the long term? Since network effects are an inherent driver of any Web3 system, the most important factor for a platform is growth. A platform that grows faster will survive, bringing not only more “social welfare” to the entire ecosystem, but also more benefits to creators and token holders. The main way a platform can grow is by making sure it actually provides as much utility as possible. Not only will this attract users to the platform because of the direct value they receive, but optimizing for users provides a better public message that is important in the Web3 community. An appropriate metaphor for this platform goal model might be more like a country than a company: the goal is not to increase shareholder value at the expense of any other good; the goal is to develop an entire economy that will ultimately improve conditions for all participants. Translating this into the day-to-day operations of the platform, we end up with a job whose goal is again to maximize social welfare.
The goal of a Web3 platform with a utility token should be to maximize the social benefits it provides.
2.2. How to maximize social welfare?
So, assuming that we do want to optimize social welfare for normative or practical reasons, how should we go about doing this? First, obviously the platform must provide some useful service, so for the rest of the discussion we assume that it does provide such a service. Lets get more specific and get into an economic model. When we say it provides some useful service, the service must be useful to someone. We call these “certain people” – those who can derive value from the platform – (potential) users. Let us abstractly call the service unit provided by the platform a transaction. The operation of the platform may require some resources and efforts, let us call the person (or company) that provides these resources and efforts the operator.
At this level of modeling, the basic question of maximizing social welfare boils down to which transactions the platform should serve. There are two reasons why we might not service transactions, even if some users derive value from them. First, it is possible that the cost (effort and resources) of a service transaction may be higher than the value it provides to the user, in which case the service transaction results in overall negative benefits. Secondly, the platform may have some capacity limits, and if the demand for transactions exceeds what it can offer, it will have to select the most valuable transactions and ignore others. To move forward in our analysis, it will be useful to delve into a very simple economic model of this situation.
2.3. Basic economic model
Let us try to describe a basic economic model that captures the essence of our situation: there are multiple transactions i = 1, 2,…, N that wish to be served by the platform. Each transaction i has a user who initiated it, who has a value vᵢ associated with it. A transaction also has a marginal cost cᵢ, the cost that the platform (through its operator) must incur in order to service it (in addition to the other transactions it is already servicing).
While in classical economic theory the marginal cost of a unit of a good tends to be a function of the number of other units that have been produced (increasing or decreasing marginal cost), in our case it is probably safe to consider the cost of the transaction to be fixed ( After some fixed costs to start operations, until the platform reaches a certain point of capacity limit).
Maximizing social welfare means choosing a set S of service transactions such that ∑ i∈S (vᵢ-cᵢ) is maximized among all possible transaction sets that fit within the platform capacity.
Which transactions should we service in this model? If we do not reach the capacity limit of the platform, then we should serve any transaction with a positive value of (vᵢ-cᵢ), i.e. vᵢ > cᵢ. How to achieve this? While we can assume that the platform can calculate (or at least estimate) the cost cᵢ associated with a service transaction, the value of the transaction vᵢ is subjective to the user interested in the transaction and therefore known only to him.
So here is the basic economics trick to do this: charge the user a transaction fee equal to the transaction that services him, i.e. cᵢ. In this case, the user will choose to run his transaction only if his private value vᵢ is higher than the cost, i.e. vᵢ > cᵢ. This is called marginal cost pricing, and is a basic fact introduced in Economics 101 courses: To maximize social welfare, the price of a unit should equal the marginal cost of providing the unit.
Block unicorn Note: In this model, we have many user-initiated transactions, and each transaction has a value assigned to it by the user and a cost for the platform service. While economic theory generally assumes that the marginal cost of a good is determined by the quantity of other products produced, here we assume that the cost of each transaction is fixed until the platform reaches a certain capacity limit.
Maximizing social welfare means selecting a set of served transactions that maximizes total user value minus service costs among all transactions that may fit into the platforms capacity. In short, the platform needs to select transactions that provide services to maximize the total value that users get from it minus the total cost of platform services while ensuring capacity limits.
To optimize social welfare, transaction fees should be set to their marginal costs. This aligns users net utility with social welfare.
In the case of congestion, marginal cost should also take into account the impact of servicing our transactions on other transactions that are not served. In this case, transaction fees should take into account not only the direct cost of the transaction cᵢ, but also the “congestion cost”: the net loss of social welfare it causes to other users. Lets see how this works in the simplest and most common case.
Single-dimensional GAS model: This is the simplest and most common model to describe the capacity constraints of Web3 systems. Each transaction has a size si that describes how much of the system resources it uses (borrowing Ethereum terminology, this might be called the GAS used by the transaction), and the system has a certain capacity of total resources (i.e. GAS) K. Therefore, if ∑i∈S si ≤ K, then a set of S transactions is feasible, and maximizing social welfare means maximizing ∑i∈S(vi-ci) under this constraint. Furthermore, in this model, the cost of running a transaction is considered to be proportional to its size cᵢ=αsᵢ, (where α is some global constant).
While there is generally no efficient algorithm to solve this optimization problem (as it is the classic knapsack problem), there is a well-known greedy approximation algorithm: sort transactions according to decreasing order of vᵢ/sᵢ and serve them starting from the top transactions until the point at which the next transaction will exceed the capacity limit (or until vᵢ
Block unicorn Note: The model discussed above is very simple and naturally ignores many aspects of the actual platform. However, the main economic lesson of our simple model should remain true in very general cases: to maximize social welfare, we should charge transaction fees equal to marginal cost. When congestion exists, transaction fees should also include congestion costs.
2.4. Transaction fee mechanism
While we have identified the necessary fees to ensure maximization of social welfare, we also need to define a specific mechanism that will enable our platform to actually collect these fees. These mechanisms must take into account that both users and operators of the platform act rationally and strategically, each trying to optimize their own utility, and that collusion between the operator and multiple users, whether real or fake of users are possible.
Although users should always be assumed to behave strategically, we only need to worry about operators strategic behavior when the operator has some leeway in its behavior, meaning that other operators cannot catch them Behavior inconsistent with the stated agreement.
Operators who don’t have this leeway just need to be incentivized to continue participating through some kind of bulk payment, “block reward”.
When leeway exists, such as when an operator decides which transactions to accept, the platform protocol needs to ensure that the operator is incentivized to behave in a desired manner. Its amazing how even a simple mechanism can achieve the required fees at its equilibrium point.
Pay Bid Mechanism: Take Bitcoin’s “Pay Your Bid” as an example, one of the simplest types of mechanisms for deciding which transactions to accept, and let’s look at why we expect it to approximate marginal cost (including congestion cost), thus approximately optimizing social welfare. The basic mechanism works as follows: at a specific point in time (block), there is a single operator (miner) who decides which transactions come in.
For our purposes, it does not matter how the operator is chosen, as long as one is chosen and the protocol ensures that his decision is likely to become consensus. Users submit bids for their transactions, and the chosen operator can accept any subset of these bids he wishes (within a given capacity) and collect bids for any transactions accepted.
So what do we expect to happen in the long run, reaching the equilibrium point? If we think of our situation as an economic market (for a trading space), we want the market to reach an equilibrium where fees equal marginal costs and social welfare is maximized.
Equilibrium in the GAS model: Let us return to our one-dimensional resource model (if it is complicated, please see the blue font annotation of Block unicorn below for a rough explanation). In this model, each transaction i has a value vᵢ and a size sᵢ , the cost is proportional to its size cᵢ=αsᵢ, and the total capacity of the block is limited by K. Now, the owner of each transaction puts forward a bid bᵢ. Looking back at the operator deciding which deals to accept, it is clear that an operator that gets a bid bᵢ will accept the set of bids S such that ∑i∈S bi reaches the maximum (ignoring integer constraints), which means accepting the one with the highest bᵢ/sᵢ ratio The set of bids until the block capacity is reached.
We expect the bidding dynamics to allow bidders to find and bid (roughly, in the long run) the lowest value bᵢ that makes their transaction accepted, as long as bᵢ ≤ vᵢ, otherwise they are unwilling to pay bᵢ. The equilibrium reached under this assumption will have bidders whose value per unit size ratio bᵢ/sᵢ is high enough to bid at the equilibrium gas price p, while lower value bidders will bid at a lower value .
That is, every bidder with vᵢ≥psᵢ will bid with bᵢ=psᵢ,while vᵢ
In order to handle the case of no congestion, 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.
Block unicorn Note: Under this model, we expect users to set their bids to the highest value they are willing to pay for a service, as long as that value is higher than their valuation of the service. Operators will tend to choose deals with the highest bid/size ratio, as this maximizes their total revenue. This equilibrium state will result in maximizing social welfare, since the most valuable transaction of services will be selected and the marginal cost is reasonably compensated.
In terms of incentive compatibility mechanisms, we might be interested in how quickly and to what extent the pay-as-bid mechanism reaches (at least approximately) this equilibrium state, and how users figure out the magic parameter p* they need in order to Bid appropriately. More complex fee mechanisms, such as EIP-1559 used in Ethereum, can make the bidding process more transparent (called incentive compatibility in mechanism design terms), thereby directly leading the system to an efficient equilibrium state, maximizing the to increase social welfare as much as possible and to make expenses equal to marginal costs¹⁴. A wealth of knowledge already exists on how to design these mechanisms¹⁵, and this existing knowledge is applicable to more complex and realistic scenarios.
Extracting Value from Users (MEV): Now consider “hidden fees”, i.e. when mechanisms allow operators to extract some value from user transactions. The nature of this extraction will certainly depend on the platforms services, but a typical example in blockchain is that a validator who creates a block can add their own transactions to preempt certain user transactions, thereby transferring value to On oneself. This opportunistic value extraction has nothing to do with transaction service costs or congestion, so these implicit MEV fees are inconsistent with the normal economic functioning of the system and may, for example, drive away users who could be exploited. Therefore, mechanisms should minimize the possibility of such extraction, although sometimes it may not be completely eliminated.
2.5 Conclusion: Micro-tokenomics
Therefore, the main point of this section is that a Web3 system with utility tokens should aim to maximize the social welfare (i.e., added value) it provides. This is achieved when the charges equal the marginal cost of the transactions offered (including congestion costs). In fact, there are economic mechanisms that could lead to achieving this goal. Although the details can be complicated depending on the complexity of the platform, the basic principles still apply.
Macro Token Economics: Staking Costs and Newly Minted Tokens
In this section, we describe macro-token economics, focusing on the relationship between the rate at which new tokens are minted, staker rewards, and the security provided by staking. Our main argument is that staker rewards should cover the staker’s cost of capital, preferably paid out through new minting, and should be the primary factor in determining minting speed.
The previous section looked at transaction fees, which can be viewed as the microeconomics of a Web3 platform that provides some utility to its users. We now turn our attention to the macroeconomics of the platform: how the entire system is funded and how the tokens are managed. Again we emphasize our focus on simplicity and generality, while noting that real systems may involve more complex considerations, but hopefully our analysis can still serve as a useful starting point. We start with what we consider to be the main gap between the microeconomic analysis above and the economic feasibility of the system.
3.1. Fixed costs
The formula of charging based on marginal cost masks a core issue, which is the issue of non-marginal costs. Lets be more clear. In all our discussion above, the only cost regarding servicing some transaction i is the increased cost of servicing this transaction compared to all other transactions, which indeed determines whether we should service this additional transaction (assuming we have determines which other transactions are to be serviced).
Consider an example, the cost of servicing N transactions is $100+N*$1, that is, the cost of servicing 9 transactions is $109, and the cost of servicing 10 transactions is $110.
In this case, we would say 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 charge marginal costs, then we will only collect $1 from each transaction, but where will the missing $100 (i.e. fixed costs) come from? This problem of deficit when charging only marginal costs is particularly evident whenever marginal costs are less than average costs, which seems to be a typical situation in blockchain.
While in the “real world” any fixed costs must ultimately be paid by the users themselves, thus making marginal cost pricing impractical, in a tokenized platform fixed costs can be paid for by minting new tokens. This has the advantage of keeping expenses at the marginal cost level. Of course, someone still has to pay the fixed costs, and that person is the collection of all token holders. That is, minting new tokens means we inflate the underlying token, potentially reducing its value, so each token holder effectively loses a small portion of the value of their token.
One might wonder whether it is reasonable or desirable to place this burden on token holders. We think this is the least bad option. First, it allows us to charge users only marginal costs, thereby maximizing system usage, which as we discussed above is our fundamental goal. Second, once usage of the system is indeed maximized, one would expect that the total value of the platform would increase, thereby increasing the value of the tokens, which would compensate holders of the same tokens for paying for the fixed costs.
To achieve marginal cost pricing, any fixed costs associated with operating the platform are best paid for by minting new tokens.
Looking at existing blockchains, this is currently more or less the norm: new tokens are minted to pay for “block rewards,” which are independent of the specific transactions in the block and reward miners, stakers, or Sorter. These block rewards essentially cover the associated fixed costs, while transaction fees are an additional component paid to operators.
Concerned readers may have questions about the sustainability of this process: Does it make sense for token holders to subsidize the platform indefinitely? What is the end here? There are several possible “endgames”: First, the platform may achieve sustainable growth as part of the sustainable growth of the world economy. Another possibility is that the growth in demand for platform services exceeds the growth in platform supply. In this case, congestion charges will continue to grow (for the micro-token economic reasons detailed above) and since these charges are not costs actually borne by the system operator, the congestion charges can cover the fixed costs.
Yet another possibility is that as usage of the platform grows, the fixed costs become so small compared to the growing marginal costs that they can be treated as a small add-on to fees without causing significant distortions. Finally, if all of the above is not enough, we can imagine that after enough growth, the platform will indeed gradually increase fees beyond the specified marginal cost, just like in the real world (costs will continue to decrease).
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 who hold a certain amount of tokens and stake them in the system are giving up the use of those funds for other purposes, either directly or by selling their tokens in exchange for fiat currency (such as U.S. dollars). These costs are essentially financial as determined by the external financial environment (e.g. current interest rates), platform-related factors (real and perceived risks involved in staking the tokens), and other possible uses of the tokens (e.g. providing liquidity in AMMs) cost. Specifically, if the total staking amount is S (in USD), and the staker earns r% in return per year, the total annual cost of staking is r%*S.
Block unicorn Note: When we talk about staking costs in a proof-of-stake system, we are actually talking about the stakers giving up other possible benefits in order to participate in the system. Specifically, if a person holds some tokens and stakes them in the system, then the person cannot use those funds for other purposes, such as direct use, or by selling the tokens for fiat currency (such as USD) .
These costs depend primarily on the external financial environment (such as current interest rates), as well as the risks associated with staking in the system and other potential uses of the tokens. If a staker earns a certain percentage of returns each year, then the total annual cost of staking is that percentage multiplied by the total value of the stake.
Taking Ethereum as an example, let us calculate the staking cost of the Ethereum network as the largest proof-of-stake platform based on the data shown in Table 1 in early August 2023. At the time, approximately 19% of the Ethereum platform’s tokens were staked, putting the total value of staked tokens at $42 billion since the total value of all tokens was $224 billion. According to the table, these tokens earn returns of approximately 5% per year, resulting in a total annualized staking cost of over $2 billion. The number of transactions on Ethereum is around 400 million per year (just over 12 transactions per second), so we are talking about a cost of over $5 per transaction, which probably accounts for the majority 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, it is natural to mint only the required amount, as new minting is a burden on token holders. The protocol needs to ensure that the rewards allocated incentivize operators to participate and behave correctly, so the right balance must be found between adequately rewarding operators and minimizing new minting. We argue that incentives can generally be handled relatively easily at the microeconomic level, and therefore the main factor that should determine minting rates is providing incentives for the operators cost of capital.
For example, lets go back to the standard model of blockchain, where each block has a single operator, the leader, who is responsible for building the block and bearing most of the costs, while other operators basically Blocks are simply signed using some consensus protocol. For such a system to function properly, the leader must be compensated considerably to encourage him to build blocks, and all other operators must be compensated to continue to stay alive. The latter is usually easy to do because they have no significant agency rights and therefore no significant incentive constraints from a macroeconomic perspective.
Rewarding the leader of a block is usually a more subtle issue, because the leader has a lot of discretion, so we need to incentivize him appropriately. However, this is handled directly by the transaction fee mechanism, which incentivizes inclusion of the correct transactions exactly by using correct marginal cost pricing to account for the leaders incentives. In addition to these incentives to handle marginal costs appropriately, we only need to compensate the leader for its fixed costs, and a sufficiently large fixed block reward will do this.
The main factor in determining the casting rate should be to provide incentives for the operators cost of capital.
In our analysis, we will assume that the reward rate that operators receive from the platform is determined by the stakers themselves, based on their own financial calculations. A stakers financial considerations may relate to the financial environment, the perceived risks and potential of the platform and token, and alternative uses for the token.
While it may be possible to apply various financial models to estimate how the required reward rate depends on other financial parameters (such as external interest rates or the historical volatility of token exchange rates²¹), we will not require these estimates and will continue to require Reward rates are considered given.
According to the empirical data of different large platforms listed in Table 1, the annual return rate for stakers ranges between 2% and 20%, with typical rates ranging from 3% to 7.5%, and the median rate is about 5%. This significant variability may depend on a range of factors, and there is undoubtedly considerable noise as to what exactly these numbers mean.
Nonetheless, we can get a fairly consistent picture of a reasonable reward rate, placing it at a level comparable to typical bond or stock yields.
3.4. New coins
The platform must provide its operators with sufficient staking rewards, otherwise the operators will not agree to participate in operating the platform. As mentioned above, enough is determined by the stakers themselves and is primarily a financial issue. So how can platforms be designed to meet this? Thats what were trying to solve now. Our basic analysis will relate staking costs to fixed costs and assume that the source of staking rewards will be newly minted tokens that will be distributed proportionally to stakers on average. We will only focus on the overall amount of coins minted and rewards, not their precise composition, which we assume can be handled correctly via the transaction fee mechanism.
For the sake of a simple analysis, let us focus on the following parameters: (1) Annual minting rate as a percentage of the total existing token supply, (2) Annual staking reward rate as a percentage of the pledged amount (3) Staking rate, i.e. staked tokens The amount accounts for the proportion of all circulating tokens. The overall equality that governs this relationship is:
(Annual new coin minting rate) = (Annual staking reward rate) * (Staking rate)
We’ve already discussed the staking reward rate, now let’s take a closer look at the new mint rate. This rate is determined by the protocol, which should dictate when new tokens are minted (or conversely, destroyed). Under our assumptions, new mints are used to pay for staking rewards, which is equal to the net sum of all annual rewards distributed by the protocol. Specifically, in a block-based protocol, if the protocol stipulates that the total reward per block is R tokens (on average, the net destruction of all operators combined), where the total number of existing tokens is S, each year There are N blocks, then the annual rate of new coinage is RN/S (the new coinage rate is the speed at which the system creates new tokens in order to encourage people to participate and keep the system active).
It can be noted that under this equation, the staking reward is nominal, that is, the inflation of the token value is not taken into account. This may be the appropriate way to look at things for those stakers who do believe that new minting does not really dilute the value of their tokens, as it would allow the platform to grow faster than the minting rate. For those stakers who are less sure about this point of view, they may be interested in the actual reward rate or the adjusted reward rate, which is balanced by subtracting the minting rate from the reward rate, giving The following equation: (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 owning the tokens as a means of protecting against false identity attacks. In other words, the implicit consensus of the system is formed by operators who jointly hold enough tokens. Let us examine why we would trust this type of consensus. The first reason is simply that we do not believe that any malicious party has sufficient resources to control the majority of the stakers, and that non-malicious stakers will faithfully follow the protocol. The second reason is that any group of parties that collectively own a majority of the tokens will suffer significant losses if the platform ceases to function properly, as the token value is likely to drop significantly in such an event. The first argument is a typical honest majority argument in computer science, while the second is a game theory incentive argument in economics.
Quantifying both of these safety reasons is a rather imprecise process, as they each depend on many factors. For the first reason, we have to try to figure out what proportion of total staking the malicious parties that the platform has to defend against. For the second reason, we should estimate the economic gain that could be gained by a malicious alliance occupying the majority of staking power, as well as the economic loss caused by the decrease in the value of the token due to such manipulation. While precise quantification is difficult, in both cases the gains that could result from malicious ownership of a majority of staked tokens appear to be on the order of a constant proportion of the total value of all tokens.
Therefore, achieving reasonable security in the face of malicious actors requires at least some constant proportion of total tokens to be staked. The exact constants required for different security levels will certainly vary depending on possible manipulation between platforms, token value and liquidity, what is locked, and the nature of this locking. Nonetheless, for any specific platform, we can think of the proportion of tokens staked as a proxy for the security gained. Empirically, looking at Table 1, the staking ratios of the major platforms range from 20% to 70%, with the lowest staking ratio usually being the largest platform.
In a proof-of-stake platform, the proportion of tokens staked should reach at least some platform-related constant, and as this proportion increases, security also increases.
The required minting rate²⁶ can be calculated given the required security level and an estimate of the rewards currently demanded by stakers. Lets take the median value from Table 1 as an example: Assume that stakers demand a 5% annual return, and we want the staking ratio to be 50%. Then, according to the equation, the required annual minting rate is 2.5% (50% * 5%). This calculation is static, assuming that the required staking rewards and desired staking rate are both fixed.
Lets see how this type of calculation works in a protocol. Generally speaking, the minting protocol can determine the block reward and thus the minting rate. Once the minting rate is set, stakers decide whether to stake their tokens, and the minted tokens are then essentially distributed among stakers, providing their staking rewards. We can reasonably 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 satisfied: if the staking rate is lower than the level required by the equation, then each staker will receive a higher reward than needs, so there will be more to stake Investors poured in to pledge. If the staking rate is too high, the rewards are too low and stakers will leave. Balance can only be achieved when the staking rate brings the staking rewards in line with 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 alternative financial uses for tokens within the platform become more attractive, stakers may demand higher rewards, causing the staking rate to decrease. 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 minting rate “once and for all.” Instead, since the platform can observe the current staking rate, it can use this information to determine the minting rate. Such a dynamic mint rate mechanism might allow for more fine-grained control over the equilibrium of staking rate and mint rate as a function of the desired staking reward observed from staker behavior.
For example, Ethereum defines a curve where the minting rate increases in proportion to the square root of the staking rate, causing the reward rate to decrease in proportion to the square root of the staking rate. Another option is a dynamic protocol where the minting rate is increased when the staking rate is below the required level (and the minting rate is reduced when the staking rate is above the level deemed necessary). In both cases, equilibrium is reached only when the reward rate is equal to the level required by the stakers.
3.6. Bottom Line: Macro Token Economics
Therefore, the main point of this section is that a proof-of-stake platform with a utility token should cover any fixed costs of the platform by minting new tokens. The major component of fixed costs may be the capital 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.
