NEP-141: Der Token-Standard für das NEAR-Netzwerk

Fungible Token (austauschbare Token) bilden das Rückgrat der meisten Web3-Erfahrungen, von Stablecoins und DeFi-LP-Anteilen bis hin zu Anreizpunkten und Zahlungssystemen. Auf NEAR werden fungible Token über NEP-141 implementiert – dem kanonischen Token-Standard, der definiert, wie Verträge Guthaben im Netzwerk prägen, übertragen und verwalten sollen. Dieser Leitfaden erklärt, was NEP-141 ist, wie es sich von bekannten Ethereum-Standards unterscheidet und was Entwickler und Benutzer im Jahr 2025 wissen sollten.

Was ist NEP-141?

NEP-141 ist der Standard für fungible Token (FT) für NEAR. Er gibt die minimale Schnittstelle und das Verhalten vor, das jeder FT-Vertrag implementieren sollte, einschließlich:

• Kernübertragungsmethoden
• Speicherverwaltung
• Token-Metadaten
• Semantik für vertragsübergreifende Übertragungen und Rückerstattungen

Die offizielle Spezifikation ist im NEAR Improvement Proposals-Repository veröffentlicht und die beste einzige Quelle der Wahrheit für Implementierer. Sehen Sie sich den Standard und die zugehörigen Spezifikationen auf GitHub von NEAR an:

• NEP-141 Fungible Token Standard (Methoden, Callbacks, Resolve-Logik) — FungibleToken.md
• Token-Metadaten (Name, Symbol, Dezimalstellen, Icon usw.) — FungibleTokenMetadata.md
• Speicherverwaltung (Account-Registrierung und Einzahlungen) — Storage.md
• Konventionen für Ereignisse/Protokollierung — Events.md

Kontext zu NEAR und seiner aktuellen Roadmap finden Sie auf der offiziellen Website und im Blog:

• NEAR Protocol — near.org
• Neueste Ökosystem-Updates und technische Deep Dives — NEAR Blog

Warum NEP-141 wichtig ist

• Konsistente Integration über Wallets und dApps hinweg: Die Konformität stellt sicher, dass Token überall "einfach funktionieren" – von Exploorern wie NEAR Explorer bis hin zu DeFi-Apps wie Ref Finance.
• Vorhersehbares Verhalten für vertragsübergreifende Aufrufe: NEARs asynchrones Modell macht vertragsübergreifende Übertragungen leistungsfähig, aber knifflig; NEP-141 standardisiert Callbacks und Rückerstattungssemantik.
• Speicherbewusste Buchhaltung: NEAR verlangt von Konten, dass sie den von ihnen genutzten Speicher bezahlen. NEP-141 integriert Speichergebühren und Guthabenregistrierung, damit Verträge sicher und effizient bleiben.
• Ökosystem-Komposabilität: Standardbasierte Token ermöglichen saubere Integrationen mit Bridges, Indexern und Tools, z. B. der Rainbow Bridge oder Rust-Vertragsbibliotheken.

Wie sich NEP-141 von ERC-20 unterscheidet

Während NEP-141 und ERC-20 konzeptionell aufeinander abgestimmt sind, gibt es wichtige architektonische Unterschiede:

• Asynchrone Aufrufe und Rückerstattungen: NEARs vertragsübergreifende Aufrufe sind asynchron. NEP-141s ft_transfer_call ruft den ft_on_transfer des Empfängers und dann einen "Resolve"-Callback auf, damit nicht verwendete Token an den Absender zurückerstattet werden können. Dies steht im Gegensatz zum synchronen Fluss, der typisch für ERC-20 ist. Sehen Sie sich die "Resolve"-Mechanismen im Standard an — FungibleToken.md.
• Kein "approve/transferFrom"-Muster als Standard: NEP-141 setzt auf ft_transfer_call und explizite Empfängerlogik anstelle eines globalen Berechtigungssystems. Dies reduziert die Angriffsfläche, die auf Genehmigungen basiert, und passt besser zur promise-basierten Ausführung von NEAR.
• Speichergebühren: Benutzer müssen Konten oft beim Token-Vertrag "registrieren", indem sie einen kleinen Betrag NEAR einzahlen, um den Speicher abzudecken. Dies ist im Storage-Standard formalisiert — Storage.md.
• Ereignisprotokollierung: NEAR verwendet Standard-Protokollformate anstelle von EVM-Ereignissen. Der Event-Standard beschreibt, wie strukturierte Protokolle ausgegeben werden, die von Indexern analysiert werden können — Events.md.

