NEP-141: The token standard for the NEAR network

Fungible tokens are the backbone of most web3 experiences, from stablecoins and DeFi LP shares to incentive points and payment rails. On NEAR, fungible tokens are implemented via NEP-141—the canonical token standard that defines how contracts should mint, transfer, and account for balances across the network. This guide explains what NEP-141 is, how it differs from familiar Ethereum standards, and what developers and users should know in 2025.

What is NEP-141?

NEP-141 is the fungible token (FT) standard for NEAR. It specifies the minimal interface and behaviors every FT contract should implement, including:

• Core transfer methods
• Storage management
• Token metadata
• Cross-contract transfer semantics and refunds

The official specification is published in the NEAR Improvement Proposals repository and is the best single source of truth for implementers. See the standard and companion specs on the NEAR GitHub:

• NEP-141 Fungible Token standard (methods, callbacks, resolve logic) — FungibleToken.md
• Token metadata (name, symbol, decimals, icon, etc.) — FungibleTokenMetadata.md
• Storage management (account registration and deposits) — Storage.md
• Event/logging conventions — Events.md

For context about NEAR and its current roadmap, check the official site and blog:

• NEAR Protocol — near.org
• Latest ecosystem updates and technical deep dives — NEAR Blog

Why NEP-141 matters

• Consistent integration across wallets and dApps: Compliance ensures tokens “just work” everywhere—from explorers like NEAR Explorer to DeFi apps such as Ref Finance.
• Predictable behavior for cross-contract calls: NEAR’s asynchronous model makes cross-contract transfers powerful but tricky; NEP-141 standardizes callbacks and refund semantics.
• Storage-aware accounting: NEAR requires accounts to pay for the storage they use. NEP-141 integrates storage deposits and balance registration so contracts stay secure and efficient.
• Ecosystem composability: Standards-based tokens enable clean integrations with bridges, indexers, and tooling, e.g., the Rainbow Bridge or Rust contract libraries.

How NEP-141 differs from ERC-20

While NEP-141 and ERC-20 are conceptually aligned, there are important architectural differences:

• Asynchronous calls and refunds: NEAR’s cross-contract calls are asynchronous. NEP-141’s ft_transfer_call invokes the receiver’s ft_on_transfer and then a “resolve” callback so unused tokens can be refunded to the sender. This contrasts with the synchronous flow typical of ERC-20. See the “resolve” mechanics in the standard — FungibleToken.md.
• No “approve/transferFrom” pattern by default: NEP-141 leans on ft_transfer_call and explicit receiver logic rather than a global allowance system. This reduces approval-based attack surface and aligns better with NEAR’s promise-based execution.
• Storage deposits: Users must often “register” accounts on the token contract by depositing a small amount of NEAR to cover storage. This is formalized in the Storage standard — Storage.md.
• Event logging: NEAR uses standard log formats rather than EVM events. The Event standard describes how to emit structured logs that indexers can parse — Events.md.

These differences reflect NEAR’s design focus on scalable, asynchronous execution and low fees, while preserving developer ergonomics and user safety.

The NEP-141 interface at a glance

Typical user-facing methods:

• ft_transfer(receiver_id, amount, memo?): Transfer tokens to another account.
• ft_transfer_call(receiver_id, amount, memo?, msg): Transfer tokens and call the receiver’s contract logic; unused tokens are refunded.
• ft_balance_of(account_id): Query balance.
• ft_total_supply(): Query total supply.
• ft_metadata(): Read metadata (name, symbol, decimals, icon, reference hash).
• Storage-related: storage_deposit, storage_balance_of, storage_withdraw (from the Storage standard).

Receiver contract requirements:

• ft_on_transfer(sender_id, amount, msg) -> String: Returns the amount of tokens the receiver did not use (to be refunded to the sender). The token contract later calls its own resolver to finalize the transfer and handle refunds.

If you’re building in Rust, use the canonical libraries:

• near-sdk (contract framework) — docs.rs/near-sdk
• near-contract-standards (ready-made FT implementation) — docs.rs/near-contract-standards

Minimal FT pattern in Rust (near-contract-standards)

Below is a simplified sketch; production contracts should rely on near_contract_standards::fungible_token and implement storage and event standards.

use near_contract_standards::fungible_token::FungibleToken;
use near_contract_standards::fungible_token::metadata::{FungibleTokenMetadata, FT_METADATA_SPEC};
use near_sdk::{near_bindgen, AccountId, PanicOnDefault, BorshDeserialize, BorshSerialize};

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault)]
pub struct Token {
    pub ft: FungibleToken,
    pub metadata: FungibleTokenMetadata,
}

