Intro to NEAR Protocol’s Economics

NEAR is a developer platform for the Open Web. This means that NEAR has a set of protocols and tools that enable people to build a new wave of community-owned applications.

The main protocol, NEAR Protocol, is a blockchain to power the security, economy, and incentives of NEAR’s developer platform.

Open Web is a paradigm shift of how applications and businesses are built. In the current paradigm, a company with investors and shareholders started by founders provides some service to its users. Over time, though, the divide between what users want and what generates more revenue usually grows. At the same time, companies try to reduce external dependencies to defend against the chances that one of its suppliers fails or gets acquired by competition.

The principles of Open Web are as follows:

  • Governed by community
  • Hackable and composable
  • Open and permissionless
  • User-first and sovereign
  • Open markets

To ensure these principles are followed, a combination of efforts is required:

  • A trustless and permissionless base layer that can be leveraged by all parties for various contracts, marketplaces, rooting sovereign data storage and more.
  • An independent currency that can be operated in a permissionless way and that can have a monetary policy to incentivize the behaviors of the parties.
  • The ability of new teams to create their own community-driven economies around their applications.
  • Backend for high-risk and low-trust serverless decentralized applications.

NEAR Protocol sits at the bottom of the stack, providing a permission-less base layer, independent currency and predetermined monetary policy and marketplace of computing resources.

This article explores the economic principles governing NEAR Protocol, and how they keep aligned the interests of its community.

Native cryptocurrency Ⓝ

$NEAR (Ⓝ) is the native cryptocurrency used in NEAR Protocol and, as the lifeblood of the network, has several different use cases. As the native currency, it secures the network, provides a unit of account and medium of exchange for native resources and third-party applications, and, over the long term, aims to become a store of value used by individuals as well as by contracts and decentralized finance (DeFi) applications.

Security of the Network

NEAR Protocol is a proof-of-stake network which means that Sybil resistance from various attacks is done by staking Ⓝ. Staked Ⓝ represent a “medallion” for service providers that supply a decentralized infrastructure of servers that are maintaining state and processing transactions to NEAR users and applications. In exchange for this service, node providers receive rewards in Ⓝ.

Network Usage Fees

The utility of the network is provided by storing application data and providing a way to change it by issuing transactions. The network charges transaction fees for processing the changes to this stored data. The NEAR network collects and automatically burns these fees, such that higher usage of the network will both increase the incentives to run validating nodes (as they receive higher real yield) and increase the “Store of Value” properties of Ⓝ.

On the other hand, Ⓝ is also used as collateral for storing data on the blockchain. Having 1 Ⓝ on an account allows the user to store some amount of data (the specific amount depends on the available storage but will increase over time). This also increases the “Store of Value” properties of Ⓝ.

Medium of Exchange

Because Ⓝ is readily available on the protocol level, it can be easily used to transfer value across NEAR applications and accounts. This monetary function enables the creation of applications that use Ⓝ to charge for various functions, access to data, or performing other complex transactions. Ⓝ is exchanged within the network in a peer-to-peer fashion, across various applications and accounts, without the need for trusted third parties to clear and settle transactions.

Unit of Account

As mentioned in the “Network Usage Fees” section, Ⓝ is used to price the computation and storage of the NEAR infrastructure, which is offered by node operators. At the same time, applications and external parties can use Ⓝ as a unit of account for their application services or to measure the amount of the exchange in cases of Ⓝ as medium of exchange.

Store of Value

Ⓝ originates as security and network usage currency, connecting the need for storing and security of data with Validators (service providers). It represents the nominal cost of these services in local currency at the current exchange rate. However, as more Ⓝ are either staked or locked for applications’ state or in various financial instruments, i.e., the higher the demand for more limited supply, Ⓝ decouples from its direct network utility.

In the long-term, Ⓝ becomes a representation of the value of the data stored on the network, and their *salability* across other applications and use cases (technically defined as composability, which is a driver for Network Effects). 

Compounding this further, transaction fees burn Ⓝ instead of transferring them to network operators. Therefore, as usage grows, the amount of Ⓝ burned can exceed the fixed security fee paid out to Validators. See the “Issuance” section for details.

Genesis and inflation

At the launch, the NEAR network will have 1 billion Ⓝ. Each Ⓝ is divisible into 1024yocto Ⓝ.

Ⓝ Issuance and inflation

NEAR Protocol’s issuance of tokens, or inflation, is necessary to pay network operators, also called Validators. There is fixed issuance around 5% of the total supply each year, 90% of which goes to Validators in exchange for computing, storage, and securing the transactions happening on the network. 

As mentioned above, all transaction fees collected by the network get burned. Therefore, the issuance of Ⓝ is actually ~5% minus transaction fees. This means that, as the network grows in usage, issuance can become negative, introducing negative inflation in the protocol. Since the smallest unit of account for Ⓝ is yocto Ⓝ, the system can keep its exchange price resolution as small as infinitesimal fractions of the U.S. dollar, even with a reduction of the overall supply by two or three orders of magnitude.

avg # of tx/day Min in fees/day mint/day Annual inflation
1,000 0.1 136,986 5.000%
10,000 1 136,985 5.000%
100,000 10 136,976 5.000%
1,000,000 100 136,886 4.996%
10,000,000 1,000 135,986 4.964%
100,000,000 10,000 126,986 4.635%
1,000,000,000 100,000 36,986 1.350%
1,500,000,000 150,000 -13,014 -0.475%
2,000,000,000 200,000 -63,014 -2.300%

Expected inflation per day given different number of tx

This table includes a few assumptions. But the main point is to show how inflation gets affected by usage.

