NEP-141: NEARネットワークのトークン標準

LeeMaimaiLeeMaimai
/2025年10月16日
NEP-141: NEARネットワークのトークン標準

キーストーン

• NEP-141はNEARの公式FT標準で、トークンの転送やストレージデポジットを統合しています。

• 非同期モデルと返金セマンティクスにより、安全なクロスコントラクトインタラクションを提供します。

• ストレージとメタデータ標準を実装し、インデクサー向けに構造化されたログを発行することが重要です。

• NEP-141に準拠したトークンは、NEARエコシステム内のブリッジやDeFiアプリとシームレスに統合されます。

• NEARが2025年に向けてチェーン抽象化を進める中、標準への準拠はトークンのポータビリティを確保します。

代替可能トークン(Fungible Tokens: FT)は、ステーブルコイン、DeFiのLPトークン、インセンティブポイント、決済手段など、ほとんどのWeb3体験の基盤となっています。NEARでは、FTはNEP-141、すなわちトークン発行(ミント)、移転、ネットワーク全体での残高管理方法を定義する標準規格によって実装されています。この記事では、NEP-141とは何か、おなじみのEthereumの標準規格とどう違うのか、そして2025年に開発者やユーザーが知っておくべきことについて解説します。

NEP-141とは?

NEP-141はNEARの代替可能トークン(FT)標準です。これは、すべてのFTコントラクトが実装すべき最小限のインターフェースと動作を指定します。これには以下が含まれます:

  • コアとなる転送メソッド
  • ストレージ管理
  • トークンメタデータ
  • クロスコントラクト転送のセマンティクスと返金

公式仕様は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を呼び出し、その後「解決(resolve)」コールバックを呼び出すことで、未使用のトークンを送信者に返金できるようにします。これは、ERC-20で一般的な同期フローとは対照的です。標準における「解決」の仕組みについては、FungibleToken.mdを参照してください。
  • デフォルトでの「approve/transferFrom」パターンなし:NEP-141は、グローバルな許可システムではなく、ft_transfer_callと明示的な受信者ロジックに依存しています。これにより、承認ベースの攻撃対象領域が減少し、NEARのプロミスベース実行との親和性が高まります。
  • ストレージデポジット:ユーザーは、ストレージ料金をカバーするために少額のNEARをデポジットすることで、トークンコントラクトにアカウントを「登録」する必要がある場合があります。これは、Storage標準 — Storage.mdで正式化されています。
  • イベントログ:NEARはEVMイベントではなく、標準的なログ形式を使用します。Event標準は、インデクサーが解析できる構造化ログをどのように発行するかを説明しています — 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_depositstorage_balance_ofstorage_withdraw(Storage標準から)。

受信者コントラクトの要件:

  • ft_on_transfer(sender_id, amount, msg) -> String: 受信者が使用しなかったトークンの量(送信者に返金される)を返します。トークンコントラクトは後で自身のレゾルバーを呼び出し、転送を完了し返金処理を行います。

Rustで開発している場合は、公式ライブラリを使用してください。

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メソッドを公開(転送、転送呼び出し、残高照会など)
}

ストレージ管理ヘルパーを使用すると、ユーザーがアカウントを登録でき、ストレージ使用量を正確に追跡できます。インデクサーのためにイベント標準に従って構造化されたログを実装してください。

トークンコントラクトのベストプラクティス

  • 適切なストレージデポジットの強制:状態の肥大化とエッジケースを回避するために、新しいアカウントへの転送やミントの前にstorage_depositを要求してください — Storage.md
  • メタデータとイベント標準に従う:完全なメタデータと構造化されたログは、検出可能性と分析を向上させます — FungibleTokenMetadata.mdEvents.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_transferft_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 BridgeRef FinanceNEAR Explorer
  • NEARが2025年にチェーン抽象化とユーザーオンボーディングを進化させるにつれて、標準への準拠はトークンのポータビリティと将来性を確保します — NEAR BlogChain Signatures

新しいアセットを発行する場合でも、既存のNEP-141トークンを保持する場合でも、標準をブループリントとして扱い、その上に堅牢なセキュリティと明確なUXを構築してください。

OneKeyで暗号化の旅を守る

View details for OneKeyのご購入OneKeyのご購入

OneKeyのご購入

世界最先端のハードウェアウォレット。

View details for アプリをダウンロードアプリをダウンロード

アプリをダウンロード

詐欺アラート。すべてのコインをサポート。

View details for OneKey SifuOneKey Sifu

OneKey Sifu

暗号化の疑問を解消するために、一つの電話で。

続きを読む