LibraryConsensus2019Design paperCorpus record
The NEAR White Paper
NEAR. The NEAR team.
NEAR's public design paper: a sharded proof-of-stake chain with a single account model, nightshade-style data availability across chunks, and a stated intent that hiding the shards from application authors is part of the product.
NEAR shards execution across chunks, has a small group produce each chunk, and uses a nightshade-style assumption that a block can be valid even when some chunks are still hidden, as long as the data becomes available.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 7
Code
Source, repository, and what is actually hosted
- NEAR white paperhttps://near.org/papers/the-official-near-white-paper/
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
A block is a list of chunks
Each shard produces a chunk. A block producer assembles chunk headers into a block. The design tries not to require every validator to re-execute every shard.
Claim 02 · Paper model
Nightshade hides chunks, carefully
The paper's scaling move is to let a block be proposed before every chunk body has been seen by everyone, and to punish a producer who hides data. Data availability, not raw execution, is the constraint it names.
Claim 03 · Paper model
Doomslug gives practical finality
A block that gathers enough endorsements is treated as final under the paper's fast path. The full Byzantine proof and the fast path are related and should not be blurred.
Claim 04 · Paper model
Human-readable accounts are a product choice
The paper spends real attention on account names, access keys and usability. That is unusual in a consensus paper and it is part of the design, not a website feature added later.
Claim 05 · Paper model
Resharding is promised, not free
Splitting a shard when it is busy is the long-term scaling plan. The paper describes the direction. Live resharding is an engineering milestone that has to be checked against the network, not against the abstract.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 A block is a list of chunks
Observation
What the study says
Each shard produces a chunk. A block producer assembles chunk headers into a block. The design tries not to require every validator to re-execute every shard.
Model
What has to hold
Enough stake is online in each shard assignment to produce chunks.
Falsifier
What would retire it
Can a block include a chunk whose body is not yet public, and how long may that last?
02 Nightshade hides chunks, carefully
Observation
What the study says
The paper's scaling move is to let a block be proposed before every chunk body has been seen by everyone, and to punish a producer who hides data. Data availability, not raw execution, is the constraint it names.
Model
What has to hold
State roots in chunks match execution. A wrong root must be provable.
Falsifier
What would retire it
Can a block include a chunk whose body is not yet public, and how long may that last?
03 Doomslug gives practical finality
Observation
What the study says
A block that gathers enough endorsements is treated as final under the paper's fast path. The full Byzantine proof and the fast path are related and should not be blurred.
Model
What has to hold
Enough stake is online in each shard assignment to produce chunks.
04 Human-readable accounts are a product choice
Observation
What the study says
The paper spends real attention on account names, access keys and usability. That is unusual in a consensus paper and it is part of the design, not a website feature added later.
Model
What has to hold
Epoch assignments are random with respect to stake, so an attacker cannot camp in one shard.
Falsifier
What would retire it
What can an access key restrict, in the paper's account model?
05 Resharding is promised, not free
Observation
What the study says
Splitting a shard when it is busy is the long-term scaling plan. The paper describes the direction. Live resharding is an engineering milestone that has to be checked against the network, not against the abstract.
Model
What has to hold
Enough stake is online in each shard assignment to produce chunks.
Falsifier
What would retire it
What can an access key restrict, in the paper's account model?
03 Sequence
One action, as an operating tape
- 01Validators are assigned to produce or validate chunks for particular shards in an epoch.
- 02A chunk producer executes the shard's transactions and publishes a chunk with a state root.
- 03A block producer gathers chunk headers. Under the nightshade rule it may proceed if enough chunks are present and the missing ones are accounted for.
- 04Validators endorse the block. After the doomslug threshold, applications are told the block will not be reversed on the fast path.
- 05If a producer withholds a chunk body, the protocol's challenge path is supposed to make that omission visible and costly.
04 Load-bearing
The argument, and where a pitch drops it
Availability is the real shard problem
The cut
A header without a body lets a shard claim it did work nobody can check. NEAR's text is useful because it centres that failure. A design review should ask what a fisherman or a validator actually downloads, and what happens in the slots before a fraud proof can land.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Hiding shards from developers does not hide failure domains from operators.
Fast finality is a threshold, not a mood
The cut
Doomslug finality means a stated share of stake endorsed a block and would be slashed for equivocation. It does not mean every laptop has executed every shard. Wallets that treat an endorsement as a local execution proof are over-reading.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A later client, parameter or reward formula is a different object from this paragraph.
Account names do not change consensus
The cut
They change who can safely use the chain. Access keys that limit a dapp's authority are a response to the 'one key signs everything' failure mode. That part of the paper is easy to skip and expensive to skip.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The white paper is not the current protocol specification. NEAR publishes specs separately.
05 Register
What has to be true
Stake and threshold · Not re-measured
Enough stake is online in each shard assignment to produce chunks.
Model · Not re-measured
Hidden chunk bodies are detectable within the protocol's challenge window.
Model · Not re-measured
State roots in chunks match execution. A wrong root must be provable.
Stake and threshold · Not re-measured
Epoch assignments are random with respect to stake, so an attacker cannot camp in one shard.
06 Divergence
What happened after the paper
NEAR shipped, revised its nightshade implementation, and treated full resharding as a phased rollout rather than a day-one fact. Account-key improvements continued. Cite the 2019 paper for the chunk model. Cite the network for what is actually final this week.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it names
Sharded systems often leak the shard map into every application. NEAR's paper treats that leak as a product failure. Developers should see one chain. The protocol underneath still has to produce chunks, assign validators, and make data available.
What the design proposes
- Chunk producers handle a portion of a block. Block producers assemble a header over those chunks.
- Nightshade, in the paper's terms, keeps one block that contains the chunks rather than a family of loosely coupled chains.
- Account names and a predictable rent or storage cost are part of making the system usable, not an appendix.
How the mechanism is specified
- A validator who hides chunk data should be detectable because other validators only sign what they could fetch.
- Cross-contract calls are asynchronous. The paper does not pretend a sharded call is a local function call.
- Resharding is described as a protocol feature. Later implementations have their own timeline.
What this page does not treat as proven
- The white paper is not the current protocol specification. NEAR publishes specs separately.
- Hiding shards from developers does not hide failure domains from operators.
- No throughput number from the paper is repeated here as a live measurement.
Why the desk still reads it
The studio lesson is the product constraint: if application authors must know the shard, the protocol is unfinished. That is a higher bar than 'we have committees'.
09 Lexicon
Terms, opened into the record
- Chunk
- The piece of a block that belongs to one shard: transactions plus the resulting state root.
- Nightshade
- The paper's approach of assembling a block from chunk headers and treating missing bodies as a fault to be proven.
- Doomslug
- The fast finality rule under which enough endorsements make a block practically irreversible.
- Access key
- A key with limited permission on an account, so one application is not given the right to move every asset.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.