Note that even though 1 billion transactions per day is a pretty large number for existing blockchains, that’s about ~11k tx per second of sustained load (also these tx are benchmarked as payment tx; more complex smart contract calls will require more gas and cost more).

Bitcoin pioneered cryptocurrencies and the idea of fixed supply. At the same time, constant reduction in security rewards available to miners creates interesting issues long term with the longest chain consensus (for more details read this paper). In NEAR Protocol, we addressed this issue by guaranteeing a constant security reward rate to Validators. And instead of issuance declining independent of the usage, NEAR’s issuance declines with more usage of the network.

Also note that in comparison to Bitcoin and Ethereum, token holders can avoid inflation by delegating/validating with their stake, preserving their percentage or even increasing it (see details in the “Validators” section).

Network Usage

Transaction fees

Each transaction takes some amount of bandwidth to be included in the block and computation to be executed. We combine both of these resources into a unified measure called “gas” that Validators must spend to execute a transaction. NEAR uses WebAssembly Virtual Machine (VM) to execute transactions and provides a mapping from each VM operation to the amount of gas it spends. The goal for gas is to represent a unified measure of resources spent to receive, execute, and propagate a transaction on default hardware.

Users who want to send such a transaction must pay a transaction fee, which is computed based on the amount of gas that the transaction will require multiplied by the current gas price.

Gas price is defined systemwide and changes from block to block in a predictable manner. Specifically, if the previous block used more than ½ of the gas limit for that block, the gas price is increased by a small margin. Otherwise, the gas price will decrease. There is also a minimum gas price which provides a floor for the price.

Minimum gas price is selected to provide a cheap transaction price for users and developers, with the expectation of collecting ~0.1 Ⓝ per full chunk (part of the block from a shard, see Nightshade for more detail). This is designed to make blockchain usage more accessible. Instead of the economy of the scarcity of transaction processing (how it works in Bitcoin and Ethereum), the goal of this system is to hit the economy of scale by increasing the number of shards.

Validators when including transactions do not use fees for ordering, instead, there is a deterministic ordering based on transaction hash. As explained in the “Issuance” section, fees that are collected from transactions are burned instead of being redistributed within the network of Validators. 

This is done for a few reasons:

  • In the Proof-of-Stake network, every validator does the same amount of work by executing and validating transactions; the block producer is not all that special to be rewarded. In the case of a sharded network, it’s even more complicated to distribute these fees, as there are also receipts between shards where gas is bought when a transaction arrives but executed by different Validators.
  • Validators are still incentivized from burning transaction fees as that directly increases their yield. For simple example, let’s say total supply is 100, 50 of which is staked. Let’s 5 tokens are paid in epoch reward, then if there are no fees – yield is (55/105)/(50/100)-1~=4.76%. While if there were 5 tokens of fees burned, yield would be (55/100)/(50/100)-1~=10%.
  • This also incentivizes locking of tokens in other applications by offsetting the issuance, driving Ⓝ as a store of value for applications.


Storing data on the blockchain has a long-playing role. Networks like Bitcoin and Ethereum misprice storage by only allocating reward to miners who mined specific transactions instead of future miners who will need to continue storing this data while they are mining.

In NEAR, Ⓝ also represents the right to store some amount of data. Token holders have the right to occupy some amount of the blockchain’s overall space.

For example, if Alice has a balance of 1 Ⓝ, she can store roughly 10 kilobytes on her account. This means that users need to maintain a fraction of Ⓝ as a minimum balance if they want to have their account, similar to how checking accounts in banks require a minimum balance. 

This allows contracts which are maintaining important state to pay to Validators proportionally to the amount of data they are securing. For example, an important contract of the stable coin that would maintain the balances of millions of users will accordingly need to have a reserve of Ⓝ to cover the amount of storage it will require on the blockchain.

Storage locked for Storage % of Total Supply
10 MB 1,049 0.0001%
100 MB 10,486 0.0010%
1 GB 107,374 0.0107%
10 GB 1,073,742 0.107%
100 GB 10,737,418 1.07%
1 TB 109,951,163 11.00%

Amount of Ⓝ locked at different amounts of total storage. 

For reference, Ethereum is at ~100 GB of storage right now, the USDT contract takes  ~100 MB. Contrast that with the total amount locked in Ethereum’s DeFi is ~2.5% of ETH.

There are many ways a developer who doesn’t have a large amount of Ⓝ can still occupy space. For example, a developer can borrow Ⓝ from either off-chain entities or via on-chain lending protocol. Paying back with revenue that his application generates.

Additionally, this can also provide a good opportunity for developers to issue their own token, where they allocate a portion to the Ⓝ token holders who are interested in supporting this application. They attract more support and get Ⓝ required to launch their application and maintain its state, while their token captures revenue from the application usage.



Validators as a group are paid fixed 90% of around 5% of total supply annualized (other 10% go to Protocol Treasury). For example, in the first year Validators will receive around 45,000,000 Ⓝ. Rewards are distributed per epoch — every half a day. Which is on average ~61,640 Ⓝ of reward per epoch to be allocated between Validators.

Each validator receives a reward proportional to their participation. As a validator stakes, how many seats they take is determined via simple auction. After each epoch finishes, the validator will be evaluated based on how many blocks and chunks they produced versus what they were expected to produce.

In the event it’s below 90% of what’s expected, the validator is considered to be offline/unstable, won’t get any rewards, and will be removed from the coming epoch’s validation (i.e., force unstaked). Validators with at least 90% online presence will receive rewards that grow linearly, with 100% of the reward given for those with a 99% or above online presence. Read details of uptime and reward computation here.

For example, if there are 100 seats, a validator that has one seat – will get ~615 Ⓝ per epoch if they are above 99% of uptime. If the validator was 95% uptime, they will receive 55% of their reward – ~342 Ⓝ.

