NEAR Protocol

Changelog.

• v0.3.2-plain (2026-10-14; replaces v0.2.4, publish hash 1ab652c5d43dbad6642ad2b0f9701c2e2440abd2988d3d6c30de0956db719ec7): plain-English rewrite for learners. Adds an "At a glance" block, definitions of NEAR-specific terms at first use, labeled analogies, and "why it mattered" notes for each upgrade. Sources [1]–[37] unchanged. No claim changes.
• v0.2.4 (2026-10-14; replaces v0.2.3, publish hash def25f72bb072855d9badcb253c87ea6c5dea3bcc6da0bb159556510d4dc3274): the page record now shows the published status, version, publish date (ET) and proof; removes the line "All dates on this page are UTC." Body wording: the policy line now names the Learning Hub. No claim changes.
• v0.2.3 (2026-10-06; replaces v0.2.2, sha256 d79f31e65df3902ffb9b482bda230edbe0405c82faff4a5a716521bbf41ee438): adds Figs. 1–5 with their captions and source lines; adds sources [36] (NEAR chain state for Fig. 2) and [37] (nearcore 1.16.0 reward code for Fig. 2); adds the line "All dates on this page are UTC." after the page-record table. No claim in the v0.2.2 text changes.
• v0.2.2 (2026-10-06; replaces v0.2.1, sha256 8ffa3d46f847e6b1bef6308f739cbc95afa5e129346736c6d8176690b18caa3d): label change (the Learning Hub label is updated); source-format change to sources [23]–[26], which now lead with "NEAR chain state via FastNEAR RPC, method X, block height Y" and note explorer cross-checks where one exists. No claim changes.
• v0.2.1 (2026-10-06; replaces v0.2, sha256 1a3fe11be04d5cf5ece06cb41236c502f7ce53ed96d16cef85a04bfa4ce033d2): corrected source [24] so the treasury payouts are attributed to epochs 4835 and 4836 (the field reports the previous epoch); named those epochs in the issuance paragraph; cited the nearcore repository [35] for "published on GitHub"; corrected the v0.2 changelog line (the seat floor was removed, not corrected).
• v0.2 (2026-10-06; replaces v0.1, sha256 e4dbcc857c32bc8e649c0d74a4010778b834a4521a145b3740eee8e10bd6c199): corrects issuance and treasury wording; removes the seat floor; corrects the MPC participant count, 2026 security releases, the inflation start, HSP-027 tense, version wording, the resharding note, the Sovereign Fund figure, the Nightshade source and Skidanov's title; adds activation dates and per-release sources; renumbers sources.

At a glance

• NEAR is a proof-of-stake layer-1 blockchain, and token holders delegate NEAR to validators who secure it [1].
• Instead of every computer doing all the work, NEAR splits the network into parts called shards, and on October 6, 2026 it had ten [4][23].
• New NEAR is created each epoch at up to 2.5% of total supply a year, down from a 5% maximum before October 29, 2025 [23][26].
• NEAR accounts can have readable names like alice.near and can control addresses on other blockchains [5][29].
• Some changes are still pending, including a ratified plan to end the 30% fee rebate for app developers, which was not yet live on October 6, 2026 [23][27].

1. What it is

The basics

NEAR Protocol is a proof-of-stake layer-1 blockchain [1].

Token holders delegate NEAR to validators, who process transactions and secure the network [1]. The NEAR token is used for staking, to pay for computation and storage, and to move value between accounts and applications [2].

Shards: splitting the work

NEAR is sharded. A shard is one slice of the network that handles its own share of accounts and transactions. Instead of every node processing every transaction, the network runs several parallel shards, and each shard contributes a "chunk" to every block [4][8].

Analogy, not the mechanism itself: think of a supermarket that opens several checkout lanes instead of one. Each lane serves its own line, and together they make up the store's sales for that minute.

The design is called Nightshade. Alex Skidanov, Illia Polosukhin and Bowen Wang set it out in a paper first published in July 2019 and updated in February 2024 [8]. On October 6, 2026, mainnet's live protocol configuration listed ten shards [23].

Accounts and cross-chain tools

Two more features set NEAR apart. Accounts can have readable names such as alice.near, and one account can hold several keys with different permissions [5]. NEAR also builds "chain abstraction" tools, chain signatures and NEAR Intents, which let a NEAR account control addresses on other blockchains and settle cross-chain trades on NEAR [29][30].

