Documentation

Access Keys Access key provides an access for a particular account. Each access key belongs to some account and is identified by a unique (within the account) public key. Access keys are stored as acc

AccessKeyCreationConfig Describes the cost of creating an access key. fullaccesscost type: Fee Base cost of creating a full access access-key. functioncallcost type: Fee Base cost of creating an acces

Account Receipt Storage There is a definition of all the keys and values we store in the Account Storage Received data key = receiverid: String,dataid: CryptoHash value = Option<Vec<u8 Runtime saves i

Accounts Account ID NEAR Protocol has an account names system. Account ID is similar to a username. Account IDs have to follow the rules. Account ID Rules • minimum length is 2 • maximum length is 64

actioncreationconfig Describes the cost of creating a specific action, Action. Includes all variants. createaccountcost type: Fee Base cost of creating an account. deploycontractcost type: Fee Base co

Actions There are a several action types in Near: ![allow(unused)] fn main() { pub enum Action { CreateAccount(CreateAccountAction), DeployContract(DeployContractAction), FunctionCall(FunctionCallActi

Applying chunk Inputs and outputs Runtime.apply takes following inputs: • trie and current state root • validatoraccountsupdate • incomingreceipts • transactions and produces following outputs: • new

Block and Block Header The data structures for block and block headers are ![allow(unused)] fn main() { pub struct Block { /// Block Header pub header: BlockHeader, /// Headers of chunk in the block p

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

Cross-Contract Call This guide assumes that you have read the Financial Transaction section. Suppose Alice is a calling a function reservetrip(city: String, date: u64) on a smart contract deployed to

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

Financial Transaction Suppose Alice wants to transfer 100 tokens to Bob. In this case we are talking about native Near Protocol tokens, oppose to user-defined tokens implemented through a smart contra

Fraction numerator type: u64 denominator type: u64

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:

Light Client The state of the light client is defined by: • BlockHeaderInnerLiteView for the current head (which contains height, epochid, nextepochid, prevstateroot, outcomeroot, timestamp, the hash

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

Messages All messages sent in the network are of type PeerMessage. A PeerMessage is encoded with Protocol Buffers , using the schema in network.proto . Some fields of that schema are bytes fields that

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

Receipt All cross-contract (we assume that each account lives in its own shard) communication in Near happens through Receipts. Receipts are stateful in a sense that they serve not only as messages be