% staked / amount staked
10% 25% 50% 70% 90% 100%
number of tx / day 100,000,000 250,000,000 500,000,000 700,000,000 900,000,000 1,000,000,000
1,000 38.10% 12.38% 3.81% 1.36% 0.00% -0.48%
10,000 38.10% 12.38% 3.81% 1.36% 0.00% -0.48%
100,000 38.10% 12.38% 3.81% 1.36% 0.00% -0.48%
1,000,000 38.10% 12.38% 3.81% 1.36% 0.00% -0.47%
10,000,000 38.14% 12.42% 3.85% 1.40% 0.03% -0.44%
100,000,000 38.58% 12.77% 4.17% 1.71% 0.35% -0.13%
1,000,000,000 43.07% 16.43% 7.55% 5.01% 3.60% 3.11%
1,500,000,000 45.69% 18.56% 9.52% 6.94% 5.50% 5.00%
2,000,000,000 48.41% 20.78% 11.57% 8.93% 7.47% 6.96%

Annualized yield at different amounts staked and number of transactions per day.


NEAR is a sharded blockchain designed to scale throughput as usage grows. In the beginning, the system starts with one shard and 100 validator seats. Based on the stake offered, the protocol proportionally assigns these seats, and redistributes the rewards. Therefore, if the protocol will have 40% of the total supply at stake, each seat will require 4 million Ⓝ stake.

However, the number of seats will increase linearly with the number of shards: when 8 shards are running, 800 seats will be available. And every seat will require 500,000 Ⓝ stake, lowering the barriers of entry for more Validators.

A simple auction takes place to actually determine the seat price. Let’s say you observe the following set of proposals (and rollovers from Validators of previous epoch):

Validator Stake # Seats
V1 1,000,000 48
V2 500,000 24
V3 300,000 14
V4 300,000 14
V5 20,000 0

Example proposals by Validators and number of seats they would get at the selection process

The seat price given this proposal is determined by finding an integer number that if you divide each validator’s stake with rounding down (e.g., for V5, 20,000 / 20,500 rounding down will be 0), you will get a required number of seats. This determines who will get their seat(s) and who’s funds will be returned back. In the case of the table above, the seat price will be 20,500 if there are 100 seats, and that gives the last column’s number of seats to each validator.

The protocol automatically measures the availability of Validators: if a node fails to be online above a certain percentage when it should be creating new blocks, it loses the status of validator and will be required to submit a staking transaction again. The penalty for low-quality nodes is missing epoch rewards.

In the beginning, a small number of shards will require a larger stake, preferring professional Validators and organizations that will allocate significant resources to NEAR Protocol.

As the network and its usage grow, the number of seats will increase with the number of shards. Therefore, the minimum stake necessary to become a validator will be lower and the seat price selection mechanics will allow for a long tail of Validators to come on board. 

This long tail of non-professional Validators might individually have higher risk of failure. But together, they will provide greater decentralization and fault tolerance. At the same time, Validators with a larger stake will need to commit more computational resources when they have to validate multiple seats across different shards.


Validators can receive Ⓝ to stake from third parties via Delegation. NEAR Protocol enables delegation via smart contracts. Validators that want to accept delegation can create a special contract and allow users who don’t want to run their own nodes to deposit their Ⓝ into it. By doing so, funds deposited to that contract are available to the creator of the contract to use as part of their stake.

In the beginning, there will be a reference delegation smart contract. In the future, we can expect Validators to come up with their own staking contracts that provide various taxation benefits, liquidity, and yet-to-see features. The goal is to allow professional Validators who might not have funds to participate, increase the total stake and thus the security of the protocol, and improve the redistribution of rewards across the ecosystem. 

Protocol Treasury

We believe in sustainable development. We allocate 10% of epoch rewards to the treasury. This treasury account is designed to continue sponsoring protocol and ecosystem development. Over the long term, it should be managed by a decentralized governance process.

Before that is fully established, we allocate the custody of this to the NEAR Foundation. As decentralized governance progresses and clearly shows that it can effectively manage execution, we strongly suggest for the network to hard fork and change the custody of the treasury to a new entity.

Contract rewards

As one of the steps to create a sustainable path for contract independent operation and possibly developer income, NEAR Protocol allocates 30% of transaction fees to the contracts these transactions touched.

For example, if Alice sent a transaction to smart contract A with 0.0001 Ⓝ fee, and contract A doesn’t call any other contracts, it will receive a reward of 0.00003 (which is 30% of 0.0001 Ⓝ). On the other hand, if contract A is using contract B for 50% of its functionality (measured by gas usage), A and B will split the contract reward, each one receiving 0.000015 Ⓝ. This way popular libraries can receive a flow of funds from all the client applications that are using them.

Developers of the contracts can program various ways how these funds can be used. For example, they can be kept on the contract to allow it to allocate more storage space. DAO managing this application can decide what to do with these funds. Or there might be some third-party token buy-back & burn mechanics for contracts that have their own token.

Account Name Auction

NEAR Protocol uses human-readable account names. This allows for much better user experience for regular blockchain use cases. We also expect that these accounts will be used across various novel use cases (e.g., DNS, certification, and applications) as they represent the user’s digital identity that is also connected to finances, data ownership, and cryptography—and, in the future, supporting more of Decentralized Identifier (DID) standard.

We split account names into two groups by length: those longer than 32 characters and those shorter. We expect that shorter accounts names will have way more value for users compared to longer ones. Longer account names can register on a first-come-first-serve basis.

To give everyone a fair chance to acquire short account names, a naming auction will start shortly after MainNet launch.