Who builds and changes it

The reference node software is nearcore, published on GitHub [35]. Protocol changes are proposed in NEAR Enhancement Proposals (NEPs), such as NEP-509 for stateless validation [10]. A token-holder governance body, House of Stake, now ratifies some economic changes [27].

2. How it works

Blocks, chunks and shards

A NEAR block is the set of chunks produced by all shards for that block height [4]. The Nightshade paper treats the system as one logical chain [8]. No single participant downloads the full state or the full logical block [8].

Blocks arrive roughly every 600 milliseconds [5]. Validators stay fixed for an epoch of 43,200 blocks, which works out to about 7.2 hours at that pace [3]. An epoch is a fixed stretch of blocks after which the validator lineup can change.

Messages between shards

Accounts on different shards talk to each other asynchronously [4][5]. Asynchronous means one step is sent now and handled a little later, rather than everything happening in one go. A transaction first produces a "receipt", and that receipt runs on the shard where the receiving account lives [4]. NEAR's docs contrast this asynchronous model with Ethereum's synchronous contract execution [5].

Analogy, not the mechanism itself: it works like sending a letter to another office. You hand it off, and the other office acts on it when it arrives.

Consensus and finality

The Nightshade paper describes heaviest-chain consensus [8]. A block's weight is the total stake of the validators whose signatures it carries [8]. On top of that sits a finality gadget, an extra process that locks blocks in. Once it finalizes a block, a fork is impossible unless a very large share of total stake is slashed [8]. The paper points to the separate Doomslug paper for the full consensus algorithm [8].

Stateless validation ("Nightshade 2.0")

What changed. Before nearcore 2.0.0, every node applied every chunk and kept the full state of all shards on disk [9]. Stateless validation, specified in NEP-509, lets nodes check chunks without holding that state [9][10].

The upgrade split validator work into two roles [9]:

• Chunk producers are the top 100 validators by stake [9]. Each holds the state of its assigned shard in memory, produces chunks, and sends "state witnesses" to validators [9]. A state witness is the bundle of data a checker needs to verify a chunk without keeping the whole state.
• Chunk validators are all validators [9]. They keep no state locally, rotate every block, check the state witnesses and send endorsements to block producers [9].

Analogy, not the mechanism itself: a chunk validator is like an auditor who is handed exactly the receipts needed to check one page of the books, instead of keeping a copy of the whole ledger.

Why it mattered. NEAR's docs describe the same split today [1]. The top 100 validators produce and validate blocks and produce chunks [1]. Validators outside the top 100 act as chunk validators, with lower hardware and stake requirements [1]. For operators, that means a smaller validator can take part without the heavier equipment the top 100 need.

How the protocol upgrades

A protocol upgrade takes effect only after validators holding enough stake run the new software [11][23]. The nearcore 2.9.0 notes describe the bar as more than 80% of stake, with a voting window of up to 30 days before the release is withdrawn [11]. The live configuration sets the upgrade threshold at 4/5 of stake [23]. In other words, publishing new code does not change the network by itself; validators adopt it by running it.

Token role and economics

• Issuance (new tokens). Each epoch the protocol mints new NEAR up to a maximum annual rate of 2.5% of total supply: the live configuration shows a maximum inflation rate (max_inflation_rate) of 1/40, or 2.5% [23]. NEAR's docs call 2.5% the target [1]. The reward does not depend on how many fees were collected [1]. Payouts depend on validator uptime: rewards are based on each validator's online ratio, and validators below the uptime thresholds earn less [9][23]. Validators do not receive all of the issuance. In epochs 4835 and 4836, the last two read on October 6, 2026, about 10% of rewards went to the protocol treasury account, treasury.near [24].
• Fees (gas). Gas is counted in fixed units and priced in NEAR [6]. The price resets every block: it rises 1% if the previous block was more than half full and falls 1% otherwise, down to a floor of 0.0001 NEAR per teragas [6]. A teragas is one trillion units of gas. Fees are burned, except for a share rebated to the contracts a transaction touches [1]. The docs put that rebate at 30% of the gas a contract burns [6], and the live configuration still shows 3/10 [23].
• Storage. An account must lock NEAR in proportion to the data it stores [7]. The rate is 10^19 yoctoNEAR per byte, which is 100 kB per NEAR [7]. A yoctoNEAR is the smallest unit of NEAR. Analogy, not the mechanism itself: it is like a deposit on a storage locker that is tied up while you use the space.
• Slashing. If a validator is caught misbehaving, part or all of its stake is burned [1].
• Governance power. In House of Stake, users lock NEAR or supported liquid-staking tokens and receive veNEAR [28]. veNEAR cannot be transferred, and longer locks give more voting power [28].