Diese Unterschiede spiegeln NEARs Designfokus auf skalierbare, asynchrone Ausführung und niedrige Gebühren wider, während die Benutzerfreundlichkeit für Entwickler und die Sicherheit für Benutzer erhalten bleiben.

Die NEP-141-Schnittstelle im Überblick

Typische benutzerorientierte Methoden:

• ft_transfer(receiver_id, amount, memo?): Überweist Token an ein anderes Konto.
• ft_transfer_call(receiver_id, amount, memo?, msg): Überweist Token und ruft die Vertragslogik des Empfängers auf; nicht verwendete Token werden zurückerstattet.
• ft_balance_of(account_id): Guthaben abfragen.
• ft_total_supply(): Gesamtemission abfragen.
• ft_metadata(): Metadaten lesen (Name, Symbol, Dezimalstellen, Icon, Referenz-Hash).
• Speicherbezogen: storage_deposit, storage_balance_of, storage_withdraw (aus dem Storage-Standard).

Anforderungen an den Empfängervertrag:

• ft_on_transfer(sender_id, amount, msg) -> String: Gibt die Menge der nicht verwendeten Token zurück (die dem Absender zurückerstattet werden). Der Token-Vertrag ruft später seinen eigenen Resolver auf, um die Übertragung abzuschließen und Rückerstattungen zu bearbeiten.

Wenn Sie in Rust entwickeln, verwenden Sie die kanonischen Bibliotheken:

• near-sdk (Contract-Framework) — docs.rs/near-sdk
• near-contract-standards (fertige FT-Implementierung) — docs.rs/near-contract-standards

Minimales FT-Muster in Rust (near-contract-standards)

Unten ist ein vereinfachter Entwurf; Produktionsverträge sollten sich auf near_contract_standards::fungible_token verlassen und Speicher- und Standard-Ereignisprotokolle implementieren.

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: "Beispiel-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
    }

    // NEP-141-Methoden durch Delegation an `ft` (transfer, transfer_call, balance_of etc.) verfügbar machen
}

Verwenden Sie die Hilfsmittel für die Speicherverwaltung, damit Benutzer Konten registrieren können und Sie die Speichernutzung genau verfolgen können. Implementieren Sie strukturierte Protokolle gemäß dem Event-Standard für Indexer.

Best Practices für Token-Verträge

• Erzwingen Sie ordnungsgemäße Speichergebühren: Verlangen Sie storage_deposit vor Überweisungen und der Prägung für neue Konten, um State Bloat und Grenzfälle zu vermeiden — Storage.md.
• Befolgen Sie die Metadaten- und Event-Standards: Vollständige Metadaten und strukturierte Protokolle verbessern Auffindbarkeit und Analysen — FungibleTokenMetadata.md, Events.md.
• Verwenden Sie ft_transfer_call sorgfältig: Behandeln Sie die Empfängerlogik als nicht vertrauenswürdig. Validieren Sie Beträge, behandeln Sie Rückerstattungen über den Resolver und vermeiden Sie unsichere Annahmen — FungibleToken.md.
• Halten Sie Guthaben in 128-Bit-Ganzzahlen und Dezimalstellen konsistent: NEAR verwendet üblicherweise 24 Dezimalstellen; dokumentieren Sie Ihre Wahl klar in den Metadaten.
• Geben Sie menschenlesbare und maschinenlesbare Protokolle aus: Indexer und Analysen sind auf standardisierte Protokolle angewiesen; erfinden Sie kein eigenes Format.
• Stellen Sie klare Admin-Methoden mit Zugriffssteuerung bereit: Prägung, Aussetzung und Upgrades sollten transparent und überprüfbar sein.

Ökosystem-Auswirkungen im Jahr 2025

NEP-141 treibt eine vielfältige Palette von Vermögenswerten auf NEAR an, darunter wichtige Stablecoins. Tether hat beispielsweise USDT auf NEAR integriert, was die Abwicklungsoptionen und die Liquidität für DeFi-Nutzer verbessert — Tether startet USDT auf NEAR. Token fließen über Bridges wie die Rainbow Bridge zwischen den Ökosystemen und werden an Handelsplätzen wie Ref Finance gehandelt.