Each week’s account names—such that sha256(account_id) % 52 is equal to the week since the launch of the auction—will open for bidding. Auctions will run for seven days after the first bid, and anyone can bid for a given name. A bid consists of a bid and mask, allowing the bidder to hide the amount that they are bidding. After the seven days run out, participants must reveal their bid and mask within the next seven days. The winner of the auction pays the second-largest price.

Proceeds of the auctions then get burned by the naming contract, benefiting all the token holders.


NEAR Protocol provides a powerful cryptocurrency Ⓝ, which links together Validators, developers, users and token holders into one ecosystem.

Each role has different goals:

  • Users want security for their assets and data.
  • Developers want more adoption and capture a sustainable source of revenue.
  • Validators want to receive higher income for providing validation services.
  • Token holders want their tokens to hold value long term.

The goal of the economic design is to align these interests and incentivize the growth of the ecosystem. For example, as the price of Bitcoin grows, so does the security of the network. In other words, BTC becomes a better store of value as it becomes more expensive, and more people want to store their money there. On the other hand, Bitcoin is missing developers and hasn’t yet attracted active development.

With NEAR Protocol, as demand for tokens grows from new users and developers and increases usage of applications, we see the alignment of incentives between everyone. 

Validators will receive a higher income in Ⓝ because there is less staked, more tokens burned (increasing their yield), and the market price of their revenue may also increase due to higher demand.

This leads to the network becoming more secure and users (who are also token holders) receiving more security for their assets and data stored on the chain. The network also becomes more attractive as a place for developers to store data and assets because it has higher security and more users.

Add it all up, and growth of the demand from users and developers and the reduction of supply via staking, transaction fee burning, and state staking leads to NEAR token becoming a better store of value for all token holders.

Update 2: See the MainNet Genesis post for an update on network status as of August 2020.

Update: MainNet launched as planned on April 22. Learn more about how this works and what it means for each stakeholder in Announcing MainNet Genesis

Introduction to NEAR Protocol’s MainNet

Building a blockchain is hard enough. Building a complex blockchain that can scale to billions of users and provides great developer experience is extremely hard.

The core difference between building a regular product and blockchain is that you can’t launch something and iterate with your users quickly fixing issues in near-real time. This is not how protocols are designed and built. Once a protocol is live, changing it requires an enormous amount of coordination. In the case of a blockchain protocol, especially one built with Proof of Stake, the protocol will begin securing hundreds of millions or billions of dollars on day one. You can’t launch a half-completed project and quickly iterate in this case.

Our team comes from a background of building products and quickly iterating on them. From the start, we took a product approach, trying to learn as much as possible from the market. Instead of following the whitepaper we initially wrote or relying on our preconceptions of what developers need, we built an MVP with developer tooling, a test wallet, and a not-a-blockchain smart contract backend. We called it DevNet and got initial developers at hackathons and workshops to try building applications on it.

This gave us a lot of feedback about how smart contracts work in multi-sharded setups and the tools needed to make blockchain accessible to a wider group of developers. It also gave us time to realize that our original approach to sharding wouldn’t cut it. This led to rethinking the approach and, ultimately, the Nightshade sharding design paper.

As we continued to iterate on the design of the blockchain, we ran a publicly accessible TestNet that any developer could build and deploy contracts to. The currently running TestNet is actually a continuation of one we started in April 2019. Through many hard forks, the network has kept the state for over a year.

From the beginning, all of our development has been public on GitHub. It went from a single repo for NEAR’s reference client (nearcore) to almost 100 public repos across three organizations (nearprotocol, near, near-examples) spanning a set of tools and products to support needs of developers and initial users of NEAR Protocol.

Requirements for a fully operational network

There are a lot of pieces that must work together to make a fully decentralized network like NEAR operational:

  • The NEAR code must be bulletproof and successfully running on a large number of validators’ computers around the globe, which together are providing their compute resources and securing the network.
  • Developers should be building and launching products on NEAR.
  • NEAR should be integrated with various partners who provide additional value to the ecosystem.
  • Tokens should be in the hands of the involved parties, who are going to use them for staking, development and using the applications. These token holders are our initial community who will be early adopters of the applications and also the loudest voices of our support.
  • Active ambassadors around the world should be spreading our mission and message and educating people both about blockchain and what can be done on NEAR.
  • The general market should have both the knowledge and the desire to learn more about the project and get involved.

MainNet Roadmap and Timeline

We are going to be releasing NEAR’s MainNet in stages. Each stage is identified by the restrictions that it has and each stage has different goals. It’s important as we open up the network more and more to test at every stage and provide flexibility to address issues early in the process.

[Edit: There is no longer a 2-week wait after the unlock vote]

MainNet product roadmap

The following sections detail each of these stages.

MainNet POA

Expected time to launch: April 22 – 27, 2020

ZenHub link to track this release

This is NEAR Protocol running in Proof of Authority mode, with the NEAR Foundation operating the initial set of nodes. Most importantly, the state of the network will be maintained going forward.

The goal for this stage is to distribute initial tokens to contributors and get the initial set of validators onboard. At this point, only the NEAR Foundation is able to transfer tokens and will be using lock-up account contracts when allocating tokens to first users. In other words, most token transfers are restricted.

Developers who are ready to deploy their applications to MainNet can apply to the NEAR Foundation and get an account to deploy their application.

In parallel, we are still running our TestNet with various validators to test out all the corner cases of validation. As soon as both NEAR Collective and validators are satisfied with the stability of running on TestNet, we will transition into the next phase.

MainNet (Restricted)

Expected time to launch: June – August, 2020

ZenHub link to track this release

