NEP-141：NEAR 网络上的代币标准

LeeMaimai

/2025年10月16日

要点总结

• NEP-141 是 NEAR 上的同质化代币标准，提供核心转账、存储管理和元数据功能。

• NEP-141 通过异步调用和退款机制增强了跨合约交互的安全性。

• 遵循 NEP-141 标准的代币能够无缝集成到 NEAR 生态系统中的各种应用和工具。

• 开发者应重视存储质押和元数据标准，以提高合约的安全性和可发现性。

• 随着 NEAR 生态系统的发展，遵守 NEP-141 标准将确保代币的可移植性和未来兼容性。

同质化代币（Fungible Tokens, FT）是大多数 Web3 体验的基础，从稳定币、DeFi 流动性提供者（LP）份额，到激励积分和支付渠道，无一不依赖于它们。在 NEAR 上，同质化代币通过 NEP-141 实现——这是定义代币合约如何铸造、转移和记录网络中余额的标准。本文将介绍 NEP-141 是什么，它与以太坊上熟悉的标准有何不同，以及开发者和用户在 2025 年需要了解的内容。

什么是 NEP-141？

NEP-141 是 NEAR 上的同质化代币（FT）标准。它规定了每个 FT 合约应实现的最小接口和行为，包括：

核心转账功能
存储管理
代币元数据
跨合约转账语义和退款机制

官方规范发布在 NEAR 改进提案（NEAR Improvement Proposals）的仓库中，是实现者最权威的信息来源。请查阅 NEAR GitHub 上的标准及相关规范：

NEP-141 同质化代币标准（方法、回调、解析逻辑）— FungibleToken.md
代币元数据（名称、符号、小数位数、图标等）— FungibleTokenMetadata.md
存储管理（账户注册和质押）— Storage.md
事件/日志约定 — Events.md

了解 NEAR 及其当前路线图的背景信息，请访问官方网站和博客：

NEAR Protocol — near.org
最新的生态系统更新和技术深度解析 — NEAR Blog

NEP-141 的重要性

钱包和 dApp 的一致性集成：遵循标准意味着代币在所有地方都能「正常工作」，从 NEAR Explorer 这样的浏览器到 Ref Finance 等 DeFi 应用。
跨合约调用的可预测行为：NEAR 的异步模型使得跨合约转账功能强大但复杂；NEP-141 统一了回调和退款语义。
存储感知的记账：NEAR 要求账户支付其使用的存储费用。NEP-141 集成了存储质押和余额注册，以确保合约的安全性和效率。
生态系统可组合性：基于标准的代币能够与跨链桥、索引器和工具实现清晰的集成，例如 Rainbow Bridge 或 Rust 合约库。

NEP-141 与 ERC-20 的区别

尽管 NEP-141 和 ERC-20 在概念上是一致的，但它们在架构上存在重要差异：

异步调用和退款：NEAR 的跨合约调用是异步的。NEP-141 的 ft_transfer_call 会调用接收方的 ft_on_transfer，然后是一个「解析」回调，以便将未使用的代币退还给发送方。这与 ERC-20 通常的同步流程形成对比。有关「解析」机制的更多信息，请参阅标准 — FungibleToken.md。
默认不采用「approve/transferFrom」模式：NEP-141 倾向于使用 ft_transfer_call 和显式的接收方逻辑，而不是全局的授权系统。这降低了基于授权的攻击面，并更好地契合 NEAR 的基于 Promise 的执行模型。
存储质押：用户通常需要通过质押少量 NEAR 来「注册」代币合约的账户，以覆盖存储费用。这在存储标准 — Storage.md 中得到了正式化。
事件日志：NEAR 使用标准日志格式，而非 EVM 事件。事件标准描述了如何发出结构化日志，供索引器解析 — Events.md。

这些差异反映了 NEAR 在设计上对可扩展、异步执行和低费用的侧重，同时保证了开发者的易用性和用户的安全。

NEP-141 接口概览

典型的面向用户的函数：

ft_transfer(receiver_id, amount, memo?): 将代币转账给其他账户。
ft_transfer_call(receiver_id, amount, memo?, msg): 转账代币并调用接收方合约的逻辑；未使用的代币将被退还。
ft_balance_of(account_id): 查询余额。
ft_total_supply(): 查询总供应量。
ft_metadata(): 读取元数据（名称、符号、小数位数、图标、参考哈希）。
与存储相关的函数：storage_deposit、storage_balance_of、storage_withdraw（来自存储标准）。

接收方合约要求：

