NEAR VISION #6: NEAR Ecosystem Economics

How does economics in NEAR ecosystem work? What is its Economy Design Principles? Who are the Economic Stakeholders? And more… All of the questions will be answered in this number of #NearVision

15 min readAug 11, 2021

Opening

The ecosystem which makes up the NEAR platform is driven primarily by economic forces. This economy creates the incentives which allow participants to permissionlessly organize to drive the platform’s key functions while creating strong disincentives for undesirable, irresponsible or malicious behavior. In order for the platform to be effective, these incentives need to exist both in the short term and the long term.

Fundamentally, the NEAR platform is a marketplace between willing participants. On the supply side, operators of the validator nodes and other fundamental infrastructure need to be incentivized to provide these services which make up the “community cloud.” On the demand side, the developers and end-users of the platform who are paying for its use need to be able to do so in a way which is simple, clear and consistent so it helps them.

Further, economic forces can also be applied to support the ecosystem as a whole. They can be used at a micro level to create new business models by directly compensating the developers who create its most useful applications. They can also be used at a macro level by coordinating the efforts of a broader set of ecosystem participants who participate in everything from education to governance.

The specific application of each of these forces is described in the sections below. We will begin by benchmarking how each of the key design principles of NEAR apply to its economics and survey the landscape of existing approaches.

NEAR Economy Design Principles

NEAR’s overall system design principles are used to inform its economic design according to the following interpretations:

Usability: End users and developers should have predictable and consistent pricing for their usage of the network. Users should never lose data forever.
Scalability: The platform should scale at economically justified thresholds.
Simplicity: The design of each of the system’s components should be as simple as possible in order to achieve their primary purpose.
Sustainable Decentralization: The barrier for participation in the platform as a validating node should be set as low as possible in order to bring a wide range of participants. Over time, their participation should not drive wealth and control into the hands of a small number. Individual transactions made far in the future must be at least as secure as those made today in order to safeguard the value they modify.

Overview

The NEAR economy is optimized to provide developers and end users with the easiest possible experience while still providing proper incentives for network security and ecosystem development.

Here is a summary of the key ideas that drive the system:

