For people who know Bitcoin & Ethereum

How NEAR works, in one page

You already know blocks, hashes, signatures, proof of work and proof of stake. This page shows what NEAR does differently — accounts, sharding, receipts, fees — with animations you can step through. About 20 minutes.

NEAR in one paragraph#

NEAR is a proof-of-stake layer 1. It is one chain whose work is split into shards by account name; every ~0.6 s a block arrives carrying one chunk per shard, and blocks are final about 1.2 s later. Users have named accounts (alice.near) with several keys of different power. Transactions turn into receipts that hop between shards, so calls between contracts are asynchronous. Contracts are WebAssembly, fees are tiny and predictable, and keeping data on chain locks some NEAR rather than burning it.

1 · Accounts are names, not hashes#

On Bitcoin and Ethereum your identity is derived from a key. On NEAR an account is a name that you own, and keys are attached to it. That one change gives you key rotation, multiple devices and app-specific permissions — without smart-contract wallets.

• Names are a tree. near hands out alice.near; only alice.near can create app.alice.near. Short top-level names are reserved, so in practice you get a .near (or similar) name.
• Implicit accounts skip the name: a 64-character hex string is an ed25519 public key, and an Ethereum-style 0x… address is also a valid NEAR account controlled by an EVM wallet. Send NEAR to one and it springs into existence.
• Two kinds of keys. A full-access key can do anything, including adding and removing keys. A function-call key can only call listed methods of one contract, can’t attach deposits, and has a fee allowance. dApps create one for you so you can play without a wallet popup on every move.
• Nonces are per key, and every transaction includes a recent block hash, so it expires after 86,400 blocks (about 14 hours) — old signed transactions can’t be replayed later.
• A contract lives on an account. Deploying is just attaching Wasm code to an account; token.near is both an account and the token contract.

2 · Proof of stake, epochs and validators#

NEAR is secured by staked NEAR. Anyone can run a validator or delegate to one through a staking pool contract. Time is cut into epochs of 43,200 blocks (about 7 hours at today’s speed). At each epoch boundary the protocol picks validators by stake for the next epoch and assigns their roles.

• Block & chunk producers (the top 100 by stake) each track one shard, build its chunks, and take turns producing blocks.
• Chunk validators are everyone, 420 at the time of writing. They store no shard state; each block they are re-assigned at random to check chunks (section 5).
• Rewards come from new issuance of at most 2.5% a year, shared by stake and uptime; delegators earn through their pool minus its fee. Full rewards need ~99% uptime and drop to zero below 90%; producers under 80% (validator-only nodes under 70%) are kicked out of a later epoch.
• Unstaking takes 4 epochs before the tokens can be withdrawn — about a day at today’s epoch length.

3 · Blocks every 0.6 s, final in ~1.2 s#

Here are the three chains side by side, in real time. NEAR is fast mostly because its consensus needs only one round of small messages per block, and because finality is deterministic rather than probabilistic.

There is no mining race. The schedule of who produces each height is known for the whole epoch, weighted by stake. Each block collects approvals from other producers; that is enough to move on, and two approved blocks in a row make a block final.

4 · Sharding: one chain, many lanes#

A single global state that every node executes is what limits Ethereum L1. NEAR splits the state into shards but keeps one chain: shards don’t have their own block history, they each fill a slot in every block. This design is called Nightshade.

• A shard is just a range of account names. Which shard you are on is decided by your name — you never choose or see it.
• Busy shards are split through scheduled protocol upgrades (resharding), without stopping the chain. That is how mainnet grew to the 10 shards it has today.
• Because shards run in parallel, total throughput grows with the number of shards, while each node’s work stays bounded.

5 · Stateless validation: how split work stays secure#

Sharding’s classic problem: if only a few nodes execute a shard, a few dishonest nodes could cheat. NEAR’s answer (shipped in 2024 as “Nightshade 2.0”) is to separate executing a chunk from checking it. The few who execute keep the state; the many who check need none.

Checkers are re-drawn at random every block from the whole validator set, so to cheat you would need to control the majority of a random sample — roughly the same bar as attacking an unsharded chain. And because checking needs no disk state, validator hardware stays modest.