Accounts and keys

NEAR supports named accounts, implicit accounts derived from a key, and Ethereum-compatible accounts [5]. An account can hold "full access" keys and limited "function call" keys, so a compromised key can be swapped out [5]. Analogy, not the mechanism itself: a full-access key is like a master key to a house, and a function-call key is like a key that opens only the mailbox.

What 2.13.0 changed for keys. nearcore 2.13.0 added the FIPS 204 ML-DSA-65 post-quantum signature scheme as a third key type, alongside ed25519 and secp256k1 [16]. A post-quantum scheme is a signing method designed to resist attacks from future quantum computers. The same release added "gas keys," which carry their own prepaid NEAR balance for gas [16].

Chain signatures

Chain signatures let a NEAR account, including a smart contract, sign transactions for other blockchains [29]. There are three parts [29]:

1. Derivation paths. A NEAR account name plus a path string, such as ethereum-1, deterministically derives an address on another chain [29].
2. The v1.signer contract. Its sign method takes a payload, a path and a signature scheme: 0 for secp256k1 or 1 for ed25519 [29].
3. An MPC signing service. MPC, or multi-party computation, lets several computers jointly produce a signature without any one of them holding the full key. Independent nodes each create signature shares, and no node can sign alone [29]. NEAR's docs describe 8 nodes, and say the set can grow by a vote of active nodes [29]. As of October 6, 2026, the v1.signer contract's on-chain state listed 17 participants with a signing threshold of 11 [25]. A threshold of 11 means at least 11 participants must take part to produce a signature.

Analogy, not the mechanism itself: it is like a bank vault that opens only when enough keyholders turn their keys together.

The docs call this a "one way" tool: it signs outbound transactions on other chains, but it does not read their state [29].

NEAR Intents

With NEAR Intents, a user or AI agent states an outcome, such as swapping token A for token B [30]. Off-chain market makers, also called solvers, then compete to quote it [30]. If the user accepts a quote, a "Verifier" contract on NEAR checks and settles it [30]. That contract is intents.near. It credits deposits to an on-chain ledger and releases tokens only through withdrawals over token bridges, and its code is open source [31]. Withdrawals use several bridges, including Omni Bridge, a proof-of-authority (POA) bridge and HOT Bridge, and each has its own trust model [32].

Analogy, not the mechanism itself: it is like posting a job ("swap A for B"), letting contractors bid, and having a referee check the work before payment is released.

3. What changed

Timeline

Inflation and fees at launch

NEAR launched with 5% annual issuance: 90% went to validators and 10% to a protocol treasury [33]. Contracts received 30% of transaction fees as a rebate, and the other 70% was burned [33].

The 2025 inflation cut

What changed. The maximum yearly issuance went from 5% to 2.5% [11][26]. The 2.9.0 release notes say the change followed a community vote, proposed by Hot_DAO, that drew 91% support from those able to vote [11]. The same notes say many validators run by exchanges and funds did not vote, citing compliance reasons [11]. They also say House of Stake will play a "critical role" in setting economic parameters from now on [11]. The mainnet configuration now shows the 2.5% maximum [23].

Why it mattered. For holders and stakers, the cap on how fast new NEAR can be created was halved. For governance, the notes point economic decisions toward House of Stake [11].

Stateless validation in production

What changed. NEAR's docs describe the chunk-validator role introduced in 2.0.0 as current [1].

Why it mattered. Validators outside the top 100 can take part with lower hardware and stake requirements [1].

The 2.13 upgrade

What changed. As of October 6, 2026, mainnet was at protocol version 86, the network-wide figure [23]. The public RPC nodes that answered our queries ran nearcore 2.13.4; that is their software version, not a network-wide one [23]. The 2.13.0 release also raised the cost of creating an account from about 0.0008 NEAR to about 0.007 NEAR, paid through gas [16].

