Documentation

Block Processing This section covers how blocks are processed once they arrive from the network. Data Structures Please refer to this section for details about blocks and chunks. Validity of Block Hea

Overview This chapter covers the NEAR Protocol chain specification. Chain Specification • Block Processing • Consensus • Light Client • Selecting Chunk and Block Producers • Transactions in the Blockc

Consensus Definitions and notation For the purpose of maintaining consensus, transactions are grouped into blocks . There is a single preconfigured block G called genesis block . Every block except G

Context API Context API mostly provides read-only functions that access current information about the blockchain, the accounts (that originally initiated the chain of cross-contract calls, the immedia

Contract preparation This document describes the contract preparation and instrumentation process as well as the limitations this process imposes on the contract authors. In order to provide high perf

Overview This chapter describes various data structures used by NEAR Protocol. Data Structures • Access Keys • Accounts • Block and Block Header • Data Types • Merkle Proofs • Transaction

Data Types type CryptoHash = [u8; 32] A sha256 or keccak256 hash. AccountId = String Account identifier. Provides access to user's state. type MerkleHash = CryptoHash Hash used by a struct implementin

DataReceiptCreationConfig Describes the cost of creating a data receipt, DataReceipt. basecost type: Fee Base cost of creating a data receipt. costperbyte type: Fee Additional cost per byte sent.

Economics API Accounts own certain balance; and each transaction and each receipt have certain amount of balance and prepaid gas attached to them. During the contract execution, the contract has acces

ExtCostsConfig base type: Gas Base cost for calling a host function. readmemorybase type: Gas Base cost for guest memory read readmemorybyte type: Gas Cost for guest memory read writememorybase type:

Fee Costs associated with an object that can only be sent over the network (and executed by the receiver). sendsir Fee for sending an object from the sender to itself, guaranteeing that it does not le

Function Call In this section we provide an explanation how the FunctionCall action execution works, what are the inputs and what are the outputs. Suppose runtime received the following ActionReceipt:

Math API randomseed ![allow(unused)] fn main() { randomseed(registerid: u64) } Returns random seed that can be used for pseudo-random number generation in deterministic way. Panics • If the size of th

Merkle Proofs Many components of NEAR Protocol rely on Merkle root and Merkle proofs. For an array of sha256 hashes, we define its merkle root as: CRYPTOHASHDEFAULT = [0] 32 def combinehash(hash1, has

Miscellaneous API ![allow(unused)] fn main() { valuereturn(valuelen: u64, valueptr: u64) } Sets the blob of data as the return value of the contract. Panics • If valuelen + valueptr exceeds the memory

Promises API promisecreate ![allow(unused)] fn main() { promisecreate(accountidlen: u64, accountidptr: u64, methodnamelen: u64, methodnameptr: u64, argumentslen: u64, argumentsptr: u64, amountptr: u64

Registers API Registers allow the host function to return the data into a buffer located inside the host oppose to the buffer located on the client. A special operation can be used to copy the content

Routing table exchange algorithm Every node on the network stores its own copy of the Routing Graph . nearcore exchanges this graph in two steps. When a connection is set up, the two nodes do a full s

Runtime Runtime layer is used to execute smart contracts and other actions created by the users and preserve the state between the executions. It can be described from three different angles: going st

Overview This chapter covers the NEAR Protocol runtime specification. Runtime Specification • Account Receipt Storage • Actions • Applying chunk • Components • Runtime Crate • Bindings Specification •

StateRecord type: Enum Enum that describes one of the records in the state storage. Account type: Unnamed struct Record that contains account information for a given account ID. accountid type: Accoun

Transaction See Transactions documentation in the Runtime Specification section.

Transactions A transaction in Near is a list of actions and additional information. There are two versions of a transaction: ![allow(unused)] fn main() { pub enum Transaction { V0(TransactionV0), V1(T

Transactions in the Blockchain Layer A client creates a transaction, computes the transaction hash and signs this hash to get a signed transaction. Now this signed transaction can be sent to a node. W

Trie API Here we provide a specification of trie API. After this NEP is merged, the cases where our current implementation does not follow the specification are considered to be bugs that need to be f

Upgradability This part of specification describes specifics of upgrading the protocol, and touches on few different parts of the system. Three different levels of upgradability are: • Updating withou

Build a full web3 app, from its contract to a frontend using indexers. Welcome! In this guide we will help you navigate NEAR tech stack, so you can build Web3 applications from start to finish in no-t

Learn how to create a signature request in Abstract DAO to execute actions on foreign EVM chains. The Abstract DAO contract works as an intermediary between decentralized organizations in NEAR and EVM

Learn how to sign Abstract DAO requests for different chains and relay them to target EVM networks. In the previous section, we saw how to register a signature request on the Abstract DAO contract. No

NEAR has a rich access key system, allowing fine-grained control over accounts In NEAR, accounts can hold multiple keys, each key has its own set of permissions and specific signature schemes to sign