NEAR Protocol Specifications and Standards

This repository hosts the current NEAR Protocol specification and standards. This includes the core protocol specification, APIs, contract standards, processes, and workflows.

Changes to the protocol specification and standards are called NEAR Enhancement Proposals (NEPs).

NEPs

NEP #	Title	Author	Status
0001	NEP Purpose and Guidelines	@ori-near @bowenwang1996 @austinbaggio @frol	Living
0021	Fungible Token Standard (Deprecated)	@evgenykuzyakov	Deprecated
0141	Fungible Token Standard	@evgenykuzyakov @oysterpack, @robert-zaremba	Final
0145	Storage Management	@evgenykuzyakov	Final
0148	Fungible Token Metadata	@robert-zaremba @evgenykuzyakov @oysterpack	Final
0171	Non Fungible Token Standard	@mikedotexe @evgenykuzyakov @oysterpack	Final
0177	Non Fungible Token Metadata	@chadoh @mikedotexe	Final
0178	Non Fungible Token Approval Management	@chadoh @thor314	Final
0181	Non Fungible Token Enumeration	@chadoh @thor314	Final
0199	Non Fungible Token Royalties and Payouts	@thor314 @mattlockyer	Final
0245	Multi Token Standard	@zcstarr @riqi @jriemann @marcos.sun	Final
0256	Non-Fungible Token Events	@telezhnaya	Final
0264	Promise Gas Weights	@austinabell	Final
0297	Events Standard	@telezhnaya	Final
0300	Fungible Token Events	@telezhnaya	Final
0330	Source Metadata	@BenKurrek	Final
0364	Efficient signature verification and hashing precompile functions	@blasrodri	Final
0366	Meta Transactions	@ilblackdragon @e-uleyskiy @fadeevab	Final
0368	Bridge Wallets	@lewis-sqa	Final
0393	Sould Bound Token (SBT)	@robert-zaremba	Final
0399	Flat Storage	@Longarithm @mzhangmzz	Final
0408	Injected Wallet API	@MaximusHaximus @lewis-sqa	Final
0413	Near Wallet API - support for signMessage method	@gagdiez @gutsyphilip	Final
0418	Remove attached_deposit view panic	@austinabell	Final
0448	Zero-balance Accounts	@bowenwang1996	Final
0452	Linkdrop Standard	@benkurrek @miyachi	Final
0455	Parameter Compute Costs	@akashin @jakmeier	Final
0488	Host Functions for BLS12-381 Curve Operations	@olga24912	Final
0491	Non-Refundable Storage Staking	@jakmeier	Final
0492	Restrict creation of Ethereum Addresses	@bowenwang1996	Final
0508	Resharding v2	@wacban @shreyan-gupta @walnut-the-cat	Final
0509	Stateless validation Stage 0	@robin-near @pugachAG @Longarithm @walnut-the-cat	Final
0514	Fewer Block Producer Seats in testnet	@nikurt	Final
0518	Web3-Compatible Wallets Support	@alexauroradev @birchmd	Final
0519	Yield Execution	@akhi3030 @saketh-are	Final
0536	Reduce the number of gas refunds	@evgenykuzyakov @bowenwang1996	Final
0539	Cross-Shard Congestion Control	@wacban @jakmeier	Final
0568	Resharding V3	@staffik @Longarithm @Trisfald @marcelo-gonzalez @shreyan-gupta @wacban	Final
0584	Cross-shard bandwidth scheduler	@jancionear	Final
0591	Global Contracts	@bowenwang1996 @pugachag @stedfn	Final

Specification

NEAR Specification is under active development. Specification defines how any NEAR client should be connecting, producing blocks, reaching consensus, processing state transitions, using runtime APIs, and implementing smart contract standards as well.

Standards & Processes

Standards refer to various common interfaces and APIs that are used by smart contract developers on top of the NEAR Protocol. For example, such standards include SDK for Rust, API for fungible tokens or how to manage user's social graph.

Processes include release process for spec, clients or how standards are updated.

Contributing

Expectations

Ideas presented ultimately as NEPs will need to be driven by the author through the process. It's an exciting opportunity with a fair amount of responsibility from the contributor(s). Please put care into the details. NEPs that do not present convincing motivation, demonstrate understanding of the impact of the design, or are disingenuous about the drawbacks or alternatives tend to be poorly received. Again, by the time the NEP makes it to the pull request, it has a clear plan and path forward based on the discussions in the governance forum.

Process

Spec changes are ultimately done via pull requests to this repository (formalized process here). In an effort to keep the pull request clean and readable, please follow these instructions to flesh out an idea.

1. Sign up for the governance site and make a post to the appropriate section. For instance, during the ideation phase of a standard, one might start a new conversation in the Development » Standards section or the NEP Discussions Forum.

2. The forum has comment threading which allows the community and NEAR Collective to ideate, ask questions, wrestle with approaches, etc. If more immediate responses are desired, consider bringing the conversation to Zulip.

3. When the governance conversations have reached a point where a clear plan is evident, create a pull request, using the instructions below.

   • Clone this repository and create a branch with "my-feature".

   • Update relevant content in the current specification that are affected by the proposal.

   • Create a Pull request, using nep-0000-template.md to describe motivation and details of the new Contract or Protocol specification. In the document header, ensure the Status is marked as Draft, and any relevant discussion links are added to the DiscussionsTo section. Use the pull request number padded with zeroes. For instance, the pull request 219 should be created as neps/nep-0219.md.

   • Add your Draft standard to the NEPs section of this README.md. This helps advertise your standard via github.

   • Once complete, submit the pull request for editor review.

   • The formalization dance begins:

     • NEP Editors, who are unopinionated shepherds of the process, check document formatting, completeness and adherence to NEP-0001 and approve the pull request.
     • Once ready, the author updates the NEP status to Review allowing further community participation, to address any gaps or clarifications, normally part of the Review PR.
     • NEP Editors mark the NEP as Last Call, allowing a 14 day grace period for any final community feedback. Any unresolved show stoppers roll the state back to Review.
     • NEP Editors mark the NEP as Final, marking the standard as complete. The standard should only be updated to correct errata and add non-normative clarifications.

Tip: build consensus and integrate feedback. NEPs that have broad support are much more likely to make progress than those that don't receive any comments. Feel free to reach out to the NEP assignee in particular to get help identify stakeholders and obstacles.