Given that transfers are disabled for most accounts and the lockup contracts doesn’t allow to stake directly (only via delegation), the initial validator set is determined by a whitelist of validators to delegate to. As soon as the initial set of validators is determined from TestNet and shows their MainNet infra running, NEAR Foundation will stop staking and pass the staking to these validators.

There are a few goals for this phase:

  • Test that MainNet is operating correctly with a decentralized set of validators and continue code and security reviews
  • Initial applications which can work without transfer restrictions can start launching
  • NEAR Foundation will be continuously distributing tokens to the value-add community.

This stage is completed when the community decides that the network is secure and decentralized enough. A contract to vote on lifting transfers will be used by the community to identify such time. Validators will be casting votes, as they have locked capital in the network and can not “double vote”. Delegators can cast their votes via staking contract as proxy, overruling validators vote proportionally to their stake.

When of total stake and at least 35% of total supply vote for a specific block number, it’s considered decided by the community and transfers will unlock in two weeks [Edit: there will no longer be a fixed delay] from that block number.

MainNet (Community Governed)

Expected time: decided by the community

At this point, the network is fully operational and doesn’t have any restrictions. Validators and delegators are now responsible for continued operation of the network and deciding to upgrade.

In parallel with the general community gaining confidence and voting to unlock transfers, NEAR Collective will continue to work on ensuring the quality and security of the network, and has released a target to finalize a number of post-flight tasks. ZenHub link to track progress is here.

Comparison between stages

Here are more specific dimensions to compare different release stages of the MainNet:


Post MainNet

One of the critical parts for any project is to continue moving forward and evolve over time. To make sure NEAR does this, we follow a development process that establishes a fixed launch timeline. We have setup three networks to provide us with a testbed:

  • devnet – nightly released network from the master branch that provides a place to stress test and do initial testing of code added that day, additionally run nightly test suit.
  • betanet – released weekly, accepts external validators and application developers who want to live on the bleeding edge.
  • testnet – released every 4 weeks and is a stable version, this is the same TestNet we have been running since April 2019, and is the best place to do acceptance testing for one’s applications.

Validators on MainNet will be voting as a community on accepting new stable releases. We expect that the timing on this would usually depend on the magnitude of changes that came in that release.

We are not going to launch MainNet with all the features we have in mind. Many things end up being outside of our “MainNet v1” scope to make sure we can deliver quality products. Some of these include:

  • Upgradability without hard forking (link to discussion and epic tracking issues related)
  • Unbiasable randomness (design, implementation)
  • Safes: safe locks for operations with assets across contracts and shards (design)
  • Enable challenges to switch to selfish majority assumption (epic)
  • Parallelize Runtime (epic)
  • Rework Storage (epic)
  • Dynamic resharding (epic)
  • And more features and improvements coming from community and developers

After the “Community Governed” phase is done, we are going to set up the next release of MainNet v2 with a set of tasks to complete in subsequent 4 weeks.


How do existing token holders claim NEAR tokens on MainNet?

If you are an existing token holder, you will receive an email with detailed instructions which information must be provided to NEAR Foundation for your account to be created on MainNet with your funds.

It’s highly recommended that token holders claim their tokens before the MainNet Restricted stage to be able to participate in validation and subsequent voting to unlock transfers.

How many shards will NEAR Protocol have? How should validators handle it?

At launch, we are going to configure the network to 1 shard since it is unnecessary to have more. As network usage grows, a hard fork into 2 or more shards can happen based on a community vote. At that point, the number of shards are just a parameter in the genesis configuration. 

We have a design for Dynamic resharding that will be implemented in upcoming releases, allowing the system to change the number of shards dynamically based on load.

The important note for validators is that, as the number of shards increases, validators who have multiple seats due to large stake will start validating multiple shards in parallel (refer to the economics paper for more details regarding how validator selection works). This means they will need to run more powerful hardware or split their stake between multiple computers.

In parallel with MainNet “Restricted” launch, we are going to be running the first BetaNet and then TestNet with at least 8 shards to test performance and tooling. Validators should join these networks to establish that their setup scales properly before MainNet scales to that.

What kind of slashing does NEAR Protocol have at launch?

Slashing is disabled at launch. At launch, the network will operate with an honest supermajority assumption. Going forward, slashing conditions for violating BFT finality and producing invalid state transitions will be added via normal governance procedures.

Why should I delegate during the MainNet “Restricted” Phase if there is no inflation?

The requirement for unlocking transfers is to gain momentum around community governance. We expect a large percentage of distributed supply to participate in the voting to showcase this. If you are not delegating, you might be delaying when the community can make this decision. Validators will cast votes for their delegates (unless delegates want to override it), thus making it easy on delegates who might have limited ability to control their holdings in the short term (due to limited custody support for example).

Since there is no slashing initially, delegation is risk-free and ensures that as soon as inflation starts, people will begin receiving their rewards. If you are planning to delegate, you still should be careful to choose which validators to delegate to. Validators who don’t maintain an online presence will be kicked out and won’t receive their rewards.

How do I become an initial validator at MainNet “Restricted” Phase? How do I accept delegations?

The main way to become a validator at MainNet “Restricted” phase is to participate in the upcoming revision of Stake Wars and be an active validator of TestNet. There will be tutorials published on Github and already now you can run your nodes on Betanet. Specifically, Stake Wars 2.0 will be around delegations, so as a participant in Stake Wars you will be able to learn how to set up delegation smart contracts and invite people to delegate to you. 

From our side, we will also connect all active participants of Stake Wars with existing token holders who are interested in delegating, making sure that participants have enough stake to take a seat in MainNet “Restricted” phase.

Alternatively, if you are an existing NEAR token holder you will be able to stake your own funds freely.

