DOCSEARCHbyAlgolia
Submit Docs

NEAR Enhancement Proposals (NEPs)

repository·master·Indexed 42 days ago

https://github.com/near/neps

The authoritative source for NEAR Protocol specifications, APIs, and standards. This repository contains core protocol specifications, contract standards (such as NEP-141 Fungible Token and NEP-171 Non Fungible Token), and the formal process for proposing and implementing protocol updates.

Tokens
99.9K
Snippets
190
Records
396
Agent score
53%

What's inside NEPs

  1. Overview of NEAR Protocol Specifications and Standards

    master
    This repository serves as the central location for the NEAR Protocol specification and standards. It contains the core protocol specification, APIs, contract standards, processes, and workflows. Developers use this repository to understand how to build NEAR clients, participate in consensus, process state transitions, use runtime APIs, and implement smart contract standards.

  2. Overview of Resharding V3 (NEP-568)

    master
    NEP-568 introduces a new resharding implementation and shard layout designed for production networks. The primary goal is to increase chain capacity by splitting overutilized shards. It also serves as the architectural foundation for future features such as Dynamic Resharding, Instant Resharding, and Shard Merging. This version is a significant redesign that integrates with modern NEAR protocol features like Stateless Validation, Single Shard Tracking, and Mem-Trie, replacing the older Resharding V1 (NEP-040) and V2 (NEP-508) implementations.

  3. Host Functions for BLS12-381 Curve Operations (NEP-488)

    master
    NEP-488 introduces a set of NEAR host functions designed for efficient operations on the BLS12-381 elliptic curve. These functions are primarily intended to enable high-performance verification of BLS signatures and zkSNARKs on the NEAR blockchain. The implementation provides support for both $G_1$ and $G_2$ groups to allow for flexible implementation of cryptographic protocols.

  4. Overview of NEP-178: Non Fungible Token Approval Management

    master
    NEP-178 defines a standard system for allowing specific users or contracts to transfer specific Non-Fungible Tokens (NFTs) on behalf of an owner. This is designed for workflows where a simple atomic transfer is insufficient, such as marketplaces or dApps that require granular control over who can move a token. It provides a uniform interface for approving accounts (both individual NEAR accounts and smart contracts) to manage specific token IDs.

  5. Overview of the Multi Token Standard (NEP-245)

    master

    NEP-245 defines a standard interface for a Multi Token contract. Unlike separate Fungible Token (FT) or Non-Fungible Token (NFT) standards, a Multi Token contract can represent multiple asset classes—including fungible, semi-fungible, and non-fungible tokens—within a single contract.

    This approach improves efficiency by allowing batch transfers and reducing transaction overhead for marketplaces, games, and DAOs. It also leverages NEAR's sharding and storage staking model to support on-chain metadata and low transaction fees.

  6. What is the Vault NEP (NEP-621)?

    master

    NEP-621 defines a standardized interface for vault contracts on the NEAR Protocol, inspired by the Ethereum ERC-4626 standard.

    A vault contract allows users to deposit an underlying NEP-141 compliant fungible token (FT) in exchange for vault shares. These shares represent proportional ownership of the vault's total assets.

    Key characteristics include:

    • Underlying Assets: Can be any NEP-141 compliant token (e.g., stablecoins or yield-bearing tokens).
    • Minting/Redeeming: When depositing, the vault mints new shares based on the current exchange rate (total assets vs. total shares). When redeeming, the vault burns shares and returns the equivalent amount of the underlying asset.
    • Composable Shares: The issued shares are themselves NEP-141 compliant fungible tokens. This allows them to be transferred, traded on DEXs, or used as collateral in lending protocols.

  7. Overview of Dynamic Resharding (NEP-639)

    master

    NEP-639 introduces Dynamic Resharding, a protocol-level mechanism that allows shards to split automatically based on their state size. Unlike previous versions (Resharding V2 and V3), which required manual analysis and hardcoded protocol upgrades to change shard layouts, Dynamic Resharding is autonomous and deterministic.

    How it works:

    1. Detection: A shard proposes a split during chunk application when its memory usage exceeds a configurable threshold.
    2. Selection: The block producer for the last block of an epoch selects the best candidate for splitting.
    3. Execution: The new shard layout takes effect two epochs after the selection.
    4. Validation: The process is validated through state witnesses and requires no human intervention or coordinated binary releases.

  8. Overview of Multi Token Standard Approval Management

    master

    The Multi Token Standard Approval Management (part of NEP-245) provides a uniform interface for token owners to authorize specific NEAR accounts (either individual users or smart contracts) to transfer specific tokens on their behalf. This system is conceptually similar to the approval mechanisms found in Ethereum's ERC-721 and ERC-1155 standards.

    While NEAR's core Multi Token standard supports atomic transfers and mt_transfer_call (which allows attaching tokens to a cross-contract call), this approval system is intended for use cases requiring more granular control, such as marketplaces, dApps, or complex token workflows.

  9. Overview of NEP-616: Deterministic AccountIds

    master
    NEP-616 introduces deterministic AccountIds to support sharded contract designs on NEAR Protocol. By deriving account IDs from contract initialization code and state, developers can deploy multiple instances of the same contract code across different accounts more efficiently. This addresses challenges related to permissions, storage costs, refunds, and code verification in sharded architectures, building upon the cost-reduction benefits of global contracts introduced in NEP-591.

  10. Sticky Validator Assignment across resharding

    master

    To prevent a 'state-sync stampede' where every shard layout change causes validators to reshuffle assignments, NEAR uses the StickyReshardingValidatorAssignment feature. This introduces an AssignmentStrategy to manage how validators are assigned to shards during and after a split:

    • CarryOver: Used when the shard layout is unchanged. Validators keep assignments by ShardIndex.
    • StickyResharding: Used during a resharding event. Unchanged shards keep validators by ShardId. The children of a split shard inherit a stake-balanced subset of the parent's validators via greedy bin-packing.
    • Fresh: Fallback path used if sticky construction fails or the feature is disabled. Assignment starts from scratch.

  11. How dynamic resharding works

    master

    Dynamic resharding automates the process of splitting shards based on their memory usage. It extends the Resharding V3 infrastructure with three core mechanisms:

    1. Split proposal: During chunk application, each shard computes a proposed split point based on trie memory usage using find_trie_split.
    2. Split selection: The block producer for the last block of an epoch collects all proposed_split values from chunk headers and selects the best candidate (prioritizing force_split_shards, then the shard with the highest total_memory()).
    3. Layout derivation: The epoch manager derives a new ShardLayoutV3 (which includes cumulative split history) for two epochs ahead.

    The actual execution (MemTrie splitting, state migration, etc.) reuses the existing Resharding V3 machinery.

    Timeline:

    • Epoch N (Last Block): Split is decided and embedded in the block header.
    • Epoch N+1: The network prepares; the parent shard's memtrie is pre-loaded in the background.
    • Epoch N+2: The new shard layout takes effect.

  12. Gas pricing and resource accounting for ML-DSA-65

    master

    Using ML-DSA-65 signatures affects gas and transaction size accounting:

    • Verification Cost: Transactions are charged for the additional CPU work required to verify ML-DSA-65 signatures. The charge covers the mean verification-cost difference over classical schemes. A transaction can carry at most two ML-DSA-65 signatures (one outer signer and one inner DelegateAction signer).
    • Invalid Signatures: Like classical schemes, transactions with invalid signatures are rejected at validation without being charged gas.
    • Witness Size: ML-DSA-65 signatures are approximately 3.3 KiB (roughly 50x larger than classical signatures). The ChunkStateWitness transaction-byte bound accounts for the full signature size to prevent DoS attacks via large signatures.
    • Storage Cost: The AddKey operation includes a charge for the public-key bytes carried.