NEP-141 : La norme de token pour le réseau NEAR

Les tokens fongibles sont l'épine dorsale de la plupart des expériences web3, des stablecoins et des parts de liquidité DeFi aux points d'incitation et aux systèmes de paiement. Sur NEAR, les tokens fongibles sont implémentés via NEP-141, la norme de token canonique qui définit comment les contrats doivent émettre, transférer et comptabiliser les soldes sur l'ensemble du réseau. Ce guide explique ce qu'est NEP-141, en quoi il diffère des normes familières d'Ethereum, et ce que les développeurs et les utilisateurs devraient savoir en 2025.

Qu'est-ce que NEP-141 ?

NEP-141 est la norme de token fongible (FT) pour NEAR. Elle spécifie l'interface minimale et les comportements que chaque contrat FT doit implémenter, y compris :

• Méthodes de transfert principales
• Gestion du stockage
• Métadonnées des tokens
• Sémantique des transferts inter-contrats et remboursements

La spécification officielle est publiée dans le dépôt des Propositions d'Amélioration de NEAR (NEAR Improvement Proposals) et constitue la meilleure source de vérité unique pour les implémenteurs. Consultez la norme et les spécifications associées sur le GitHub de NEAR :

• Norme de Token Fongible NEP-141 (méthodes, callbacks, logique de résolution) — FungibleToken.md
• Métadonnées des tokens (nom, symbole, décimales, icône, etc.) — FungibleTokenMetadata.md
• Gestion du stockage (enregistrement de compte et dépôts) — Storage.md
• Conventions d'événements/journalisation — Events.md

Pour un contexte sur NEAR et sa feuille de route actuelle, consultez le site officiel et le blog :

• NEAR Protocol — near.org
• Dernières mises à jour de l'écosystème et analyses techniques approfondies — Blog NEAR

Pourquoi NEP-141 est important

• Intégration cohérente entre les portefeuilles et les dApps : La conformité garantit que les tokens "fonctionnent simplement" partout, des explorateurs comme NEAR Explorer aux applications DeFi telles que Ref Finance.
• Comportement prévisible pour les appels inter-contrats : Le modèle asynchrone de NEAR rend les transferts inter-contrats puissants mais délicats ; NEP-141 standardise les callbacks et la sémantique de remboursement.
• Comptabilité consciente du stockage : NEAR exige que les comptes paient le stockage qu'ils utilisent. NEP-141 intègre les dépôts de stockage et l'enregistrement des soldes afin que les contrats restent sécurisés et efficaces.
• Composabilité de l'écosystème : Les tokens basés sur des normes permettent des intégrations propres avec des ponts, des indexeurs et des outils, par exemple le Rainbow Bridge ou les bibliothèques de contrats Rust.

Comment NEP-141 diffère d'ERC-20

Bien que NEP-141 et ERC-20 soient conceptuellement alignés, il existe des différences architecturales importantes :

• Appels asynchrones et remboursements : Les appels inter-contrats de NEAR sont asynchrones. La méthode ft_transfer_call de NEP-141 invoque la méthode ft_on_transfer du destinataire, puis un callback de "résolution" pour que les tokens inutilisés puissent être remboursés à l'expéditeur. Ceci contraste avec le flux synchrone typique d'ERC-20. Consultez les mécanismes de "résolution" dans la norme — FungibleToken.md.
• Pas de modèle "approve/transferFrom" par défaut : NEP-141 s'appuie sur ft_transfer_call et une logique explicite du destinataire plutôt que sur un système d'autorisation globale. Cela réduit la surface d'attaque basée sur les autorisations et s'aligne mieux avec l'exécution basée sur les promesses de NEAR.
• Dépôts de stockage : Les utilisateurs doivent souvent "enregistrer" leurs comptes auprès du contrat de token en déposant une petite quantité de NEAR pour couvrir le stockage. Ceci est formalisé dans la norme de stockage — Storage.md.
• Journalisation des événements : NEAR utilise des formats de journal standardisés plutôt que des événements EVM. La norme d'événements décrit comment émettre des journaux structurés que les indexeurs peuvent analyser — Events.md.

Ces différences reflètent l'accent mis par NEAR sur l'exécution évolutive et asynchrone, ainsi que sur des frais réduits, tout en préservant l'ergonomie pour les développeurs et la sécurité des utilisateurs.

L'interface NEP-141 en un coup d'œil

Méthodes typiques orientées utilisateur :

• ft_transfer(receiver_id, amount, memo?): Transférer des tokens vers un autre compte.
• ft_transfer_call(receiver_id, amount, memo?, msg): Transférer des tokens et appeler la logique du contrat du destinataire ; les tokens inutilisés sont remboursés.
• ft_balance_of(account_id): Interroger le solde.
• ft_total_supply(): Interroger l'offre totale.
• ft_metadata(): Lire les métadonnées (nom, symbole, décimales, icône, hash de référence).
• Liés au stockage : storage_deposit, storage_balance_of, storage_withdraw (de la norme de stockage).

Exigences pour les contrats récepteurs :

• ft_on_transfer(sender_id, amount, msg) -> String: Retourne le montant des tokens que le récepteur n'a pas utilisés (à rembourser à l'expéditeur). Le contrat de token appelle ensuite son propre résolveur pour finaliser le transfert et gérer les remboursements.

Si vous développez en Rust, utilisez les bibliothèques canoniques :

• near-sdk (framework de contrat) — docs.rs/near-sdk
• near-contract-standards (implémentation FT prête à l'emploi) — docs.rs/near-contract-standards

Modèle FT minimal en Rust (near-contract-standards)

Voici une esquisse simplifiée ; les contrats de production doivent s'appuyer sur near_contract_standards::fungible_token et implémenter les normes de stockage et d'événements.

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

    // Exposer les méthodes NEP-141 en déléguant à `ft` (transfert, transfert_appel, solde_de, etc.)
}

