What are NEPs?
What NEPs (NEAR Enhancement Proposals) are, how a NEAR standard is proposed and finalised, how to read one, and how they map to Ethereum ERCs and EIPs.
Beginner4 min read3-question check
A NEP — NEAR Enhancement Proposal — is a numbered design document that describes a change to NEAR: a new protocol feature, a smart-contract interface, or a wallet API. When people say “NEP-141 token” they mean a contract that implements the interface written down in proposal number 141.
Standards are what make a token show up correctly in every wallet, explorer and DEX without anyone writing custom code for it. A wallet does not know your contract — it only knows that anything implementing NEP-141 has ft_balance_of, ft_transfer and ft_metadata, so it calls those.
All NEPs live in github.com/near/NEPs (the neps/ folder holds one markdown file per proposal), and the contract standards are also published in readable form at nomicon.io/Standards.
| Category | What it covers | Examples |
|---|---|---|
| Protocol | Changes to nearcore itself — new actions, fees, runtime behaviour. Validators must upgrade. | NEP-366 meta transactions |
| Contract standards | Interfaces that contracts implement so other contracts and apps can talk to them. No protocol change needed. | NEP-141, NEP-171, NEP-245, NEP-297 |
| Wallet standards | APIs between dApps and wallets. | NEP-413 message signing |
How a standard becomes final#
- Idea — discussed publicly (forum or a GitHub issue) to see whether anyone else needs it.
- Draft — the author opens a pull request against
near/NEPsusing the NEP template; a moderator checks formatting and assigns a number (usually the PR number). - Review — subject-matter experts and the relevant working group (a small committee of recognised experts, e.g. the Contract Standards or Protocol working group) review it. Normative changes happen here.
- Voting — the working group votes in a public call. The outcome is approved (Final) or rejected.
- Final — the document is frozen apart from errata and non-normative clarifications. New behaviour arrives as a versioned extension (that is why events carry a
versionlike1.2.0).
How to read a NEP#
- Header — number, title, authors, status (Draft / Review / Final…), category, version, and creation/update dates. Check the status before relying on it.
- Summary and Motivation — the problem being solved. Skim these first.
- Specification — the normative part. Words like MUST, SHOULD and MAY carry their RFC meanings; method signatures are written TypeScript-style with JSON types (
stringfor 128-bit numbers,nullfor optional). - Reference implementation — usually points at
near-contract-standards(Rust) or an example contract. This is where you copy from. - Security implications, Alternatives, Changelog — the changelog tells you what each version added, which matters when a standard has extensions.
# token metadata (NEP-148)
near view wrap.near ft_metadata '{}'
# a balance (NEP-141) — amounts come back as strings
near view wrap.near ft_balance_of '{"account_id": "alice.near"}'
# which standards does a contract claim to implement? (NEP-330, if supported)
near view some-contract.near contract_source_metadata '{}'Check yourself
3 questions · progress saved in this browser