{
"consensusAlgorithm": {
"name": "Nightshade",
"description": "Nightshade is a sharding-based, Proof-of-Stake (PoS) consensus protocol enabling parallel transaction processing.\n Near Nightshade has one single main chain producing blocks. Main chain blocks do not contain actual transactions, but they include one chunk header for each shard, where\n a chunk is the equivalent of a block in a standard, non-shared blockchain. At the beginning of the epoch, both the block and chunk production schedule\n are randomly generated. For each block on the main chain, and for every shard, one of the assigned chunk producers is responsible to produce the part of the main chain block\n related to the shard, and share the chunk header with the network. Finality is determined by the NFG (Nightshade finality gadget), and after 2 consecutive blocks are built on the same fork the t-2 block is considered final.\n Reverting a finalized block will require at least 1/3 of the total stake to be slashed.",
"blockTime": 0.6,
"consensusFinality": 1.2,
"unbondingPeriod": 172800
},
"economicSecurity": {
"token": {
"symbol": "NEAR",
"decimals": 24,
"coingeckoId": "near"
}
},
"pruningWindow": 129600,
"risks": {
"economicSecurity": {
"value": {
"value": "Staked assets",
"sentiment": "good",
"description": "There are staked assets on the DA layer that can be slashed in case of a data withholding attack. A dishonest supermajority of validators must collude to finalize a block with missing or invalid data. The invalid block would be added to the chain but rejected by honest full nodes.\n "
},
"adjustSecurityRisk": true
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer."
}
},
"systemCategory": "public",
"technology": {
"description": "\n## Architecture\n\n\n\n## Near Nightshade\n\n### Consensus\nNEAR's Nightshade consensus operates a Proof-of-Stake (PoS) system that enables parallel processing of transactions through a sharded architecture. As with any PoS system, validators are required to lock a stake to be eligible for block production and attestations.\nThe main differentiator of the NEAR blockchain is that its blocks do not contain actual transactions but rather block headers of separate blockchains, known as shards.\nThe ***main chain*** can contain many shards, and the current NEAR implementation supports 9 shards.\n\n\n\n\n\n\nEach shard is composed of chunks, which are equivalent to standard blockchain blocks.\nEssentially, the state of the main chain is split into n shards, and only the shards block headers end up being part of the main chain.\n\n\n\n\n\n\nBecoming a block producer requires locking (staking) a certain amount of tokens, currently around 11,000 NEAR. Staking operates through a threshold PoS mechanism, where a user’s stake must exceed the protocol's seat price—determined by the total NEAR tokens staked by other validators—in order to become a validator. The largest stakers at the beginning of a particular epoch are selected as block producers for that epoch. Each block producer is randomly assigned a certain number of shards to manage. \nBefore the epoch starts, the block producer downloads the state of the shard(s) they are assigned to (they have 1 epoch to complete this download). Throughout the epoch, they collect transactions that affect their assigned shard(s) and apply them to the state. NEAR nodes have an automatic 'garbage collection' routine that deletes the state of previous shards after five epochs, freeing up unused storage.\nWithin an epoch (12 hours), the main chain block and shard block production schedule is determined by a randomness seed generated at the beginning of the epoch. For each block height, a main chain block producer is assigned. \nValidators participate in several validation rounds within the epoch. For each round, one validator in each shard is chosen to be the chunk producer, and one validator from the entire set is chosen to be the block producer. Validators can serve as both block and chunk producers, but they maintain separate stakes for these roles.\nThe shard block producer is responsible for producing the part of the block related to their shard, known as a chunk. The chunk contains the list of transactions for the shard to be included in the block, as well as the Merkle root of the resulting state. Each main chain block contains either one or zero chunks per shard, depending on whether the shard can keep up with the main chain block production speed.\n\n\n\n\n\n\nA block on the main chain will only contain a small header of the chunk, composed of the Merkle root of all applied transactions and the Merkle root of the final state. When a block producer generates a chunk, they also produce an associated state witness, which is necessary for executing the chunk.\n\nChunk producers maintain the full state of their shard. Validators, on the other hand, do not maintain the state of any shard locally; instead, they download and verify all the block headers. They validate chunks using the state witness created by the chunk producers.\n\n### Data Availability\nSince only shard chunk producers maintain the shard state (while main chain validators do not), and main chain block producers need to attest to the chunk headers, data availability of the shard data must be ensured.\n\nAfter a block producer creates a chunk, they generate an erasure-coded version of it using Reed-Solomon encoding. The extended chunk is then split into multiple parts, which are distributed to all main chain validators.\n\n\n\n\nA block producer will not process a main chain block if they do not have the corresponding chunk sample for at least one chunk included in the block, or if they are unable to reconstruct the entire chunk for any shard for which they maintain the state.\n\nFor a particular chunk to be considered available, it is sufficient that [mainChainBlockProducer/nOfShards] + 1 of the block producers possess their respective parts and are able to serve them. As long as the number of malicious actors does not exceed one-third of the validators (block producers), any chain built by more than half of the block producers will have all its chunks available.\n\n\n\n\n\n### Finality\nFinality is determined by a modified Doomslug finality gadget. A block is considered final after two consecutive blocks are built on the same fork, making the block that is two blocks behind (t-2) final. Reverting a finalized block would require slashing at least one-third of the total stake.\n\n## L2s Data Availability\nA rollup can utilize a dedicated Data Availability (DA) smart contract on a NEAR shard, known as a Blob Store contract, where it posts data as standard NEAR transactions. All transactions are converted into Receipts, and depending on their actions, some receipts may be processed over two blocks.\nRegarding data retrieval, full nodes prune Receipts after 3 epochs (approximately 36 hours). Once the pruning window expires, the data remains accessible only through archive nodes.\n ",
"references": [
{
"title": "Near Nightshade Consensus",
"url": "https://pages.near.org/downloads/Nightshade.pdf"
},
{
"title": "Near Doomslug Finality Gadget",
"url": "https://discovery-domain.org/papers/doomslug.pdf"
},
{
"title": "Near documentation",
"url": "https://docs.near.org/"
},
{
"title": "Near Core - Architecture",
"url": "https://near.github.io/nearcore/"
},
{
"title": "Blob Store contract - Nuffle Labs",
"url": "https://github.com/Nuffle-Labs/data-availability/blob/5026b81aa5d941aaf4dd1b23bc219b9150e84405/contracts/blob-store/src/lib.rs"
}
],
"risks": [
{
"category": "Funds can be lost if",
"text": "a dishonest majority of Near validators finalizes an unavailable block."
}
]
},
"throughput": [
{
"size": 16777216,
"frequency": 1,
"sinceTimestamp": 1587513600
},
{
"size": 33554432,
"frequency": 1,
"sinceTimestamp": 1742342400
},
{
"size": 33554432,
"frequency": 0.6,
"sinceTimestamp": 1747141200
},
{
"size": 37748736,
"frequency": 0.6,
"sinceTimestamp": 1755561600
}
],
"type": "Public Blockchain",
"usedWithoutBridgeIn": [
{
"id": "rss3",
"name": "RSS3 Value Sublayer",
"slug": "rss3"
}
],
"usedWithoutBridgeIn": [],
"validators": {
"type": "dynamic"
}
}
rss3+42-31
statuses+3-0
{
"redWarning": {
"text": "RSS3 is retiring the Value Sublayer (VSL) and migrating to Ethereum. The L2 halted on April 24, 2026 and VSL bridge withdrawals have been paused. Previously-initiated withdrawals will be completed as part of the migration; $RSS3 on VSL will be migrated to Ethereum via a claim portal expected in the coming weeks ($POWER converts to $RSS3 at 23:1). See [the official announcement](https://rss3.io/blog/the-next-stage-of-rss3.html)."
},
"unverifiedContracts": []
}