As a developer, how do I create accounts for my users?

During POA and Restricted stages, only the NEAR Foundation is able to freely create accounts after doing KYC. NEAR Foundation, as part of its distribution activities, will provide a way for people to receive some initial amount of NEAR which they can use to provision their account and deploy applications.

If an application needs users to have an on-chain account, it can route them to the NEAR Foundation’s work drop landing page (which will be created).

Alternatively, applications can use Access Keys to their own application as a proxy identity and provide a way to “export” the user’s identity later to a full account. We are going to write a separate blog post to describe how this can be done.

The major part of this work was done by James Prestwich and Barbara Liau from

TLDR: Today we are releasing a set of tools to deploy EVM contracts on the NEAR network, thus benefiting from the performance, user experience and developer tooling of NEAR. Underneath, it’s implemented as an execution environment which runs Ethereum as a smart contract on NEAR.  Web3.js tooling works with NEAR via a custom provider. 

EVM support and web3.js provider

Ethereum’s developer community is large, and many crypto developers are familiar with the Ethereum Virtual Machine (EVM). Solidity, an EVM-targeted language, has been developed since the beginning to serve as the primary language for smart contracts. While it has clear limitations when compared to general purpose languages like Rust and TypeScript, Solidity maintains broad adoption and extensive tooling for on-chain development.

NEAR, on the other hand, uses the WebAssembly Virtual Machine (WASM), an increasingly popular technology both in crypto and in the wider tech world. The majority of the crypto space is moving in this direction, with projects like ETH2, Polkadot, and more deciding to use WASM.

While we believe strongly in WebAssembly, we recognize the need to simplify this transition for developers, and are releasing a way for existing EVM contracts to run on NEAR. To do so, we’ve deployed the EVM as a smart contract. Conveniently, the Parity Ethereum client has an EVM implementation in Rust that is easily compilable to WebAssembly. 

Running the EVM as a smart contract is essentially a simplified version of the ETH2 / Serenity execution environment concept, and it doesn’t require any custom transaction processing logic! You can find the EVM contract on Github.

Since the majority of Ethereum tooling relies on web3.js, we’ve implemented a custom web3 provider, NearProvider,  that allows direct communication to Ethereum contracts via familiar interfaces in near-web3-provider library. NearProvider handles the connection to the Near network, and automatically translates objects and RPC calls for you.

Let’s dig in!

How it works

First, let’s get your Solidity application running on NEAR’s TestNet:

If you don’t have an existing Truffle project, set it up first. You can find the example here –

Next, install NEAR shell:

npm install -g near-shell

Then, login with NEAR wallet:

near login

This will redirect you to the NEAR web wallet, and walk you through creating a new account. You can enter any accountID you’d like to use going forward. Next, you will authorize the CLI to use this account via a transaction, and then enter the newly created accountID to complete the login.

The next step is to configure NEAR as another network in truffle.js:

The above code imports near-web3-provider, which provides a mapping from Ethereum RPCs to NEAR’s network.

Next, we’ll point it to the keyStore that contains your NEAR account, from which you will be deploying applications (and paying fees). Here, I use my account illia, but you should change this to your accountId.

And that’s it, you are ready to deploy applications to NEAR’s EVM!

truffle migrate –network near

You can checkout success of your transaction in the block explorer:

The final step is to plugin your near-web3-provider into your frontend web3 code. This way you can now use NEAR Wallet and enable people to onboard and use your application easily.

Once you have your provider set up, you can interact with near-evm using Truffle, Web3.js, and many other standard Solidity development tools. While the library is still in early stages, many web3-based apps will just work out of the box.

You can checkout full example here:

NEAR EVM support is ready for your project! Start developing today.


Here are the useful resources:


On Nov 11, 4pm PST we had the second Stake Wars call with around 20 people.

Due to the issues uncovered last week, we took more caution this time and chose to start the genesis in house and invite external people to join afterwards. The network was started several minutes before the call, and during the call, Peter demonstrated how to join the network and stake to become a validator.

The network went down at 14560 blocks at around 9:00pm PST on Monday. All validating nodes crashed almost simultaneously. From the logs we observed that the nodes had dramatic increase in memory and cpu usage right before the crash. Due to the lack of proper logging, we were not able to determine the cause of the crash and therefore decided to restart the network on Tuesday with more careful debugging and logging setup.

The network crashed again on Tuesday night, around 11pm PST. From the valgrind output we saw that a function that broadcasts message to the network used an unreasonable amount of memory. After some investigation and sifting through logs of more than 1GB we found that there is a subtle bug in our network code that would only be triggered under a specific circumstance. We quickly deployed a quick fix that prevents such bug in normal situations but are still working on fully fixing the issue in the byzantine setting. We restarted the network again on Wednesday and it has been running without any downtime since then.

Released v0.4.6 with updates (fully implemented finality gadget) and fixes described below.


  • The aforementioned network bug. More specifically, when we receive account announcement we check whether it already exists in the routing table by doing an exact match. However, since account announcement has epoch id, and because a newly joined peer would rebroadcast the account announcement they receive from peers, if a node in the network announce their account for the next epoch at the same time, it causes the announcement to overwrite each other. Each overwrite would lead to a broadcasting to the entire network and therefore causes exponential growth of network messages, which causes the entire network to crash. The issue is temporarily fixed in and we are still working on fully fixing the issue.
  • We also noticed that, even though we fixed some major memory leaks last week, nodes were still leaking memory slowly. Through inspection we found that some caches in ShardsManager were not properly implemented and caused the leak. This issue is fixed in (which is pending more testing).
  • There is also some issue with rpc that makes wallet sometimes nonfunctional. Validators complained that they have to try multiple times to register one account name. This issue is fixed in