ft_on_transfer(sender_id, amount, msg) -> String: 返回接收方未使用的代币数量（用于退还给发送方）。代币合约稍后会调用其自身的解析器来完成转账并处理退款。

如果您使用 Rust 开发，请利用官方库：

near-sdk（合约框架）— docs.rs/near-sdk
near-contract-standards（现成的 FT 实现）— docs.rs/near-contract-standards

Rust 中的最小 FT 模式（near-contract-standards）

以下是一个简化的示例；生产环境的合约应依赖 near_contract_standards::fungible_token 并实现存储和事件标准。

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
    }

    // 通过委托给 `ft` 来暴露 NEP-141 方法（transfer, transfer_call, balance_of 等）
}

使用存储管理助手，以便用户可以注册账户，并且您可以准确跟踪存储使用情况。根据事件标准实现结构化日志，以供索引器使用。

代币合约的最佳实践

强制执行正确的存储质押：在转账和铸币给新账户之前要求 storage_deposit，以避免状态膨胀和极端情况 — Storage.md。
遵循元数据和事件标准：完整的元数据和结构化日志可提高可发现性和分析能力 — FungibleTokenMetadata.md, Events.md。
谨慎使用 ft_transfer_call：将接收方的逻辑视为不可信。验证金额，通过解析器处理退款，并避免不安全的假设 — FungibleToken.md。
使用 128 位整数存储余额并保持小数位数一致：NEAR 通常使用 24 位小数；请在元数据中清晰记录您的选择。
发出人类可读且机器可解析的日志：索引器和分析工具依赖于标准化日志；请勿自行创建日志格式。
提供清晰的管理员函数和访问控制：铸币、暂停和升级应透明且可审计。

2025 年的生态系统影响

NEP-141 为 NEAR 上各种资产提供支持，包括主要的稳定币。例如，Tether 在 NEAR 上集成了 USDT，为 DeFi 用户提供了更好的结算选项和流动性 — Tether launches USDT on NEAR。代币通过 Rainbow Bridge 等跨链桥在不同生态系统之间流动，并在 Ref Finance 等交易平台进行交易。

在协议层面，NEAR 通过 Chain Signatures 等举措，持续推进链抽象和多链用户体验，这些举措旨在简化跨链交互和密钥管理。您可以在官方博客 — NEAR Blog 和关于链抽象的深度解析 — Chain Signatures 上关注最新的发布和技术更新。

对于开发者而言，这意味着 NEP-141 代币将越来越多地参与跨链流动、移动端友好型入驻以及通过 NEAR 生态系统的前端可组合性。现在遵守标准将确保您的资产在这些功能扩展时保持兼容性。

钱包和 dApp 的集成技巧

在 UI 中处理存储流程：在首次转账或兑换前，提示用户使用 storage_deposit 进行注册。
同时支持 ft_transfer 和 ft_transfer_call：许多 dApp 使用后者来执行原子操作和退款。
清晰显示元数据：使用小数位数正确格式化余额；在可用时显示图标和参考哈希。
解析标准化日志：索引 NEP-141 事件以支持通知、分析和历史视图。

用户可以通过 NEAR Explorer 跟踪代币余额和转账，dApp 可以使用 NEAR NEPs 仓库中的官方规范 — NEPs on GitHub 来检查合约或验证部署。

托管和安全

NEAR 的低费用和快速最终性使其非常适合频繁转账，但托管仍然至关重要。如果您持有大量 NEP-141 代币或与 DeFi 交互，请考虑将密钥转移到离线硬件钱包，以进行交易验证并降低网络钓鱼风险。OneKey 提供设备内确认和多链支持，有助于确保在关键操作中批准的是预期的 ft_transfer 或 ft_transfer_call 参数。对于活跃的 NEAR 用户来说，将硬件钱包与合理的账户权限和经过审计的 dApp 配对，可以显著降低您的攻击面。

主要亮点

NEP-141 是 NEAR 上权威的 FT 标准，将转账、存储质押、元数据和事件日志整合到一个可组合的接口中 — FungibleToken.md。
异步模型和退款语义提供了比基于授权模式更安全的跨合约交互。
实现存储和元数据标准；为索引器发出结构化日志。
符合 NEP-141 标准的代币可在 NEAR 不断增长的生态系统中无缝集成到跨链桥、钱包和 DeFi 应用中 — Rainbow Bridge, Ref Finance, NEAR Explorer。
随着 NEAR 在 2025 年不断发展其链抽象和用户入驻能力，遵守标准将确保您的代币保持可移植性和面向未来 — NEAR Blog, Chain Signatures。