Utilisez les assistants de gestion de stockage afin que les utilisateurs puissent enregistrer leurs comptes et que vous puissiez suivre avec précision l'utilisation du stockage. Implémentez des journaux structurés conformément à la norme d'événements pour les indexeurs.

Meilleures pratiques pour les contrats de tokens

• Appliquer correctement les dépôts de stockage : Exigez storage_deposit avant les transferts et les émissions vers de nouveaux comptes pour éviter l'enflure de l'état et les cas limites — Storage.md.
• Suivre les normes de métadonnées et d'événements : Des métadonnées complètes et des journaux structurés améliorent la découvrabilité et l'analytique — FungibleTokenMetadata.md, Events.md.
• Utiliser ft_transfer_call avec précaution : Traitez la logique du destinataire comme non fiable. Validez les montants, gérez les remboursements via le résolveur et évitez les hypothèses dangereuses — FungibleToken.md.
• Conserver les soldes en entiers de 128 bits et maintenir la cohérence des décimales : NEAR utilise couramment 24 décimales ; documentez clairement votre choix dans les métadonnées.
• Émettre des journaux lisibles par l'homme et analysables par machine : Les indexeurs et l'analytique dépendent des journaux standardisés ; n'inventez pas votre propre format.
• Fournir des méthodes d'administration claires avec contrôle d'accès : L'émission, la mise en pause et la mise à niveau doivent être transparentes et auditables.

L'impact de l'écosystème en 2025

NEP-141 alimente un ensemble diversifié d'actifs sur NEAR, y compris des stablecoins majeurs. Par exemple, Tether a intégré USDT sur NEAR, améliorant les options de règlement et la liquidité pour les utilisateurs DeFi — Tether lance l'USDT sur NEAR. Les tokens circulent entre les écosystèmes via des ponts comme le Rainbow Bridge et s'échangent sur des plateformes comme Ref Finance.

Côté protocole, NEAR continue de faire progresser l'abstraction de chaîne et les expériences utilisateur multi-chaînes, notamment grâce à des initiatives comme Chain Signatures, qui visent à simplifier les interactions inter-chaînes et la gestion des clés. Vous pouvez suivre les sorties et les mises à jour techniques sur le blog officiel — Blog NEAR et l'analyse approfondie de l'abstraction de chaîne — Chain Signatures.

Pour les constructeurs, cela signifie que les tokens NEP-141 participent de plus en plus aux flux inter-chaînes, à l'intégration conviviale pour mobile et à la composition front-end via la pile de développement de l'écosystème NEAR. Le respect des normes garantit dès maintenant la compatibilité de vos actifs à mesure que ces capacités se développent.

Conseils d'intégration pour les portefeuilles et les dApps

• Gérer les flux de stockage dans l'interface utilisateur : Invitez les utilisateurs à s'enregistrer avec storage_deposit avant les premiers transferts ou échanges.
• Prendre en charge à la fois ft_transfer et ft_transfer_call : De nombreuses dApps utilisent cette dernière pour effectuer des opérations atomiques et des remboursements.
• Afficher les métadonnées de manière soignée : Utilisez les décimales pour formater correctement les soldes ; affichez les icônes et les hashes de référence lorsque disponibles.
• Analyser les journaux standardisés : Indexez les événements NEP-141 pour alimenter les notifications, l'analytique et les vues historiques.

Les utilisateurs peuvent suivre les soldes et les transferts de tokens via NEAR Explorer, et les dApps peuvent inspecter les contrats ou vérifier les déploiements en utilisant les spécifications officielles dans le dépôt des NEPs de NEAR — NEPs sur GitHub.

Conservation et sécurité

Les faibles frais et la finalité rapide de NEAR le rendent pratique pour les transferts fréquents, mais la conservation reste essentielle. Si vous détenez des tokens NEP-141 importants ou interagissez avec la DeFi, envisagez de déplacer vos clés vers un portefeuille matériel hors ligne pour la vérification des transactions et la réduction du risque de phishing. OneKey fournit des confirmations sur appareil et une prise en charge multi-chaînes, ce qui permet de s'assurer que vous approuvez les bons paramètres ft_transfer ou ft_transfer_call lors d'opérations critiques. Pour les utilisateurs actifs de NEAR, associer un portefeuille matériel à des autorisations de compte judicieuses et à des dApps auditées peut réduire considérablement votre surface d'attaque.

Points clés à retenir

• NEP-141 est la norme FT faisant autorité sur NEAR, combinant transferts, dépôts de stockage, métadonnées et journalisation des événements dans une interface composable — FungibleToken.md.
• Le modèle asynchrone et la sémantique de remboursement offrent des interactions inter-contrats plus sûres que les modèles basés sur l'autorisation.
• Implémentez les normes de stockage et de métadonnées ; émettez des journaux structurés pour les indexeurs.
• Les tokens conformes à NEP-141 s'intègrent de manière transparente entre les ponts, les portefeuilles et les applications DeFi dans l'écosystème croissant de NEAR — Rainbow Bridge, Ref Finance, NEAR Explorer.
• Alors que NEAR fait évoluer son abstraction de chaîne et son intégration utilisateur en 2025, la conformité aux normes garantit que vos tokens restent portables et pérennes — Blog NEAR, Chain Signatures.

Que vous émettiez un nouvel actif ou que vous déteniez des tokens NEP-141 existants, considérez la norme comme votre plan directeur, puis ajoutez une sécurité robuste et une UX claire par-dessus.