At ETHDenver 2022, a top blockchain conference and hackathon, we proudly announced the launch of Pagoda: the world’s first Web3 startup platform. The Pagoda vision is to empower developers with a fully Web3-native toolset for building, maintaining, and scaling blockchain-based startups. 

Open Source, Integrated: Open Services for Developer-Entrepreneurs

In the first seven years of smart contract blockchains, building out across the Web3 tech stack has made it easier to build blockchain-based products and services. But even as the time from idea to working prototype has shortened with improved tooling, it’s still painful for engineers to monitor and maintain those prototypes and mature them into efficient, growth-ready businesses. 

Enter Pagoda, the first integrated Web3 startup platform and end-to-end solution for developer-entrepreneurs. 

The blockchain ecosystem still largely relies on many Web2 tools – especially the tools required to monitor an app’s performance and to track adoption and growth. These aren’t designed to work with Web3 products and come with all the platform risks that Web3 seeks to avoid. Every service we use now in Web2 needs to be rebuilt to integrate with Web3, to support the principles of users owning their own data and blockchain-based accounts. 

Pagoda’s objective is to offer Web3 native, fully decentralized versions of these tools at every layer of the stack, from the base blockchain protocol all the way up to the application and marketing/distribution layers. The NEAR ecosystem consists of many open source projects that can be integrated as “open services”: a familiar, cohesive development experience on top of a decentralized toolset. By providing interactive tutorials, scalable infrastructure, and operational analytics that are truly Web3 native, Pagoda better integrates them into one simple interface.

Growing the NEAR Ecosystem: the Best Choice for Founders

Beginning in 2018, NEAR Inc’s original mandate was to build the NEAR Protocol and launch MainNet, which we did in October 2020. From there, we focused on maintaining and evolving the protocol – notably with the launch of sharding, which started in late 2021 – and improving the developer experience.

Now we are a team of 70+ members across 20 countries. Pagoda will continue to contribute to the development of the NEAR ecosystem, as Near Inc did, by building and maintaining the protocol, SDKs, and APIs, while building out more tools and services at every layer of the stack. 

The core Pagoda product is the Developer Console.

Integrating the Web3 Stack: Pagoda Developer Console

The Pagoda Developer Console integrates open source, Web3-native tools across the entire stack, making it easier than ever for developer-entrepreneurs to build, maintain, and scale blockchain-based businesses.

The transition from developer to entrepreneur happens faster in Web3, and it’s getting easier all the time to launch a product. Actually scaling that product requires not just developer tools, but a whole range of tools to support and grow post-launch – all of these are integrated in the Developer Console. This includes a DAO to manage upgrades to applications, deep on-chain analytics, and even triggers and alarms in case of unexpected events. Connecting to users directly becomes even more important as a Web3 product grows, so founders also need easy ways to launch ownership tokens, NFTs for marketing, and notifications for simple communication with users. All of these tools need to be Web3-native from the ground up and seamlessly integrated in a single experience: this is the vision for founders on Pagoda.

As the NEAR Ecosystem expands and more tools are created, Pagoda will continuously integrate them into the product stack. It’s still early days for the Developer Console, but we encourage all developer-entrepreneurs to try it out and explore the future of Web3 startups. 

Try the Pagoda Developer Console Today

To start exploring the Developer Console and sign up for news and updates from Pagoda, visit and follow on Twitter at @PagodaPlatform. 

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 unit 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 increase the incentives to run validating nodes (as they receive higher real yield).

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).

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.

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.


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 and more tokens burned (increasing their yield). As more people use the network, their individual usage fees can be kept low while validators are still compensated for storing more data overall, which 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 the NEAR token balancing good utility for users and developers with what validators need to help make the network increasingly more secure. 

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.