NEPs

Summary

NEAR Enhancement Proposals (NEPs) are design documents that describe standards for the NEAR platform, including core protocol specifications, contract standards, and wallet APIs. Each NEP provides concise technical specifications and the rationale behind the proposed enhancement.

Each NEP is championed by a community member, which builds consensus within the community and sheperds the NEP from ideation to completion. The NEP process is designed to be open and transparent, allowing anyone in the NEAR community to propose, discuss, and review ideas for improving the NEAR ecosystem.

All NEPs are stored as text files in a versioned repository, allowing for easy historical tracking.

Motivation

The purpose of the NEP process is to give the community a way to propose, discuss, and document changes that impact the whole NEAR ecosystem in a structured manner. Given the complexity and number of participants involved across the ecosystem, a well-defined process helps ensure transparency, security, and stability.

NEP Types

There are three kinds of NEPs:

  1. A Protocol NEP describes a new feature of the NEAR protocol (e.g. NEP-264, NEP-366)
  2. A Contract Standards NEP specifies NEAR smart contract interfaces for a reusable concept in the NEAR ecosystem (e.g. NEP-141, NEP-171)
  3. A Wallet Standards NEP specifies ecosystem-wide APIs for Wallet implementations (e.g. NEP-413)

Submit a NEP

Each NEP must have a champion that proposes a new idea, shepherds the discussions in the appropriate forums to build community consensus, proposes the NEP and help it progress toward completion.

Start with ideation

Everyone in the community is welcome to propose, discuss, and review ideas to improve the NEAR protocol and standards. The NEP process begins with a new idea for the NEAR ecosystem.

Before submitting a new NEP, publicly check if your idea is original and relevant to the NEAR community. This saves time and avoids proposing something already discussed or unsuitable for most users.

Submit a NEP Draft

Following the above initial discussions, the author willing to champion the NEP should submit the NEP Draft in the form of a Draft Pull Request:

  1. Fork the NEPs repository.
  2. Copy nep-0000-template.md to neps/nep-xxxx.md (do not assign a NEP number yet).
  3. Fill in the NEP following the NEP template guidelines. For the Header Preamble, make sure to set the status as “Draft.”
  4. Push this to your GitHub fork and submit a pull request.
  5. Now that your NEP has an open pull request, use the pull request number to update your 0000 prefix. For example, if the PR is 305, the NEP should be neps/nep-0305.md.
  6. Push this to your GitHub fork and submit a pull request. Mention the @near/nep-moderators in the comment and turn the PR into a “Ready for Review” state once you believe the NEP is ready for review.

NEP Lifecycle

The NEP process begins when an author submits a NEP draft. The NEP lifecycle consists of three stages: draft, review, and voting, with two possible outcomes: approval or rejection.

Throughout the process, various roles play a critical part in moving the proposal forward. Most of the activity happens asynchronously on the NEP within GitHub, where all the roles can communicate and collaborate on revisions and improvements to the proposal.

NEP Process

NEP Stages

Moderator, when moving a NEP to review stage, should update the Pull Request description to include the review summary, example:

---

## NEP Status _(Updated by NEP moderators)_

SME reviews:

- [ ] Role1: @github-handle
- [ ] Role2: @github-handle

Contract Standards WG voting indications (❔ | :+1: | :-1: ):

- ❔ @github-handle
- ❔ ...

<Other> voting indications:

- ❔
- ❔

NEP Outcomes

NEP Roles and Responsibilities

author Author
Anyone can participate

The NEP author (or champion) is responsible for creating a NEP draft that follows the guidelines. They drive the NEP forward by actively participating in discussions and incorporating feedback. During the voting stage, they may present the NEP to the working group and community, and provide a final implementation with thorough testing and documentation once approved.

Moderator Moderator
Assigned by the working group

The moderator is responsible for facilitating the process and validating that the NEP follows the guidelines. They do not assess the technical feasibility or write any part of the proposal. They provide comments if revisions are necessary and ensure that all roles are working together to progress the NEP forward. They also schedule and facilitate public voting calls.

