NEAR
NEAR ยท NEAR PROTOCOL

What is NEAR Protocol?

Layer 1 Sharded
Last verified: April 2026
This page documents what NEAR Protocol is and how it works โ€” based on the NEAR whitepaper and official NEAR Foundation documentation. Nothing here is financial advice. Always do your own research.

๐Ÿ‘‹ New to this? Just start reading at the top โ€” it begins in plain English and gets more detailed as you scroll. Jump to any level:

๐ŸŸข The simple version

Plain English โ€” no jargon. Start here.

In one sentence

NEAR is a blockchain that tries hard to be easy to use โ€” including letting you have a simple username instead of a long, scary address.

The "friendly" blockchain

Crypto is often intimidating: long random wallet addresses, confusing steps, jargon everywhere. NEAR's whole goal is to fix that. Its best-known feature is human-readable names โ€” you can be something like "alice.near" instead of a 42-character string of gibberish. The idea is to make crypto feel as normal as using any app.

What it offers

NEAR is fast and cheap, supports the usual apps and DeFi, and has pushed into newer areas like AI projects and tools that let you use several blockchains without even knowing which one you're on. Its coin is called NEAR.

What to keep in mind

NEAR's ease of use is genuinely appealing for beginners, but it's a smaller ecosystem than the giants, with fewer apps and less money flowing through it. It competes in a crowded field of fast, cheap chains. NEAR's price is volatile, as always.

๐ŸŸก A bit more detail

For when you want to go a little deeper.

Nightshade sharding: how it actually works

Nightshade divides the NEAR blockchain into shards, each processing a subset of transactions and storing a subset of the state. Each shard produces a "chunk" โ€” a portion of a full block. Validators are assigned to shards in rotating groups. A full block on NEAR contains chunks from all shards, assembled together. The key innovation: transactions that span multiple shards (cross-shard transactions) are handled through asynchronous execution โ€” the transaction initiates on one shard and a receipt is sent to the destination shard to complete execution.

Stateless validation (Phase 2, 2023) means validators verify transaction validity using cryptographic witnesses (state witnesses) provided alongside transactions, rather than maintaining the full shard state locally. This enables smaller validators to participate and makes it practical to increase the shard count significantly.

What it's used for in real life

NEAR hosts a growing DeFi ecosystem (Ref Finance DEX, Burrow lending). The NEAR account model with named accounts powers social applications. Calimero Network builds private shards on NEAR for enterprise use. The AI-adjacent project NEAR AI (announced 2024) positions NEAR as infrastructure for AI agent economies. Several gaming projects use NEAR for in-game asset ownership. The Aurora EVM-compatible environment on NEAR allows Ethereum dApps to deploy without modification.

The NEAR account model

NEAR accounts are named (alice.near, bob.alice.near) rather than cryptographic hashes. Sub-accounts create hierarchical namespaces โ€” contracts can be deployed at sub-accounts of their parent. Each account can have multiple access keys with different permission levels: full-access keys (can do anything) and function-call access keys (can only call specific contract methods). This key model enables applications to manage keys on behalf of users, abstracting away seed phrase management entirely.

How people evaluate this

Key NEAR metrics: daily transactions, active accounts, TVL in DeFi, shard count (indicator of scaling capacity), and developer activity. NEAR's competitive position is developer experience and sharding scalability โ€” it targets the "next billion users" narrative where simplicity matters more than decentralisation. Live data: CoinGecko ยท NEARBlocks.

๐ŸŸฃ The full technical picture

For the technically curious.

The NEAR whitepaper: Nightshade design

The NEAR Protocol whitepaper describes a system where the blockchain state is split across N shards, each maintained by a rotating committee of validators. The core challenge of sharding โ€” cross-shard communication and atomic transactions โ€” is handled by converting synchronous cross-contract calls into asynchronous receipts. This means NEAR does not provide atomic cross-shard transactions (where either both parts execute or neither does); instead, contracts must be designed to handle asynchronous execution and potential failures.

Source: Skidanov, A. & Polosukhin, I. (2020). Nightshade: Near Protocol Sharding Design. near.org/papers/nightshade

Doomslug: NEAR's block production mechanism

NEAR uses a consensus mechanism called Doomslug for block production. In Doomslug, a block produced by the designated block producer is considered "threshold-confirmed" once it receives endorsements from more than half of the validators โ€” without requiring a full BFT consensus round. Full finality (irreversibility) is provided by an additional BFT finality gadget that runs in parallel. This separation of concerns (fast liveness from Doomslug, strong safety from BFT finality) is similar to Polkadot's BABE + GRANDPA design.

Technical detail

NEAR's state witness model for stateless validation: when a validator is assigned to validate a chunk (shard block), it receives a "state witness" โ€” a compact cryptographic representation of the portion of the state the transactions in that chunk will access, along with Merkle proofs of inclusion. The validator can verify transaction validity using only this witness, without maintaining the full shard state. The witness is produced by the previous chunk producer and distributed via P2P. This enables validators to participate with much smaller storage requirements, making higher shard counts economically practical.

Key protocol parameters

  • Consensus: Doomslug (block production) + BFT finality gadget
  • Sharding: Nightshade (dynamic sharding, stateless validation from 2023)
  • Current shards: 6 (expandable dynamically)
  • Block time: ~1 second
  • Smart contract languages: Rust (primary), JavaScript/TypeScript, AssemblyScript
  • Account model: Named accounts (alice.near), multiple access keys
  • EVM compatibility: Via Aurora (EVM on NEAR)
  • Total supply: 1 billion NEAR (inflationary, ~5% annually)

Source: NEAR documentation. docs.near.org