Utility Tokens and Proof of Stake: An Innovative Approach to Platform Fixed Cost Payments
TechFlow Selected TechFlow Selected
Utility Tokens and Proof of Stake: An Innovative Approach to Platform Fixed Cost Payments
A proof-of-stake platform with a utility token should cover any fixed costs by minting new tokens.
Navigating Web3 tides with focused insightsAuthor: Noam Nisan
Translation: Block unicorn
This article discusses "Web3 platforms with proof-of-stake and utility tokens," a fairly common class of platforms within the "blockchain world." We briefly explain the meaning of each term, and Table 1 lists some of the largest such platforms as of early August 2023 along with several key "financial" metrics.
Table 1: Proof-of-stake systems with utility tokens having at least $3 billion market cap (Source: Retrieved from stakingrewards.com on August 7, 2023)
Our goal here is to propose simple and broad principles regarding the token economics of such systems—commonly referred to as "tokenomics." We pursue extreme simplicity; any specific system will require more complex analysis based on its particular goals, constraints, and environment. Nonetheless, we hope the views presented here can serve as a useful way of thinking about these issues, and perhaps even as preliminary design guidelines.
The Type of System We Are Discussing
Here we elaborate on what is meant by a "Web3 platform with proof-of-stake and utility tokens," and argue that such platforms must deliver real utility to users, grow to sufficient scale, and reward their operators.
1.1 Web3 Platforms
We use the term "Web3 platform" to refer to any computing platform that provides online services in a way that achieves consensus and trust without relying on any trusted central party. Basic examples include cryptocurrencies like Bitcoin, digital economy platforms like Ethereum, various decentralized "Layer 2" layers that enhance Ethereum, or specialized decentralized application platforms for finance (DeFi). The key point is that these systems should operate in such a way that you can trust them without depending on the proper behavior—or even existence—of any single company, institution, or government. Essentially, a single trusted entity is replaced by consensus among numerous small participants.
Of course, one might question the desirability or importance of such systems that bypass traditional trusted mechanisms like banks and financial institutions. But this paper takes it as given that many people want such systems and consider it worthwhile—and important—not to rely on centralized entities in certain applications.
The level of trust provided by a Web3 platform clearly depends on the number and quality of the many parties collaborating to support the system's trustworthiness. Thus, such platforms exhibit strong positive feedback network effects: the more the platform grows, the greater the trust in it, hence the higher the value it delivers, attracting more participation and further growth.
A critical requirement for any Web3 system is to initially grow and then maintain a size large enough to produce significant network effects.
1.2 Proof-of-Stake
Since the security of Web3 systems relies on cooperation and agreement among many small parties, a key challenge every Web3 system must address is Sybil attack resistance: How do we ensure that what appears to be a large group of independent actors is not actually a single controlling organization masquerading as many? Following the Bitcoin network, early systems addressed this via "proof-of-work," where supporting parties had to demonstrate computational power. As Bitcoin became popular, the amount of computation required grew so large that electricity consumption accounted for a significant fraction of global usage, contributing non-negligibly to global warming.
While there have been proposals for other forms of Sybil resistance—such as "proof-of-personhood," identifying actual humans—the only alternative currently with significant practical use may well be "proof-of-stake." In such systems, participants must own some system "token," and the quantity they hold determines their "identity" within the system. Specifically, protocols within the system are agreed upon by a majority (or possibly supermajority) of stakeholders.
There is extensive literature comparing proof-of-stake and proof-of-work systems, but here is how a typical proof-of-stake system works from an economic perspective. Initially, the platform "mints" a certain number of tokens and distributes them somehow. To participate in operating the platform, operators must acquire some tokens on the open market and "stake" them—locking them into the platform—as collateral for proper operation. In return for staking tokens and continuously participating in operations, the platform typically rewards stakers with additional tokens (which they can then sell on the open market). These rewards may come from fees paid by users, newly minted tokens, or a combination. If rewards come from new mints, then clearly the total token supply increases (i.e., the token is inflationary). Another possibility is granting operators the right to extract some value from system users, commonly known as Miner Extractable Value (MEV).
Stakers in a proof-of-stake platform must be rewarded through user fees, new token issuance, value extraction from users, or some combination thereof.
In the table above, we see "tokenomic" data for the largest proof-of-stake platforms, including Ethereum valued at over $200 billion and another eight platforms each worth billions of dollars (at time of writing, many smaller platforms also exist, about 50 of which are each valued over $100 million). As we can see, the actual rewards provided to stakers (annual percentage return relative to their staked amount) range from 2% to 20% APR, with a median slightly above 5%. When adjusted for token inflation, real returns range from 0% to 10%, with a median around 3%. Not all tokens in these systems are staked; the staked proportion ranges from 15% to 70%, with a median near 50%. One goal of this paper is to provide a principled way of thinking about these numbers.
1.3 Utility Tokens
There are many types of tokens and multiple ways to classify them. In this paper, we are interested in classification by economic use. This classification includes three types: payment tokens, utility tokens, and security tokens. Payment tokens aim to act as "money," typically serving as a medium of exchange and store of value—examples include Bitcoin and many stablecoins. Security tokens are financial instruments that grant holders certain legal rights or claims against the issuer, much like traditional securities (e.g., stocks or bonds).
Utility tokens allow automated access to certain services from the platform, enabling users to derive some benefit. Most commonly, utility tokens can be used to pay fees for using the platform, where the platform offers some service to users. For example, the Ethereum blockchain provides a service of executing transactions on its public ledger—the so-called "world computer"—a service many users desire and are willing to pay substantial fees for. Ethereum’s native token, ETH, is the only way to pay for this service, so potential Ethereum users must first buy ETH from someone willing to sell before using the blockchain.
When analyzing a Web3 platform purely from a "utility" standpoint, it becomes clear that a key goal of such a system is to genuinely deliver maximum utility to users. Naturally, delivering utility via a Web3 platform requires maintaining sufficient trust and openness while meeting other platform-specific requirements. Holding tokens becomes a key enabler of the required trustless collaboration. From a utility-driven perspective, the purpose of tokens and their tokenomics should serve the goal of delivering utility. Here, we conduct a clean "microeconomic" analysis of tokens.
Clearly, most utility tokens may also serve other functions and to some extent act as payment tokens. One might suspect that the current value of ETH reflects not only its utility in running transactions on the Ethereum blockchain but also its role as a store of value and means of payment, similar to Bitcoin. Our analysis applies when a token’s value—either entirely or significantly—derives from its utility aspect.
Micro Tokenomics: Fees and Social Welfare
In this section, we describe the microeconomics of tokens, focusing on transaction fees users must pay to use the platform. We argue that optimal transaction fees should equal the marginal cost incurred by the platform in processing transactions, including congestion costs (if any).
Since platforms with utility tokens, by definition, provide some service to users, a market for this service naturally emerges—one that determines who gets served and how much they pay. This section provides a basic analysis of such a market.
To maintain our goal of simplicity, we keep the discussion as simple as possible while still covering what we believe are the essential economic features of utility-based Web3 systems. In particular, we adopt a "static" analysis, avoiding time and dynamics—which are often harder to handle—but we believe the same principles should apply.
2.1 Platform Goals and Social Welfare
First, we must clarify what the platform should aim to optimize. While the initial reaction might be "make the platform builders rich," such cynicism ignores participant behavior in the platform ecosystem and fails to offer actionable guidance. We defend the opposite view: the platform's goal should be to maximize the total value it brings to the "world"—what economists sometimes call maximizing social welfare.
Let us start from a normative perspective: What should the platform optimize? If we view the platform as a company and its tokens as stock, it would seem natural to maximize income to "shareholders." However, this view conflicts with the ethos of the Web3 community, which dislikes seeing its infrastructure as a company and prefers viewing it as providing public services to users. The Ethereum blockchain is a good example: those who hold ETH but do not stake it receive no direct profit from Ethereum’s operation. Returning to our distinction between security tokens and utility tokens, the former aligns well with maximizing income to token (stock) holders, while the latter—which we focus on—aligns with maximizing the value of the platform ecosystem, primarily its users.
If the above normative argument seems too naive or idealistic, consider a more pragmatic view. Suppose some participants have less altruistic goals, such as maximizing their private income as token holders. How could they achieve this in the long run? Since network effects are inherent drivers of any Web3 system, the most important factor for a platform is growth. A faster-growing platform will survive, bringing more "social welfare" to the entire ecosystem and more returns to creators and token holders. The main way a platform grows is by ensuring it delivers as much utility as possible. This attracts users due to direct value and also sends a stronger public signal—a valuable trait in the Web3 community. An appropriate metaphor for such a platform may be more like a nation than a company: the goal is not to increase shareholder value at all costs, but to develop an entire economy that ultimately improves conditions for all participants. Translating this into daily platform operations, our working objective again becomes maximizing social welfare.
The working goal of a Web3 platform with a utility token should be to maximize the social welfare it provides.
2.2 How to Maximize Social Welfare?
Assuming we wish to optimize social welfare for normative or practical reasons, how should we proceed? First, obviously, the platform must provide some useful service, so we assume it does throughout the rest of the discussion. Let us get more concrete and introduce an economic model. When we say it provides a useful service, that service must be useful to someone. We call these "someones"—those who can derive value from the platform—the (potential) users. Let us abstractly refer to a unit of the platform's "service" as a transaction. Running the platform may require some resources and effort; let us call those providing these resources and effort (individuals or companies) the operators.
At this level of modeling, the core problem of maximizing social welfare reduces to which transactions the platform should serve. There are two reasons why we might not serve a transaction even if some user gains value from it. First, the cost (effort and resources) of servicing the transaction might exceed the value it provides to the user, resulting in net negative welfare. Second, the platform may have capacity limits; if demand exceeds supply, it must choose the most "valuable" transactions and ignore others. To advance our analysis, it will be useful to dive into a very simple economic model of this situation.
2.3 Basic Economic Model
Let us try to describe a basic economic model capturing the essence of our scenario: multiple transactions i=1,2,…,N that the platform may serve. Each transaction i has a user initiating it, who assigns it a value vᵢ. The transaction also has a marginal cost cᵢ—the cost the platform (via its operators) must incur to serve it, beyond what is already spent serving other transactions.
While in classical economic theory, the marginal cost per unit of a good is often a function of the number of units already produced (increasing or decreasing marginal cost), in our case, it may be safe to assume transaction costs are fixed (after some fixed startup costs, until the platform reaches a certain capacity limit).
Maximizing social welfare means selecting a set S of transactions to serve such that ∑ i∈S (vᵢ−cᵢ) is maximized across all possible sets fitting within the platform's capacity.
Which transactions should we serve in this model? If we haven’t reached the platform’s capacity limit, we should serve any transaction with positive (vᵢ−cᵢ), i.e., vᵢ > cᵢ. How can we achieve this? While we may assume the platform can compute (or at least estimate) the cost cᵢ associated with serving a transaction, the value vᵢ is subjective to the user interested in that transaction—only they know it.
Thus comes the fundamental economic trick: charge users a transaction fee equal to the cost of serving their transaction, i.e., cᵢ. In this case, users will choose to run their transaction only if their private value vᵢ exceeds the cost, i.e., vᵢ > cᵢ. This is called "marginal cost pricing," a basic principle taught in Economics 101: to maximize social welfare, the price per unit should equal the "marginal cost" of providing that unit.
Block unicorn note: In this model, we have many user-initiated transactions, each with a user-assigned value and a platform service cost. While economic theory usually assumes marginal cost depends on prior production volume, here we assume each transaction has a fixed cost until the platform hits a capacity limit.
Maximizing social welfare means selecting a set of served transactions that maximizes total user value minus service costs, subject to capacity constraints. In short, the platform must choose which transactions to serve—within capacity limits—to maximize total user value minus total service cost.
To optimize social welfare, transaction fees should be set to marginal cost. This aligns users' net utility with social welfare.
Under congestion, "marginal cost" should also account for the impact of serving our transaction on others who fail to get service. In this case, transaction fees should cover not only the direct cost cᵢ but also the "congestion cost"—the net loss in social welfare imposed on other users. Let us see how this works in the simplest and most common case.
One-dimensional GAS model: This is the simplest and most common model for describing Web3 system capacity constraints. Each transaction has a size si representing how much system resource it consumes (borrowing Ethereum’s terminology, this might be called the GAS used by the transaction), and the system has a total resource (i.e., GAS) capacity K. Thus, a set S of transactions is feasible if ∑i∈S si ≤ K, and maximizing social welfare means maximizing ∑i∈S(vi−ci) under this constraint. Additionally, in this model, the cost of running a transaction is assumed proportional to its size: cᵢ=αsi (where α is some global constant).
While there is generally no efficient algorithm to solve this optimization problem (as it is the classic knapsack problem), a well-known greedy approximation exists: sort transactions in decreasing order of vᵢ/sᵢ and serve them starting from the top until adding the next would exceed capacity (or until vᵢ
Block unicorn note: The model discussed above is very simple and naturally omits many aspects of real platforms. However, the main economic lesson from our simple model should remain valid 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 cost."
2.4 Transaction Fee Mechanisms
Although we’ve identified the necessary fees to ensure maximal social welfare, we also need to define a concrete mechanism enabling the platform to actually collect these fees. These mechanisms must account for the fact that both users and operators will act rationally and strategically, each trying to optimize their own utility, and collusion among operators and users—real or fake—is possible.
While users should always be assumed to behave strategically, we only need to worry about operator strategic behavior when operators have discretion—that is, when other operators cannot "catch" them violating the protocol.
Operators without discretion only need to be incentivized via some bulk payment—"block rewards"—to continue participating.
When discretion exists—for example, when operators decide which transactions to accept—the platform protocol must ensure operators are incentivized to act as desired. Surprisingly, even simple mechanisms can achieve the desired fees at equilibrium.
Pay-your-bid mechanism: Take Bitcoin’s "pay-your-bid" as an example—one of the simplest mechanisms for deciding which transactions to accept—and let us see why we expect it to approximately charge marginal cost (including congestion cost), thus approximately optimizing social welfare. The basic mechanism works as follows: at a given time (block), a single operator (miner) decides which transactions go in.
For our purposes, how the operator is chosen doesn’t matter, as long as one is selected and the protocol ensures their decision likely becomes consensus. Users submit bids for their transactions, and the chosen operator may accept any subset of these bids (within capacity limits) and collects the bid amount for each accepted transaction.
What do we expect to happen in the long run—at equilibrium? If we view our scenario as an economic market (for transaction space), we expect the market to reach equilibrium, where fees equal marginal cost and social welfare is maximized.
Equilibrium in the GAS model: Let us return to our one-dimensional resource model (see Block unicorn’s blue font notes below for a simplified explanation if this seems complex). In this model, each transaction i has value vᵢ, size sᵢ, cost proportional to size cᵢ=αsᵢ, and total block capacity limited by K. Now, each transaction owner submits a bid bᵢ. Clearly, the operator receiving bids will accept the set S of bids that maximizes ∑i∈S bi (ignoring integer constraints), meaning accepting bids with the highest bᵢ/sᵢ ratio until block capacity is filled.
We expect bidding dynamics to allow bidders to find and bid (roughly, in the long run) the minimum bᵢ needed to get their transaction accepted, as long as bᵢ≤vᵢ—otherwise they wouldn’t be willing to pay bᵢ. At equilibrium under this assumption, bidders with high enough vᵢ/sᵢ ratios will bid at a "clearing gas price" p, while lower-value bidders will bid less.
That is, each bidder with vᵢ≥psᵢ will bid bᵢ=psᵢ, while those with vᵢ
To handle the no-congestion case—where transactions with vᵢ≥cᵢ=αsᵢ do not fill 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 bid price to the maximum they are willing to pay, as long as it exceeds their valuation of the service. Operators will prefer transactions with the highest bid-to-size ratio, as this maximizes their revenue. This equilibrium leads to maximal social welfare, as the most valuable transactions are selected and marginal costs are properly compensated.
Regarding incentive-compatible mechanisms, we may care about how quickly and closely the "pay-your-bid" mechanism reaches (at least approximately) this equilibrium, and how users discover the magical parameter p* to bid appropriately. More sophisticated fee mechanisms, such as Ethereum’s EIP-1559, can make the bidding process more transparent (in mechanism design terms, "incentive-compatible"), directly guiding the system to an efficient equilibrium that maximizes social welfare and sets fees equal to marginal cost¹⁴. There is already a large body of knowledge on designing such mechanisms¹⁵, and this existing knowledge applies to more complex and realistic scenarios as well.
Value extraction from users (MEV): Now consider "hidden fees," where the mechanism allows operators to extract some value from user transactions. The nature of this extraction certainly depends on the platform’s service, but a typical example in blockchains is when a block proposer adds their own transaction to "front-run" certain user transactions, thereby transferring value to themselves. Such opportunistic value extraction is unrelated to transaction service costs or congestion, so these implicit MEV fees are inconsistent with the system’s proper economic functioning—for instance, potentially driving away users who can be exploited. Therefore, mechanisms should minimize such extraction possibilities, though complete elimination may sometimes be impossible.
2.5 Conclusion: Micro Tokenomics
Thus, the key takeaway from this section is that Web3 systems with utility tokens should aim to maximize the social welfare (i.e., value-added) they provide. This goal is achieved when fees equal the marginal cost (including congestion cost) of the transactions provided. Indeed, there exist economic mechanisms that can lead to this outcome. Although details may be complex depending on platform complexity, the basic principles remain applicable.
Macro Tokenomics: Staking Costs and New Token Issuance
In this section, we describe macro tokenomics, focusing on the relationship between the rate of new token issuance, staker rewards, and the security provided by staking. Our main argument is that staker rewards should cover the capital cost of staking, preferably paid via new issuance, and should be the primary factor determining the issuance rate.
The previous section focused on transaction fees, which can be seen as the microeconomics of a Web3 platform providing utility to users. We now turn to the platform’s macroeconomics: how the entire system is funded and how tokens are managed. Again, we emphasize simplicity and generality, noting that real systems may involve more complex considerations, but we hope our analysis still serves as a useful starting point. We begin with what we see as the main gap between the above microeconomic analysis and the economic feasibility of the system.
3.1 Fixed Costs
The formula of charging marginal cost hides a core issue: the problem of "non-marginal" costs. Let us be more explicit. In all our earlier discussions, the only cost of serving transaction i was the incremental cost compared to serving all other transactions—an amount that indeed determines whether we should serve this additional transaction (assuming we’ve already decided which others to serve).
Consider an example: the cost of serving N transactions is $100 + N×$1, so serving 9 transactions costs $109, and serving 10 costs $110.
In this case, we say there is a $100 fixed cost and a $1 marginal cost. Although the marginal cost is $1, the average cost of serving 10 transactions is $11. If we only charge marginal cost, we can collect only $1 per transaction, but where will the missing $100 (the fixed cost) come from? This deficit problem is especially pronounced whenever marginal cost is less than average cost—a typical scenario in blockchains.
While in the "real world," any fixed cost must eventually be paid by users, making marginal cost pricing impractical, in a tokenized platform, fixed costs can be covered by minting new tokens. This has the advantage of keeping fees at marginal cost levels. Of course, someone still pays the fixed cost—and that someone is the collective of all token holders. That is, minting new tokens inflates the relevant token, potentially reducing its value, so each token holder effectively loses a small portion of their token’s value.
One might wonder whether burdening token holders in this way is reasonable or desirable. We believe it is the least bad option. First, it allows us to charge users only marginal cost, maximizing system usage—which, as discussed above, is our fundamental goal. Second, once system usage is truly maximized, the platform’s total value is expected to increase, raising the token’s value and compensating the same token holders who paid for the fixed cost.
To enable marginal cost pricing, any fixed costs associated with operating the platform should best be paid by minting new tokens.
Looking at existing blockchains, this is more or less the current norm: new tokens are minted to pay "block rewards," which are independent of specific transactions in the block, rewarding miners, stakers, or sequencers. These block rewards essentially cover the relevant fixed costs, while transaction fees form an additional component paid to operators.
Readers skeptical about sustainability may ask: Does it make sense for token holders to indefinitely subsidize the platform? What is the "endgame"? Several possible "endgames" exist: First, the platform may sustainably grow as part of the world economy. Second, demand for platform services may grow faster than supply. In this case, congestion fees will continue to rise (due to micro tokenomic reasons detailed above), and since these fees are not actual costs borne by operators, congestion fees can cover fixed costs.
Another possibility is that as platform usage grows, fixed costs become negligible compared to rising marginal costs and can be covered by a small fee surcharge without causing significant distortion. Finally, if none of the above suffice, we can imagine that after sufficient growth, the platform gradually raises fees above prescribed marginal cost, just like in the "real world" (costs will continuously decrease).
3.2 Staking Costs
In proof-of-stake systems, the most significant fixed cost is typically the financial cost of staking—sometimes called "security cost," "capital cost," or "opportunity cost." Specifically, a staker holding a certain amount of tokens and locking them into the system forgoes using those funds elsewhere, either directly or by selling tokens for fiat currency (e.g., USD). These costs are essentially financial costs determined by the external financial environment (e.g., current interest rates), platform-related factors (real and perceived risks of staked tokens), and other potential uses of the token (e.g., providing liquidity in AMMs). Specifically, if total staked amount is S (in USD) and stakers earn r% annual return, the total annual staking cost is r%×S.
Block unicorn note: When discussing staking costs in proof-of-stake systems, we are referring to the opportunity cost stakers face by participating in the system. Specifically, if someone holds tokens and stakes them, they cannot use those funds elsewhere—either directly or by selling tokens for fiat currency (e.g., USD).
These costs mainly depend on the external financial environment (e.g., current interest rates), risks associated with staking in the system, and other potential uses of the token. If stakers earn a certain annual return, the total annual staking cost equals that percentage multiplied by the total staked value.
Take Ethereum as an example: let us calculate the staking cost of the Ethereum network—the largest proof-of-stake platform—using data shown in Table 1 from early August 2023. At that time, about 19% of Ethereum’s tokens were staked. With a total token value of $224 billion, the total staked value was $42 billion. According to the table, these tokens earned about 5% annual return, so the total annual staking cost exceeded $2 billion. Ethereum processes about 400 million transactions per year (slightly over 12 per second), meaning a cost of over $5 per transaction—likely constituting a major portion of Ethereum’s total operating cost.
3.3 Staking Rewards
Although platforms need to mint new tokens to cover operator costs, it is natural to mint only what is necessary, as new issuance burdens token holders. The protocol must ensure allocated rewards incentivize operators to participate and act correctly, thus striking a balance between sufficiently rewarding operators and minimizing new issuance. We argue that incentives can usually be handled relatively easily at the microeconomic level, so the primary factor determining issuance rate should be rewarding operators for their capital cost.
For example, consider the "standard" blockchain model where each block has a single operator—the leader—who builds the block and bears most of the cost, while other operators simply "sign" the block via some consensus protocol. For normal operation, the leader must be substantially compensated to encourage block construction, while all other operators must be compensated to stay continuously "online." The latter is usually easy, as they have little discretion, so from a macroeconomic perspective, there are no significant incentive constraints.
Rewarding the block leader is often a more subtle issue because the leader has significant discretion, so we need moderate incentives. However, this is directly handled by the transaction fee mechanism, which precisely incentivizes correct transaction inclusion by aligning with marginal cost pricing. Beyond these marginal-cost-aligned incentives, we only need to compensate the leader’s fixed cost, and a sufficiently large fixed "block reward" achieves this.
The primary factor determining issuance rate should be rewarding operators for their capital cost.
In our analysis, we assume the reward rate operators receive from the platform is determined by stakers themselves, based on their own financial calculations. Stakers’ financial considerations may relate to the financial environment, perceived risks and potential of the platform and token, and alternative uses of the token.
Although various financial models could estimate how required reward rates depend on other parameters (e.g., external interest rates or historical volatility of token exchange rates²¹), we do not need such estimates and will treat the required reward rate as given.
Empirical data from different large platforms listed in Table 1 show annual staking returns ranging from 2% to 20%, with typical rates between 3% and 7.5%, and a median around 5%. This significant variability likely depends on a range of factors, and there is undoubtedly considerable "noise" regarding the exact meaning of these numbers.
Nevertheless, we can form a fairly consistent picture of reasonable reward rates, placing them at levels comparable to typical bond or stock yields.
3.4 New Minting
The platform must provide sufficient staking rewards to its operators; otherwise, operators will refuse to participate. As noted, "sufficient" is determined by stakers themselves and is primarily a financial issue. How should the platform be designed to meet this? This is what we now address. Our basic analysis links staking cost to fixed cost and assumes staking rewards will come from newly minted tokens, distributed proportionally among stakers. We focus only on the overall quantities of minting and rewards, assuming precise distribution can be properly handled by transaction fee mechanisms.
For simple analysis, let us focus on the following parameters: (1) annual minting rate as a percentage of total existing token supply, (2) annual staking reward rate as a percentage of staked amount, and (3) staking ratio—the proportion of staked tokens to all circulating tokens. The overall equality governing this relationship is:
(Annual new minting rate) = (Annual staking reward rate) × (Staking ratio)
We have discussed staking reward rates; now let us examine minting rate more closely. This rate is determined by the protocol, which should specify when new tokens are minted (or conversely, burned). Under our assumptions, new minting is used to pay staking rewards and equals the net total of all annual rewards distributed by the protocol. Specifically, in a block-based protocol, if the protocol specifies a total reward of R tokens per block (on average, net of all operator combinations’ burns), with total existing tokens S and N blocks per year, the annualized minting rate is RN/S (the minting rate being the speed at which the system creates new tokens to incentivize participation and keep the system active).
It can be noted that under this equation, staking rewards are "nominal"—that is, not adjusted for token value inflation. This may be an appropriate way for stakers who truly believe new minting does not dilute their token value, as the platform may grow faster than the minting rate. For stakers less confident in this view, they may care about the "real reward rate" or "adjusted reward rate," which balances by subtracting the minting rate from the reward rate, yielding the following equation: (Adjusted reward rate) = (Minting rate) / (Staking ratio) - (Minting rate).
3.5 Staking Ratio and Security
By definition, the security of a proof-of-stake platform relies on holding tokens as a defense against Sybil attacks. In other words, the system’s implied consensus is formed by operators collectively holding enough tokens. Let us examine why we trust this type of consensus. The first reason is straightforward: we don’t believe any malicious party has enough resources to control the majority of staked tokens, and non-malicious stakers will faithfully follow the protocol. The second reason is that any group collectively holding a majority of tokens would suffer massive losses if the platform ceases to function properly, as token value would likely plummet. The first argument is the typical "honest majority" argument in computer science, while the second is an economic game-theoretic "incentive" argument.
Quantifying these two security arguments is quite imprecise, as each depends on many factors. For the first, we must estimate what fraction of total staked tokens a malicious actor must overcome. For the second, we should estimate the economic gain a malicious coalition with majority stake could obtain versus the economic loss from token devaluation due to manipulation. While precise quantification is difficult, in both cases, the potential gain from maliciously controlling a majority of staked tokens appears to be on the order of a constant fraction of the total token value.
Therefore, to achieve reasonable security against malicious actors, a certain constant fraction of total tokens must be staked. The exact constant for different security levels will vary across platforms depending on possible manipulations, token value and liquidity, locked portion, and nature of that lock. Nevertheless, for any specific platform, we can view the proportion of staked tokens as a proxy for the security obtained. Empirically, looking at Table 1, major platforms have staking ratios between 20% and 70%, with the lowest ratios typically at the largest platforms.
In a proof-of-stake platform, the proportion of staked tokens should be at least some platform-specific constant, with security increasing as this proportion rises.
Given a required security level and an estimate of the reward required by current stakers, the required minting rate can be calculated²⁶. Let us take the median values from Table 1 as an example: suppose stakers require a 5% annual return and we aim for a 50% staking ratio. Then, according to the equation, the required annual minting rate is 2.5% (50%×5%). This calculation is static, assuming the required staking reward and desired staking ratio are fixed.
Let us see how such a calculation might work within a protocol. Generally, the minting protocol can decide the "block reward," thus setting the minting rate. Once the minting rate is set, stakers decide whether to stake their tokens, and the newly minted tokens are essentially distributed among stakers, providing their staking rewards. We can reasonably assume that the higher the staking reward rate, the more stakers will choose to stake.
Thus, the staking ratio will self-adjust until the above equation is satisfied: if the staking ratio is below the required level, each staker receives a higher reward than "needed," so more stakers will join. If the staking ratio is too high, rewards are too low, and stakers will leave. Equilibrium is reached only when the staking reward matches the "market" demand.
Moreover, if the financial environment changes while the protocol remains unchanged, the staking ratio will self-adjust. For example, if external interest rates rise or alternative financial uses of the token within the platform become more attractive, stakers may demand higher rewards, leading to a lower staking ratio. Conversely, if confidence in the platform’s future increases, stakers will demand fewer rewards, so the staking ratio will rise.
Of course, the platform need not choose a fixed minting rate "once and for all." Instead, since the platform can observe the current staking ratio, it can use this information to determine the minting rate. Such a dynamic minting rate mechanism may allow finer control over the equilibrium of staking and minting rates, depending on the observed function of required staking rewards derived from staker behavior.
For example, Ethereum defines a curve where minting rate increases proportionally to the square root of staking ratio, thus making reward rate decrease proportionally to the square root of staking ratio. Another option is a dynamic protocol that increases minting rate when staking ratio falls below the desired level (and decreases it when staking ratio exceeds what is deemed necessary). In both cases, equilibrium is reached only when the reward rate equals the level required by stakers.
3.6 Bottom Line: Macro Tokenomics
Thus, the key takeaway from this section is that proof-of-stake platforms with utility tokens should pay any fixed costs of platform operation by minting new tokens. The main component of fixed costs may be the capital cost of staking, which depends on the financial environment. Since platform security depends on the staking ratio, the protocol should mint enough new tokens to achieve the desired level of security.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@StarkWareLtd