Why it mattered. Users and builders gained a post-quantum key type and gas keys with their own prepaid gas balance [16]. Creating a new account became more expensive [16]. The release notes also say shards now split automatically [16] (see "Is resharding automatic yet?" below).

HSP-027

What changed. The proposal moves the developer gas rebate from 30% to 0% [27]. Under it, 100% of eligible execution fees go to the protocol's existing fee mechanism, and gas prices and validator rewards are unchanged [27]. Anton Astafiev, CTO of NEAR One, wrote the proposal [27]. The 2.14.0-rc.1 notes include it: the burnt_gas_reward parameter goes from 3/10 to 0 [20].

Why it matters. Builders whose contracts now receive 30% of the gas they burn [6] would stop receiving that rebate once a protocol upgrade activates it [27]. As of October 6, 2026, it was not active [23].

Other 2.14 contents

The release candidate adds an on-chain ML-DSA signature-verification host function [20], a built-in tool that lets contracts check that post-quantum type of signature. It also adds early reassignment of chunk producers that stop producing, and it removes the DelegateV2 action that 2.13.0 had introduced [20].

4. What is open

When does 2.14 reach mainnet?

House of Stake said in July 2026 that HSP-027 would ship in protocol update v2.14, then targeted for August 2026 [27]. It added that the final date depends on engineering readiness, testing and validator coordination [27]. On September 28, 2026, the latest 2.14 build was still a release candidate [22]. On October 6, 2026, the live configuration still showed the 30% rebate [23]. No activation date appears in the sources we reviewed.

Is resharding automatic yet?

Resharding means splitting shards to change their number. The 2.13.0 notes say shards now split automatically at epoch boundaries based on state size, with no protocol upgrade needed [16]. The live configuration's dynamic_resharding field reads false [23], but the field predates 2.13: it is also false in the 2020 genesis configuration, so it does not show whether automatic splitting is on [23]. Archival RPC shows mainnet going from nine to ten shards at block 207,849,134 on July 21, 2026, 01:15:14 UTC (July 20, 9:15:14 p.m. ET), two epochs after protocol 86 took effect, with no protocol-version change and dynamic_resharding still false [26]. That is consistent with automatic shard splitting, but it is not proof that the new mechanism made the split. The current count is ten shards [23].

How much trust goes into chain signatures?

NEAR's docs describe the MPC service as 8 independent nodes [29]. As of October 6, 2026, the v1.signer contract's on-chain state listed 17 participants with a signing threshold of 11 [25]. Users of chain signatures and of anything built on them depend on that set behaving honestly, and on how it changes through votes [29]. The contract lists participants by NEAR account ID; the docs do not describe who runs them [25][29].

Bridge trust models

NEAR Intents settles on NEAR, but withdrawals to other chains go through bridges that each have their own trust model [32]. These include a bridge that uses proof-of-authority consensus [32]. Which bridge a given withdrawal uses depends on the destination chain [32].

Where token economics go next

Polosukhin's Sovereign Fund post is explicitly "a proposal and not a mandate" [34]. It proposes a fund seeded with the existing protocol treasury and fed by protocol revenue [34]. The fund would use yield to pay for public goods such as validator support and MPC providers [34]. The same post says Intents fees are routed into NEAR buybacks [34]. We have not verified the mechanics of that fee routing from protocol documentation, so it is not described here as a protocol rule. Whether the fund is adopted, and in what form, is unknown.

Governance concentration

Upgrades need 4/5 of stake to adopt them [23]. The 2.9.0 notes record that large exchange and fund validators held back from the community vote that preceded the inflation cut [11]. How House of Stake's stake-weighted votes and validator adoption interact on future economic changes is still being worked out in practice [11][27].

Operational security

Six nearcore releases in 2026 were marked as critical fixes for flaws that could crash nodes: 2.10.4 [12], 2.10.6 [13], 2.10.7 [14], 2.11.1 [15], 2.13.2 [18] and 2.13.4 [19]. One feature, DelegateV2, was added in 2.13.0 and is set for removal in 2.14 [16][20].

What this page leaves out

By Learning Hub policy, this dive carries no price, market value, trading or usage-volume figures. Those go stale, and News covers them.

Not financial advice.