Auf der Protokollseite treibt NEAR weiterhin die Kettenabstraktion und Multi-Chain-Benutzererlebnisse voran, insbesondere durch Initiativen wie Chain Signatures, die darauf abzielen, kettenübergreifende Interaktionen und die Schlüsselverwaltung zu vereinfachen. Sie können laufende Veröffentlichungen und technische Aktualisierungen im offiziellen Blog — NEAR Blog und im Deep Dive zur Kettenabstraktion — Chain Signatures verfolgen.

Für Entwickler bedeutet dies, dass NEP-141-Token zunehmend an kettenübergreifenden Flows, mobilerfreundlichem Onboarding und Frontend-Komposabilität über den Entwicklerstack des NEAR-Ökosystems teilnehmen. Die Einhaltung von Standards stellt nun sicher, dass Ihre Vermögenswerte kompatibel bleiben, wenn sich diese Fähigkeiten erweitern.

Integrationstipps für Wallets und dApps

• Behandeln Sie Speicherflüsse in der Benutzeroberfläche: Fordern Sie Benutzer auf, sich mit storage_deposit zu registrieren, bevor sie erste Überweisungen oder Swaps durchführen.
• Unterstützen Sie sowohl ft_transfer als auch ft_transfer_call: Viele dApps verwenden letztere für atomare Operationen und Rückerstattungen.
• Zeigen Sie Metadaten sauber an: Verwenden Sie Dezimalstellen zur korrekten Formatierung von Guthaben; zeigen Sie Icons und Referenz-Hashes an, wo verfügbar.
• Analysieren Sie standardisierte Protokolle: Indexieren Sie NEP-141-Ereignisse, um Benachrichtigungen, Analysen und historische Ansichten zu ermöglichen.

Benutzer können Token-Guthaben und Überweisungen über NEAR Explorer verfolgen, und dApps können Verträge inspizieren oder Bereitstellungen mit den offiziellen Spezifikationen im NEAR NEPs-Repo überprüfen — NEPs auf GitHub.

Verwahrung und Sicherheit

NEARs niedrige Gebühren und schnelle Finalität machen es bequem für häufige Überweisungen, aber die Verwahrung bleibt entscheidend. Wenn Sie erhebliche NEP-141-Token halten oder mit DeFi interagieren, sollten Sie Ihre Schlüssel auf eine Offline-Hardware-Wallet verschieben, um Transaktionen zu überprüfen und das Phishing-Risiko zu verringern. OneKey bietet Bestätigungen auf dem Gerät und Multi-Chain-Unterstützung, was dazu beiträgt, sicherzustellen, dass Sie die beabsichtigten ft_transfer- oder ft_transfer_call-Parameter während kritischer Operationen genehmigen. Für aktive NEAR-Nutzer kann die Kombination einer Hardware-Wallet mit vernünftigen Konto-Berechtigungen und geprüften dApps Ihre Angriffsfläche erheblich reduzieren.

Wichtige Erkenntnisse

• NEP-141 ist der maßgebliche FT-Standard auf NEAR und vereint Überweisungen, Speichergebühren, Metadaten und Ereignisprotokollierung in einer zusammensetzbaren Schnittstelle — FungibleToken.md.
• Das asynchrone Modell und die Rückerstattungssemantik bieten sicherere vertragsübergreifende Interaktionen als genehmigungsbasierte Muster.
• Implementieren Sie Speicher- und Metadatenstandards; geben Sie strukturierte Protokolle für Indexer aus.
• Token, die NEP-141 einhalten, lassen sich nahtlos in Bridges, Wallets und DeFi-Apps im wachsenden NEAR-Ökosystem integrieren — Rainbow Bridge, Ref Finance, NEAR Explorer.
• Während NEAR 2025 seine Kettenabstraktion und das Benutzer-Onboarding weiterentwickelt, stellt die Einhaltung von Standards sicher, dass Ihre Token portabel und zukunftssicher bleiben — NEAR Blog, Chain Signatures.

Ob Sie ein neues Asset ausgeben oder bestehende NEP-141-Token halten, behandeln Sie den Standard als Ihre Blaupause – und fügen Sie dann robuste Sicherheit und eine klare Benutzererfahrung hinzu.