The experience this week shows that stability of our network is improving with each week. For next week, we will again open registration for stake wars to the public with a customized landing page that does input validation.

We also invite validator to start actually trying malicious or DDOS types of attacks to start testing non vanilla behaviors.

Today we are open sourcing the main code base of the NEAR Protocol client. You can start exploring code on GitHub right now.

It’s the first milestone in our plan to build a decentralized future. From my previous experience at Google with open sourcing projects (ScikitFlow, TensorFlow), the earlier a project opens the source code, the easier it is to build a truly open source community around it.

Our grand vision of making crypto and blockchain accessible to billions of people starts with a more intuitive UX for both end users and developers. While end-user experience is an important topic, today we’ll focus on developer experience. The tools we’re building are the first step in addressing this.

Our aim for open sourcing the code today is two-fold:

  • Start iterating on developer experience with real developers;
  • Enable collaborations with external developers who would be interested in contributing to the client development or ecosystem;

In this post, I’ll briefly describe what is included, how it fits into the bigger picture and how you can get involved.


We are using TypeScript as the main programming language, which makes it easy for anyone with a background in JavaScript to build smart contracts. Also, this allows developers to test smart contracts with familiar JavaScript tools.

Near Studio

Building and testing ERC-20 contract in NEAR Studio

We are building a lightweight web-based IDE — NEAR Studio (github), where one can try building smart contracts now. We’ve provided an example fiddle of an ERC-20 contract that you can play with right now. Share your fiddles with us on Discord.


Running DevNet and interacting via RPC interface

As the backend to NEAR Studio, we provide a “DevNet”, which is a stripped-down version of the NEAR node that only runs WebAssembly and State Transition without running consensus/networking. This is an analog of the Ganache project in Ethereum. See how to run and use DevNet here.

We are going to add more documentation in the next few days about how to use NEAR Studio and DevNet together to test deploying and transacting with your smart contracts.

If you are interested in the consensus layer or how the NEAR Protocol works overall, feel free to dive deeper into the code. Currently, we have just a minimal amount of architecture in place to facilitate contributions. You can also learn more about our consensus on research portal: Informal spec to TxFlow and Beacon Chain consensus spec.

Upcoming Milestones

Now that codebase is open we are going to be diligent about reporting current progress and upcoming milestones through GitHub issues and Community Updates.

We split our future development into three major milestones:

  • DevNet: complete developer experience for our blockchain. We are progressing on this milestone pretty well, but there is still more work to be done.
  • “Minimum Viable Blockchain” (MVB): a fully functioning blockchain that can provide a platform for running experiments on governance, economics and user experience. This version will only have a Beacon chain consensus.
  • Shard chains: adding sharding of state and processing to MVB.

Even though the release of these milestones is ordered, we are working on them in parallel.

Get Started

Developers, we encourage you to identify problems in the blockchain space you are most interested in (scalability, usability for developers or consumers, etc) and start working on that. The easiest way to start is to join our Discord or create a discussion issue on Github. Or simply find a bug in our code and fix it 🙂

PS. Note on the license. It is currently GPL v3 because of usage of Substrate components. Parity promised to switch the license to Apache v2 when they release POC v3 in a few months. Thus we will update as well to Apache v2 at that moment.

If you want to stay up to date with what we build at NEAR, use the following channels:

Lastly, please subscribe to our newsletter.

Thanks to Ash Egan, Erik Trautman and Bowen Wang for comments on the draft of this post.

A central component of any blockchain is the consensus. At its core, Blockchain is a distributed storage system where every member of the network must agree on what information is stored there. A consensus is the protocol by which this agreement is achieved.

The consensus algorithm usually involves:

  • Election. How a set of nodes (or single node) is elected at any particular moment to make decisions.
  • Agreement. What is the protocol by which the elected set of nodes agrees on the current state of the blockchain and newly added transactions.

In this article, I want to discuss the first part (Election) and leave exact mechanics of agreement to a subsequent article.

Proof of Work:

Examples: Bitcoin, Ethereum

The genius of Nakamoto presented the world with Proof of Work (PoW) consensus. This method allows participants in a large distributed system to identify who the leader is at each point in time. To become a leader, everybody is racing to compute a complex puzzle and whomever gets there first ends up being rewarded. This leader then publishes what they believe is the new state of the network and anybody else can easily prove that leader did this work correctly.

There are three main disadvantages to this method:

  • Pooling. Because of the randomness involved with finding the answer to the cryptographic puzzle which solves a given block, it’s beneficial for a large group of independent workers to pool resources and find the answer more predictably. With pooling, if anybody in the pool finds the answer, all members of the pool gets fraction of the reward. This increases likelihood of payout at any given moment even if each reward is much smaller. Unfortunately, pooling leads to centralization. For example it’s known that 53%+ of Bitcoin network is controlled by just 3 pools.
  • Forks. Forks are a natural thing in the case of Nakamoto consensus, as there can be multiple entities that found the answer within same few seconds. The fork which is ultimately chosen is that which more other network participants end up adopting. This leads to a longer wait until a transaction can be considered “final”, as one can never be sure that the current last block is the one that most of the network is building on.
  • Wasted energy. A huge number of customized machines operate around the world solely performing computations for the sake of identifying who should be the next block leader, consuming more electricity than all of Denmark. Iceland for example spends a significant percentage of all electricity produced on mining Bitcoin.

Proof of Stake.

Examples: EOS, Steemit, Bitshares

The most widely adopted alternative to Proof of Work is Proof of Stake (PoS). As an idea, it means that every node in the system participates in decisions proportionally to the amount of money they have.

