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).
NEP # | Title | Author | Status |
---|---|---|---|
0001 | NEP Purpose and Guidelines | @jlogelin | 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 | Review |
0264 | Promise Gas Weights | @austinabell | Final |
0297 | Events Standard | @telezhnaya | Final |
0330 | Source Metadata | @BenKurrek | Review |
0366 | Meta Transactions | @ilblackdragon @e-uleyskiy @fadeevab | Final |
0393 | Sould Bound Token (SBT) | @robert-zaremba | Final |
0399 | Flat Storage | @Longarithm @mzhangmzz | Final |
0448 | Zero-balance Accounts | @bowenwang1996 | Final |
0452 | Linkdrop Standard | @benkurrek @miyachi | Final |
0455 | Parameter Compute Costs | @akashin @jakmeier | Final |
0514 | Fewer Block Producer Seats in testnet |
@nikurt | Final |
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 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.
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.
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.
-
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.
-
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.
-
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 asDraft
, and any relevant discussion links are added to theDiscussionsTo
section. Use the pull request number padded with zeroes. For instance, the pull request219
should be created asneps/nep-0219.md
. - Add your Draft standard to the
NEPs
section of this README.md. This helps advertise your standard via github. - Update Docusaurus documentation under the
specs/Standards
to describe the contract standard at a high level, how to integrate it into a Dapp, and a link to the standard document (ie.neps/nep-0123.md
). This helps advertise your standard via nomicon. Any related nomicon sections should be prefixed and styled using the following snippet:
:::caution This is part of proposed spec [NEP-123](https://github.com/near/NEPs/blob/master/neps/nep-0123.md) and subject to change. :::
-
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 toReview
. - 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.
This repository uses Docusaurus for the Nomicon website.
-
Move into the
/website
folder where you will run the following commands:-
Make sure all the dependencies for the website are installed:
# Install dependencies yarn
-
Run the local docs development server
# Start the site yarn start
Expected Output
# Website with live reload is started Docusaurus server started on port 3000
The website for docs will open your browser locally to port
3000
-
-
Make changes to the docs
-
Observe those changes reflected in the local docs
-
Submit a pull request with your changes