6 · Life of a transaction: receipts#

This is the part that most surprises Ethereum developers. A NEAR transaction doesn’t execute all at once. It is first converted into a receipt — an internal message — which is delivered to the shard of the account it targets. Anything a contract does to another account (call it, send it NEAR) creates more receipts, each executed in a later block on the right shard.

• No global atomicity. Each receipt commits or fails on its own. If a downstream call fails, earlier state changes stay; the contract handles it in a callback. Patterns like “deduct first, restore on failure” replace Solidity’s revert-everything.
• Things happen in between. Other transactions can touch your contract between a call and its callback, so state must be consistent at the end of every receipt.
• Latency is in blocks. Every receipt hop costs one block (~0.6 s), whether or not the target is on the same shard; only a transaction to your own account runs in the block it lands in. A typical swap finishes in a handful of blocks.
• Deposits travel with receipts. Attached NEAR leaves the sender immediately and is refunded automatically if the receiving call fails.

Want to see this live? The NEAR IDE has a simulator that shows every receipt of your own contract’s calls, and an inspector that does the same for any real transaction.

7 · Gas and fees#

Like Ethereum, every operation costs gas; unlike Ethereum, gas is calibrated to time: 1 Tgas (10¹² gas) ≈ 1 millisecond of compute on validator hardware. A transaction can buy up to 1,000 Tgas. The gas price has a floor and only creeps up (at most 0.5% per block) when blocks are more than half full, so fees stay predictable. There is no tip auction.

• You attach gas, pay for it at the current price, and get unused gas back as a refund receipt.
• Fees are burnt. Today 30% of the gas burnt while running a contract’s code still goes to that contract’s account as a developer rebate; the next protocol upgrade (HSP-027, nearcore 2.14) removes it, after which all gas is burnt. At high usage, burning can exceed new issuance.
• Meta-transactions (NEP-366) let a relayer pay gas for a user’s signed action, so apps can onboard users who hold no NEAR.

8 · Storage staking instead of state bloat#

Every byte an account stores — its keys, contract code and contract data — must be backed by NEAR held in that account (tiny accounts under 770 bytes are exempt). It is not a fee: delete the data and the NEAR is free again. Locked NEAR can’t be staked, so state growth has a real cost and can’t happen for free.

Practical effect: contracts that let users add data usually ask them to attach a small deposit to cover it (standards like NEP-145 formalise this), and a contract account without enough balance simply can’t write more state.

9 · Smart contracts#

• Contracts are WebAssembly, written mostly in Rust (near-sdk-rs) or JavaScript/TypeScript (near-sdk-js). The runtime exposes host functions for storage, logs, promises and crypto.
• One contract per account, and it can be upgraded by redeploying with a full-access key. Remove all full-access keys and the code is locked — immutable, as long as the contract itself has no method to upgrade or add keys.
• View calls are free: anyone can read contract state through an RPC node without a transaction.
• Standards are NEPs (NEAR’s ERCs): NEP-141 fungible tokens, NEP-171 NFTs, NEP-245 multi-tokens, NEP-297 events.

To write your first one with the Solidity version side by side, start with NEAR by Example.

10 · The NEAR token#

• Units: 1 NEAR = 10²⁴ yoctoNEAR. Total supply is about 1.31 billion at the time of writing.
• Uses: paying gas, storage staking, and securing the network through staking.
• Issuance: at most 2.5% per year goes to validators and delegators; gas fees are burnt, so heavy usage offsets issuance.

11 · Beyond one chain#

Two newer pieces let NEAR act for other chains. Chain Signatures: a network of independent MPC node operators signs transactions for Bitcoin, Ethereum, Solana and more on behalf of NEAR accounts and contracts — a contract can own a Bitcoin address. NEAR Intents: users sign what they want (“swap my ETH on Base for USDC on Solana”), solvers compete to fill it, and a contract on NEAR settles it. Together they let people use apps on NEAR from any chain. The Chain Signatures & Intents module goes deeper.

Cheat sheet: Ethereum → NEAR#

Check yourself#