Thresholded Proof of Stake: Validating node operators provide scarce and valuable compute resources to the network. In order to ensure that the computations they run are correct, they are required to “stake” NEAR tokens which guarantee their results. If these results are found to be inaccurate, the staker loses their tokens. This is a fundamental mechanism for securing the network. The threshold for participating in the system is set algorithmically at the lowest level possible to allow for the broadest possible participation of validating nodes in a given “epoch” period (½ of a day).
Epoch Rewards: Node operators are paid for their service a fixed percentage of total supply as a “security” fee of roughly 4.5% annualized. This rate targets sufficient participation levels among stakers in order to secure the network while balancing with other usage of NEAR token in the ecosystem.
Protocol treasury: In addition to validators, the protocol treasury receives 0.5% of total supply annually to continuously re-invest into ecosystem development.
Transaction Costs: Usage of the network consumes two separate kinds of resources — instantaneous and long term. Instantaneous costs are generated by every transaction because each transaction requires the usage of both the network itself and some of its computation resources. These are priced together as a mostly-predictable cost per transaction, which is paid in NEAR tokens.
Storage Costs: Storage is a long term cost because storing data represents an ongoing burden to the nodes of the network. Storage costs are covered by maintaining minimum balance of NEAR tokens on the account or contract. This provides an indirect mechanism of payment via inflation to validators for maintaining contract and account state on their nodes.
Inflation: Inflation is the combination of payouts to validators and the protocol treasury minus the collected transaction fees (and a few other NEAR burning mechanics like the name auction. Overall, the maximum inflation is 5%, which can go down over time as network gets more usage and more transactions fees are burned. It’s possible that inflation becomes negative (total supply decreases) if there are enough fees burned.
Scaling Thresholds: In a network which scales its capacity relative to the amount of usage it receives, the thresholds which drive the network to bring on additional capacity are economic in nature.
Security Thresholds: Some thresholds which provide for good behavior among participants are set using economic incentives. For example, “Fishermen” (described separately).

The justifications for each of these principles is described in more detail in the following sections.

Resources Provided

A blockchain-based cloud provides several specific resources to the applications which run atop it:

Compute (CPU): This is the actual computer processing (and immediately available RAM) which run the code in a contract.
Bandwidth (“Network”): This is the network traffic between participants and users, including messages which submit transactions and those which propagate blocks.
Storage: Permanent data storage on the chain, typically expressed as a function of storage space (eg kilobytes).

Existing blockchains like Ethereum account for all of these in a single up front transaction fee which represents a separate accounting for each of them but ultimately charges developers or users for them only once in a single fee. This is a high volatility fee commonly denominated in “gas”.

Developers prefer predictable pricing so they can budget and provide prices for their end users. The pricing for the above-mentioned resources on NEAR is an amount which is slowly adjusted based on system usage (and subject to the smoothing effect of resharding when usage grew sustainably) rather than being fully auction-based. This means that a developer can more predictably know that the cost of running transactions or maintaining their storage.

Initially, all of these resources will be priced and paid in terms of NEAR tokens. In the future, they may also be priced in terms of a stable currency denomination (for example a token pegged to the $USD).

COMPUTE AND BANDWIDTH (“GAS”)

Compute (CPU) is a momentary resource spent on executing a transaction. The cost of each CPU instruction is denominated in “gas” units and its price is determined based on the slowly adjusted price of gas (denominated in NEAR tokens). Bandwidth is usually measured in bytes, but in the NEAR platform it is converted into gas units by using a simple coefficient of overhead which has been estimated on reference hardware.

Each chunk (piece of a block) is given a specific maximum gas limit which is determined based on how much a single block can “fit” when executed on reference hardware. The block limit can also be adjusted by network participants in order to account for performance improvements or the participants deciding to run better hardware. This is done via the normal system governance processes.

The current gas price is predictable but not fixed. Each block, it is adjusted in the following way:

If the prior block is more than half full, the gas price from the previous block is increased by an amount given by the parameter called `alpha`.
If the prior block is less than half full, the gas price from the previous block is decreased by an amount also given by the parameter called `alpha`.

Gas usage can trigger Resharding, as explained below.

STORAGE

Storage is a long-term scarce asset. For an application or users to use it, they must maintain a minimum balance on their account that scales linearly with amount of storage such account takes. The required amount of NEAR tokens per byte is fixed and is subject to change only by major governance decision (and, given trends in storage hardware and system capacity, it will likely be adjusted down going forward).

For example, if some contract takes 10 kilobytes of storage due to data stored under it, this contract must maintain minimum balance of 1 NEAR. A contract like USDT from Ethereum would need to maintain ~10k NEAR balance to cover for storage it is using. This also means that regular user’s accounts need to maintain fraction of NEAR minimum balance.

Using a minimum balance of NEAR on the account leads to this amount not being staked or used in other applications. Validators are getting paid indirectly for maintaining this storage from inflation and the fact that total stake is smaller.

The NEAR system will keep shard size mostly balanced, allowing for each node to maintain roughly the same amount of state (which will be roughly the total state size divided by the number of shards). As individual shard state size changes, the assignment of accounts and contracts to shards can shift to maintain this balance.

Resharding

Accounts and contracts are each assigned to a shard. Because the usage of such contracts is not equal, the usage or size of some shards might greatly outpace the usage or size of other shards. To prevent this, NEAR uses resharding, which rebalances shards periodically based on specific conditions. The end result will be a set of shards that are expected to have a reasonable and balanced amount of transactions and storage usage.

During each epoch (½ day), statistics are accumulated regarding how full blocks are during that epoch and other relevant conditions. Each contract is examined based on its usage during the previous epoch and its current storage. Contracts are then “bucketed” into groups such that each bucket has roughly the same expected aggregate characteristics.

The system knows approximate limits on transaction usage per shard (the “gas limit”) as well as expected per-node storage. If the amount of resources used in the previous epoch exceeded a particular threshold (eg if a large number of blocks are more than half full), a number of new shards will be allocated, increasing the number of buckets and averaging down each of their expected usages.

Adding new shards also means there will be more seats available for validation, which in turn brings more unique validators to the table as the per-seat price (in NEAR tokens) goes down. This computation is performed one epoch in advance of actually using these new shards so validators have the time they need to re-sync the necessary state and other shard information.

Inflation

The overall inflation (minting of new tokens) of the system is determined by how large the epoch reward is for running a validating node. The rate of minting of new tokens is capped at 5% per annum. The effective rate is computed per epoch (½ a day). It is calculated from the expected inflation rate per epoch minus the fees collected during the epoch. Each portion of fees captured by the platform is removed from inflation, thus reducing the overall inflation of the system as its usage increases. Should the system’s usage fees reliably exceed the tokens generated by the inflation, it will become deflationary overall.

Because the system is sharded and has hidden validators whose assignment is unknown to the system, it must socialize all rewards. This means that the “security” fee is evenly allocated to all validators independent of how much transactions or storage their shards processed.

Economic Stakeholders

Validators: Provide the computational resource and security for the network by running nodes.
Developers: Create the applications which run atop the network
Token Holders: Accounts or applications which maintain token balances
NEAR Foundation: An independent entity which coordinates the governance and technical evolution efforts of the network participants.
Third Party Observers: The observers of the chain who provide extra fraud and bad behavior protection.
Users: Users of applications on the network who do not maintain token balances.

The impact of economic policies on each of these stakeholders is examined below.

VALIDATOR REWARDS

As a “Proof of Stake” system, the NEAR platform is secure because the validators who run nodes put some of their tokens at stake as a kind of deposit to guarantee good behavior and for validator selection (prevent Sybil attack). Should these validators produce an invalid block or create an alternative chain (eg. with the goal of creating a double spend), they will be “slashed”, cutting this deposit.

Validators are chosen based on the “Thresholded Proof of Stake” model which uses an auction to determine how many “seats” will be allocated to each prospective validator (by determining the minimum threshold number of tokens for a single seat). This auction is designed to provide fair (equal opportunity) allocation and allow as many people as possible to participate in the network’s validation process so it can achieve meaningful decentralization.

A validator can deterministically expect to participate in the validation process in a proportion which matches their proportion of total stake in the network. A given validator may become one of several possible roles:

Block Producer
Chunk Producer
Hidden Validator

Independent of the role the validator is assigned, its reward will be proportional to the percentage of total amount staked by the validator. This means there is no need to pool stake under a minimum required to become a validator.

In exchange for servicing the network by producing blocks and chunks and providing security and data availability, validators are rewarded with target number of NEAR every epoch. The target value is computed in such a way that, on an annualized basis, it will be 4.5% of total supply.

Because validators are selected on a per-epoch basis and they each need to do an equal amount of work to validate chunks, provide data availability and produce blocks, the reward gets allocated every epoch and gets divided proportionally to the stake of each participant.

All transaction fees (minus the part which is allocated as the rebate for contracts) which are collected within each epoch are burned by the system. The inflationary reward is paid out to validators at the same rate regardless of the amount of fees collected or burned. Taken together, this means that system-wide inflation is reduced by an amount proportional to the amount of fees which are paid to the system and, should network usage fees exceed the system-wide inflation rate, the system will become deflationary.

The computational requirements for running a validating node are designed to be minimal. Most operators should be able to do so easily with a standard cloud-hosted virtual machine, for example with Amazon AWS’s $100/month instance or a n1-highcpu-4 Google Cloud instance (and likely with even less robust hardware). For validators who anticipate staking substantial balances and thus who expect to participate in many shards simultaneously, they might want to utilize more hardware (and redundancy) to compensate for the extra storage, bandwidth and compute load they will need.

THIRD PARTY OBSERVERS (“HIDDEN VALIDATORS” AND “FISHERMAN”)

A key disadvantage of an unsophisticated sharded blockchain system is that the overall system security is split because only a portion of the network’s validators are validating the transactions of a particular shard. NEAR employs two ways to counteract this problem: “Hidden Validators” and “Fishermen”.

“Hidden Validators” are validators who are selected from the general validator pool and are assigned to validate shards that are unknown to any parties except themselves. This process, which is described in greater detail in other sections, ensures that it is extremely difficult to successfully corrupt a sufficient number of nodes to perfrom malicious behaviors in a shard.

Hidden Validators are compensated for validating and signing off on the validity of chunks and blocks as a normal part of the validator compensation process.

“Fishermen” are observing nodes who permissionlessly detect and report bad behavior. These nodes are synced with the network but are not necessarily participating in the consensus and don’t actually get paid for any specific ongoing activity. They can include wallet operators, application developers or exchange infrastructure. These nodes validate parts of the chain that are important to them and, if they detect issues, they can flag those issues via challenge. To prevent “griefing” of challenges, a small bond of 10 NEAR must be posted ahead of time.

The system does not provide any reward for operating a node as a Fisherman (there is no reward for sending a successful challenge). Instead, participants who run a Fisherman node generally have outside motivations for maintaining the security of the network.

CONTRACT REWARDS

A portion of the fees generated by a particular transaction are provided back to the contracts that were run during that transaction. This “Contract Reward” may be distributed in accordance with the rules specified in the contract, for example it may be allocated to an account controlled by the contract developer, by investors, by a DAO, etc.

The percentage of fees which are allocated to this reward is set to a minimum value as system-level parameter, initially 30%. Developers always can charge extra outside of this mechanism by requiring user to attach funds to the call.

This creates a business model for developers who might otherwise not have a meaningful way of charging for their applications. Having a minimum fee which is set at the system level avoids a “race to the bottom” which results in zero rewards due to competition (or simply the “forking out” of the fee by another developer).

This has a powerful effect of incentivizing developers to build applications and core contracts for the network because they will be directly compensated proportional to the usage of these contracts.

TOKEN HOLDERS

Token holders may choose not to participate in the staking process, for example because they are only temporary holders, they are providing liquidity for trading markets or they simply prefer not to participate. Token holders who do not participate in the staking and validation process receive no additional benefits from the operation of the network itself, though their tokens have utility by powering storage of the data and their usage of applications running on the network.

PROTOCOL TREASURY

To enable continues community growth and evolution of protocol, part of the inflation (10% of the inflation, or a total of 0.5% annually per initial parameters) is allocated to Protocol Treasury. In the future, these are expected to be managed by the community with the goal of coordinating long-term development of NEAR ecosystem, particularly efforts that won’t sustain themself like future protocol development.

Given the current state of decentralized governance, initially treasury will be overseen by the NEAR Foundation. The NEAR Foundation’s mandate is to enable community-driven innovation to benefit people around the world. While the foundation is nonessential to the operation of the network, which is fully decentralized, it is already able to support the project’s ongoing evolution in ways that other entities would find difficult. For example, it is funding education, events or infrastructure projects which benefit the commons but do not have a particular business model and which would otherwise not be funded.

The amount of inflation that is allocated to the Protocol Treasury also acts as a decentralizing economic force since it allows for the redistribution of capital back into the ecosystem to developers and other participants who support the commons who might not otherwise have stake to offer.

Special Conditions

SLASHING CONDITIONS AND PROGRESSIVE SLASHING

There are two major types of malicious behaviour possible on the NEAR platform:

Double Signing: Signing two or more different blocks at the same height.
Invalid Chunks: Signing a chunk with an invalid data or computational result.

Malicious validators might double sign because they are trying to execute a chain reorganization which reverts certain transactions (which might allow them to conduct a “double spend” as a result).

Non-malicious double signing in a Proof of Stake system can also happen due to a misconfiguration or issue in the software.

To balance the risk of accidental slashing, NEAR uses “Progressive slashing”. This is where the portion of stake that is slashed is a multiple of the amount of stake that exhibited the double signing behavior during the epoch in question. This multiple is 3, so each malicious participant gets slashed by 3 * malicious_stake / total_stake.

For an example of a double sign which leads to slashing, assume a validator has 1% of the total tokens which have been staked in a particular epoch. Assuming the total amount of tokens staked in the epoch is 50,000,000 NEAR, this validator has 500,000 NEAR at stake. If that validator double signs and there are no other double signs, the validator will lose 3% of their stake in that epoch, so they will have 485,000 of NEAR returned to them and 15,000 NEAR will be burned. If the total amount of stake that double signed within an epoch reaches 33% (which becomes dangerous for the network), the entire stake of all involved parties will be slashed.

For an invalid chunk, the full stake of the validator gets slashed. This is because an invalid chunk is only possible if the node is actually malicious (they have modified the code).