NEP-141：NEAR 網路的代幣標準

可替代代幣（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 的基於承諾的執行模型相符。
• 儲存存款：用戶通常需要透過存入少量 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](https://onekey.so/blog/zh-HK/ecosystem/what-is-a-smart-contract/)-standards (現成的 FT 實施) — docs.rs/near-contract-standards

Rust 中的最小 FT 模式（near-[contract](https://onekey.so/blog/zh-HK/ecosystem/what-is-a-smart-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 方法（轉移、轉移呼叫、餘額查詢等）
}

請使用儲存管理助手，以便用戶可以註冊帳戶，並且您可以準確追蹤儲存使用量。根據事件標準實施結構化日誌，供索引器使用。

代幣合約的最佳實踐

• 強制執行適當的儲存存款：在轉移和鑄造給新帳戶之前，要求進行 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。

無論您是發行新資產還是持有現有的 NEP-141 代幣，都應將標準視為您的藍圖——然後在其之上疊加強健的安全性和清晰的用戶體驗。