One of the main ways of using PoS in practice is called Delegated Proof of Stake (DPoS). In this system, the whole network votes for “delegates” — participants who maintain the network and make all of the decisions on behalf of the other members. Depending on the implementation, delegates must either personally stake a large sum of money or use it to campaign for their election. Both of these mean that only high net worth individuals or consortia can be delegates.

In theory, this is very similar to how equity in companies works. In that case, small equity holders participate in elections and elect a small number of decision makers (the board of directors), who are typically large equity holders. These large equity holders then make all of the major decisions on the behalf of all shareholders.

Depending on the specifics of consensus itself, the Proof of Stake system can address the forking and wasted energy that are problematic with Proof of Work. This method still has downside of centralization due to either small number of individual nodes (EOS) or centrally controlled pools end up participating in network maintenance. Also, in specific implementations of DPoS, the fact that all delegates know each other means that slashing (penalizing delegate for wrongdoing by taking their stake) may not happen because a majority of delegates must vote for it.

Ultimately, these factors mean that a small club of rich get richer, perpetuating some of the systemic problems that blockchains were created to address.

Thresholded Proof Of Stake:

Examples: NEAR

NEAR uses an election mechanism called Thresholded Proof of Stake (TPoS). The general idea is that we want a deterministic way to have a large number of participants that are maintaining network maintenance thereby increasing decentralization, security and establishes fair reward distribution. The closest alternative to our method is an auction, where people bid for fixed number of items and at the end the top N bids win, while receiving a number of items proportional to the size of their bids.

In our case, we want a large pool of participants (we call them “witnesses”) to be elected to make decisions during a specific interval of time (we default to one day). Each interval is split into a large number of block slots (we default to 1440 slots, one every minute) with a reasonably large number of witnesses per each block (default to 1024). With these defaults, we end up needing to fill 1,474,560 individual witness seats.

Example of selecting set of witnesses via TPoS process

Each witness seat is defined by the stake of all participants that indicated they want to be signing blocks. For example, if 1,474,560 participants stake 10 tokens each, then each individual seat is worth 10 tokens and each participant will have one seat. Alternatively, if 10 participants stake 1,474,560 tokens each, individual seat still cost 10 tokens and each participant is awarded with 147,456 seats. Formally, if X is the seat price and {Wi} are stakes by each individual participant:

Formula to identify single witness seat threshold

To participate in the network maintenance (become a witness), any account can submit a special transaction that indicates how much money one wants to stake. As soon as that transaction is accepted, the specified amount of money is locked for at least 3 days. At the end of the day, all of the new witness proposals are collected together with all of the participants who signed blocks during the day. From there, we identify the cost for an individual seat (with the formula above), allocate a number of seats for everybody who has staked at least that amount and perform pseudorandom permutation.

NEAR Protocol uses inflationary block rewards and transaction fees to incentivize witnesses to participate in signing blocks. Specifically, we propose an inflation rate to be defined as percentage of total number of tokens. This encourages HODLers to run participating node to maintain their share in the network value.

When participant signs up to be witness, the portion of their money is locked and can not be spend. The stake of each witness is unlocked a day after the witness stops participating in the block signature. If during this time witness signed two competing blocks, their stake will be forfeited toward the participant that noticed and proved “double sign”.

The main advantages of this mechanism for electing witnesses are:

  • No pooling necessary. There is no reason to pool stake or computational resources because the reward is directly proportional to the stake. Put another way, two accounts holding 10 tokens each will give the same return as 20 tokens in a single account. The only exception if you have less tokens then threshold, which is counteracted by a very large number of witnesses elected.
  • Less Forking. Forks are possible only when there is a serious network split (when less then ⅓ adversaries present). In normal operation, a user can observe the number of signatures on the block and, if there is more than ⅔+1, the block is irreversible. In the case of a network split, the participants can clearly observe the split by understanding how many signatures there are versus how many there should be. For example, if the network forks then the majority of the network participants will observe blocks with less than ⅔ (but likely more than ½) of necessary signatures and can choose to wait for a sufficient number of blocks before concluding that the block in the past is unlikely to be reversed. The minority of the network participants will see blocks with less than ½ signatures, and will have a clear evidence that the network split might be in effect, and will know that their blocks are likely to be overwritten and should not be used for finality.
  • Security. Rewriting a single block or performing a long range attack is extremely hard to do since one must get the private keys from witnesses who hold ⅔ of total stake amount over the two days in the past. This is with assumption that each witness participated only for one day, which will rarely happen due to economic incentive to continuously participate if they holding tokens on the account.

A few disadvantages of this approach:

  • Witnesses are known well in advance so an attacker could try to DDoS them. In our case, this is very difficult because a large portion of witnesses will be on mobile phones behind NATs and not accepting incoming connections. Attacking specific relays will just lead to affected mobile phones reconnecting to their peers.
  • In PoS, total reward is divided between current pool of witnesses, which makes it slightly unfavorable for them to include new witnesses. In our approach we add extra incentives for inclusion of new witness transactions into the block.

This system is a framework which can incorporate a number of other improvements as well. We are particularly excited about Dfinity and AlgoRand’s research into using Verifiable Random Functions to select random subset of witnesses for producing next block, which helps with protecting from DDoS and reducing the requirement to keep track of who is a witness at a particular time.

In future posts of this series, we will discuss the Agreement part of our consensus algorithm, sharding of state and transactions and design of distributed smart contracts.

To follow our progress you can use:


Thanks to Ivan Bogatyy for feedback on the draft. Thanks to Alexander Skidanov, Maksym Zavershynskyi, Erik Trautman, Aliaksandr Hudzilin, Bowen Wang for helping putting together this post.

No spam. Never shared. Opt out at any time.