#[near_bindgen]
impl Token {
    #[init]
    pub fn new(owner_id: AccountId, total_supply: near_sdk::json_types::U128) -> Self {
        let mut this = Self {
            ft: FungibleToken::new(b"t".to_vec()),
            metadata: FungibleTokenMetadata {
                spec: FT_METADATA_SPEC.to_string(),
                name: "Example Token".to_string(),
                symbol: "EXT".to_string(),
                icon: None,
                reference: None,
                reference_hash: None,
                decimals: 24,
            },
        };
        this.ft.internal_register_account(&owner_id);
        this.ft.internal_deposit(&owner_id, total_supply.0);
        this
    }

    // Expose NEP-141 methods by delegating to `ft` (transfer, transfer_call, balance_of, etc.)
}

Use the storage management helpers so users can register accounts and you can track storage usage accurately. Implement structured logs according to the Event standard for indexers.

Best practices for token contracts

• Enforce proper storage deposits: Require storage_deposit before transfers and minting to new accounts to avoid state bloat and edge cases — Storage.md.
• Follow metadata and event standards: Complete metadata and structured logs improve discoverability and analytics — FungibleTokenMetadata.md, Events.md.
• Use ft_transfer_call carefully: Treat receiver logic as untrusted. Validate amounts, handle refunds via the resolver, and avoid unsafe assumptions — FungibleToken.md.
• Keep balances in 128-bit integers and decimals consistent: NEAR commonly uses 24 decimals; document your choice clearly in metadata.
• Emit human-readable and machine-parseable logs: Indexers and analytics rely on standardized logs; don’t roll your own format.
• Provide clear admin methods with access control: Minting, pausing, and upgrading should be transparent and auditable.

The ecosystem impact in 2025

NEP-141 powers a diverse set of assets on NEAR, including major stablecoins. For example, Tether integrated USDT on NEAR, improving settlement options and liquidity for DeFi users — Tether launches USDT on NEAR. Tokens flow across ecosystems via bridges like the Rainbow Bridge, and trade on venues such as Ref Finance.

On the protocol side, NEAR continues advancing chain abstraction and multi-chain user experiences, prominently through initiatives like Chain Signatures—which aim to simplify cross-chain interactions and key management. You can follow ongoing releases and technical updates on the official blog — NEAR Blog and the deep dive on chain abstraction — Chain Signatures.

For builders, this means NEP-141 tokens increasingly participate in cross-chain flows, mobile-friendly onboarding, and front-end composability via the NEAR ecosystem’s developer stack. Adhering to standards now ensures your assets remain compatible as these capabilities expand.

Integration tips for wallets and dApps

• Handle storage flows in the UI: Prompt users to register with storage_deposit before first transfers or swaps.
• Support both ft_transfer and ft_transfer_call: Many dApps use the latter to perform atomic operations and refunds.
• Display metadata cleanly: Use decimals to format balances correctly; show icons and reference hashes where available.
• Parse standardized logs: Index NEP-141 events to power notifications, analytics, and historical views.

Users can track token balances and transfers via NEAR Explorer, and dApps can inspect contracts or verify deployments using the official specifications in the NEAR NEPs repo — NEPs on GitHub.

Custody and security

NEAR’s low fees and fast finality make it convenient for frequent transfers, but custody remains critical. If you hold significant NEP-141 tokens or interact with DeFi, consider moving keys to an offline hardware wallet for transaction verification and reduced phishing risk. OneKey provides on-device confirmations and multi-chain support, which helps ensure you are approving the intended ft_transfer or ft_transfer_call parameters during critical operations. For active NEAR users, pairing a hardware wallet with sensible account permissions and audited dApps can materially lower your attack surface.

Key takeaways

• NEP-141 is the authoritative FT standard on NEAR, combining transfers, storage deposits, metadata, and event logging into a composable interface — FungibleToken.md.
• The asynchronous model and refund semantics provide safer cross-contract interactions than approval-based patterns.
• Implement storage and metadata standards; emit structured logs for indexers.
• Tokens adhering to NEP-141 integrate seamlessly across bridges, wallets, and DeFi apps in NEAR’s growing ecosystem — Rainbow Bridge, Ref Finance, NEAR Explorer.
• As NEAR evolves its chain abstraction and user onboarding in 2025, standards compliance ensures your tokens remain portable and future-proof — NEAR Blog, Chain Signatures.

Whether you’re issuing a new asset or holding existing NEP-141 tokens, treat the standard as your blueprint—then layer robust security and clear UX on top.