Reviewer NEP Reviewer (Subject Matter Experts)
Assigned by the working group

The reviewer is responsible for reviewing the technical feasibility of a NEP and giving feedback to the author. While they do not have voting power, they play a critical role in providing their voting recommendations along with a summary of the benefits and concerns that were raised in the discussion. Their inputs help everyone involved make a transparent and informed decision.

Approver Approver (Working Groups)
Selected by the Dev Gov DAO in the bootstrapping phase

The working group is a selected committee of 3-7 recognized experts who are responsible for coordinating the public review and making decisions on a NEP in a fair and timely manner. There are multiple working groups, each one focusing on a specific ecosystem area, such as the Protocol or Wallet Standards. They assign reviewers to proposals, provide feedback to the author, and attend public calls to vote to approve or reject the NEP.

NEP Communication

NEP discussions should happen asynchronously within the NEP’s public thread. This allows for broad participation and ensures transparency.

However, if a discussion becomes circular and could benefit from a synchronous conversation, any participants on a given NEP can suggest that the moderator schedules an ad hoc meeting. For example, if a reviewer and author have multiple rounds of comments, they may request a call. The moderator can help coordinate the call and post the registration link on the NEP. The person who requested the call should designate a note-taker to post a summary on the NEP after the call.

When a NEP gets to the final voting stage, the moderator will schedule a public working group meeting to discuss the NEP with the author and formalize the decision. The moderator will first coordinate a time with the author and working group members, and then post the meeting time and registration link on the NEP at least one week in advance.

All participants in the NEP process should maintain a professional and respectful code of conduct in all interactions. This includes communicating clearly and promptly and refraining from disrespectful or offensive language.

NEP Playbook

  1. Once an author submits a NEP draft, the NEP moderators will review their pull request (PR) for structure, formatting, and other errors. Approval criteria are:
    • The content is complete and technically sound. The moderators do not consider whether the NEP is likely or not to get accepted.
    • The title accurately reflects the content.
    • The language, spelling, grammar, sentence structure, and code style are correct and conformant.
  2. If the NEP is not ready for approval, the moderators will send it back to the author with specific instructions in the PR. The moderators must complete the review within one week.
  3. Once the moderators agree that the PR is ready for review, they will ask the approvers (working group members) to nominate a team of at least two reviewers (subject matter experts) to review the NEP. At least one working group member must explicitly tag the reviewers and comment: "As a working group member, I'd like to nominate @SME-username and @SME-username as the Subject Matter Experts to review this NEP." If the assigned reviewers feel that they lack the relevant expertise to fully review the NEP, they can ask the working group to re-assign the reviewers for the NEP.
  4. The reviewers must finish the technical review within one week. Technical Review Guidelines:
    • First, review the technical details of the proposals and assess their merit. If you have feedback, explicitly tag the author and comment: "As the assigned Reviewer, I request from @author-username to [ask clarifying questions, request changes, or provide suggestions that are actionable.]." It may take a couple of iterations to resolve any open comments.
    • Second, once the reviewer believes that the NEP is close to the voting stage, explicitly tag the @near/nep-moderators and comment with your technical summary. The Technical Summary must include:
      • A recommendation for the working group: "As the assigned reviewer, I do not have any feedback for the author. I recommend moving this NEP forward and for the working group to [accept or reject] it based on [provide reasoning, including a sense of importance or urgency of this NEP]." Please note that this is the reviewer’s personal recommendation.
      • A summary of benefits that surfaced in previous discussions. This should include a concise list of all the benefits that others raised, not just the ones that the reviewer personally agrees with.
      • A summary of concerns or blockers, along with their current status and resolution. Again, this should reflect the collective view of all commenters, not just the reviewer’s perspective.
  5. The NEP author can make revisions and request further reviews from the reviewers. However, if a proposal is in the review stage for more than two months, the moderator will automatically reject it. To reopen the proposal, the author must restart the NEP process again.
  6. Once both reviewers complete their technical summary, the moderators will notify the approvers (working group members) that the NEP is in the final comment period. The approvers must fully review the NEP within one week. Approver guidelines:
    • First, read the NEP thoroughly. If you have feedback, explicitly tag the author and comment: "As a working group member, I request from @author-username to [ask clarifying questions, request changes, or provide actionable suggestions.]."
    • Second, once the approver believes the NEP is close to the voting stage, explicitly comment with your voting indication: "As a working group member, I lean towards [approving OR rejecting] this NEP based on [provide reasoning]."
  7. Once all the approvers indicate their voting indication, the moderator will review the voting indication for a 2/3 majority:
    • If the votes lean toward rejection: The moderator will summarize the feedback and close the NEP.
    • If the votes lean toward approval: The moderator will schedule a public call (see NEP Communication) for the author to present the NEP and for the working group members to formalize the voting decision. If the working group members agree that the NEP is overall beneficial for the NEAR ecosystem and vote to approve it, then the proposal is considered accepted. After the call, the moderator will summarize the decision on the NEP.
  8. The NEP author or other assignees will complete action items from the call. For example, the author will finalize the “Changelog” section on the NEP, which summarizes the benefits and concerns for future reference.

Transferring NEP Ownership

While a NEP is worked on, it occasionally becomes necessary to transfer ownership of NEPs to a new author. In general, it is preferable to retain the original author as a co-author of the transferred NEP, but that is up to the original author. A good reason to transfer ownership is that the original author no longer has the time or interest in updating it or following through with the NEP process. A bad reason to transfer ownership is that the author does not agree with the direction of the NEP. One aim of the NEP process is to try to build consensus around a NEP, but if that is not possible, an author can submit a competing NEP.

If you are interested in assuming ownership of a NEP, you can also do this via pull request. Fork the NEP repository, modify the owner, and submit a pull request. In the PR description, tag the original author and provide a summary of the work that was previously done. Also clearly state the intent of the fork and the relationship of the new PR to the old one. For example: “Forked to address the remaining review comments in NEP # since the original author does not have time to address them.

What does a successful NEP look like?

Each NEP should be written in markdown format and follow the NEP-0000 template and include all the appropriate sections, which will make it easier for the NEP reviewers and community members to understand and provide feedback. The most successful NEPs are those that go through collective iteration, with authors who actively seek feedback and support from the community. Ultimately, a successful NEP is one that addresses a specific problem or needs within the NEAR ecosystem, is well-researched, and has the support of the community and ecosystem experts.

Auxiliary Files

Images, diagrams, and auxiliary files should be included in a subdirectory of the assets folder for that NEP as follows: assets/nep-N (where N is to be replaced with the NEP number). When linking to an image in the NEP, use relative links such as ../assets/nep-1/image.png

Style Guide

NEP numbers

When referring to a NEP by number, it should be written in the hyphenated form NEP-X where X is the NEP’s assigned number.

RFC 2119

NEPs are encouraged to follow RFC 2119 for terminology and to insert the following at the beginning of the Specification section:

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

NEP Maintenance

Generally, NEPs are not modifiable after reaching their final state. However, there are occasions when updating a NEP is necessary, such as when discovering a security vulnerability or identifying misalignment with a widely-used implementation. In such cases, an author may submit a NEP extension in a pull request with the proposed changes to an existing NEP document.

A NEP extension has a higher chance of approval if it introduces clear benefits to existing implementors and does not introduce breaking changes.

If an author believes that a new extension meets the criteria for its own separate NEP, it is better to submit a new NEP than to modify an existing one. Just make sure to specify any dependencies on certain NEPs.

References

The content of this document was derived heavily from the PEP, BIP, Rust RFC, and EIP standards bootstrap documents:

Copyright and related rights waived via CC0.