NEP-141: El estándar de tokens para la red NEAR

Los tokens fungibles son la columna vertebral de la mayoría de las experiencias web3, desde stablecoins y participaciones de LP de DeFi hasta puntos de incentivo y vías de pago. En NEAR, los tokens fungibles se implementan a través de NEP-141, el estándar de token canónico que define cómo los contratos deben acuñar, transferir y contabilizar saldos en toda la red. Esta guía explica qué es NEP-141, en qué se diferencia de los estándares familiares de Ethereum y qué deben saber los desarrolladores y usuarios en 2025.

¿Qué es NEP-141?

NEP-141 es el estándar de token fungible (FT) para NEAR. Especifica la interfaz mínima y los comportamientos que cada contrato de FT debe implementar, incluyendo:

• Métodos de transferencia principales
• Gestión de almacenamiento
• Metadatos del token
• Semántica de transferencia entre contratos y reembolsos

La especificación oficial se publica en el repositorio de Propuestas de Mejora de NEAR y es la mejor fuente única de verdad para los implementadores. Consulte el estándar y las especificaciones complementarias en el GitHub de NEAR:

• Estándar de Token Fungible NEP-141 (métodos, callbacks, lógica de resolución) — FungibleToken.md
• Metadatos del token (nombre, símbolo, decimales, icono, etc.) — FungibleTokenMetadata.md
• Gestión de almacenamiento (registro de cuentas y depósitos) — Storage.md
• Convenciones de eventos/registro — Events.md

Para obtener contexto sobre NEAR y su hoja de ruta actual, consulte el sitio oficial y el blog:

• NEAR Protocol — near.org
• Últimas actualizaciones del ecosistema y análisis técnicos profundos — Blog de NEAR

Por qué importa NEP-141

• Integración consistente entre billeteras y dApps: El cumplimiento garantiza que los tokens "simplemente funcionen" en todas partes, desde exploradores como NEAR Explorer hasta aplicaciones DeFi como Ref Finance.
• Comportamiento predecible para llamadas entre contratos: El modelo asíncrono de NEAR hace que las transferencias entre contratos sean potentes pero complicadas; NEP-141 estandariza los callbacks y la semántica de reembolso.
• Contabilidad consciente del almacenamiento: NEAR requiere que las cuentas paguen por el almacenamiento que utilizan. NEP-141 integra depósitos de almacenamiento y registro de saldos para que los contratos se mantengan seguros y eficientes.
• Componibilidad del ecosistema: Los tokens basados en estándares permiten integraciones limpias con puentes, indexadores y herramientas, por ejemplo, el Rainbow Bridge o las bibliotecas de contratos de Rust.

Cómo NEP-141 se diferencia de ERC-20

Si bien NEP-141 y ERC-20 están conceptualmente alineados, existen diferencias arquitectónicas importantes:

• Llamadas asíncronas y reembolsos: Las llamadas entre contratos de NEAR son asíncronas. ft_transfer_call de NEP-141 invoca el ft_on_transfer del receptor y luego un callback de "resolución" para que los tokens no utilizados puedan ser reembolsados al remitente. Esto contrasta con el flujo síncrono típico de ERC-20. Consulte la mecánica de "resolución" en el estándar — FungibleToken.md.
• Patrón "approve/transferFrom" no predeterminado: NEP-141 se basa en ft_transfer_call y lógica explícita del receptor en lugar de un sistema de asignación global. Esto reduce la superficie de ataque basada en aprobaciones y se alinea mejor con la ejecución basada en promesas de NEAR.
• Depósitos de almacenamiento: Los usuarios a menudo deben "registrar" cuentas en el contrato de token depositando una pequeña cantidad de NEAR para cubrir el almacenamiento. Esto está formalizado en el Estándar de Almacenamiento — Storage.md.
• Registro de eventos: NEAR utiliza formatos de registro estándar en lugar de eventos EVM. El Estándar de Eventos describe cómo emitir registros estructurados que los indexadores pueden analizar — Events.md.

Estas diferencias reflejan el enfoque de diseño de NEAR en la ejecución escalable y asíncrona y las tarifas bajas, al tiempo que preservan la facilidad de uso para los desarrolladores y la seguridad del usuario.

La interfaz NEP-141 de un vistazo

Métodos típicos orientados al usuario:

• ft_transfer(receiver_id, amount, memo?): Transfiere tokens a otra cuenta.
• ft_transfer_call(receiver_id, amount, memo?, msg): Transfiere tokens y llama a la lógica del contrato del receptor; los tokens no utilizados se reembolsan.
• ft_balance_of(account_id): Consulta el saldo.
• ft_total_supply(): Consulta el suministro total.
• ft_metadata(): Lee los metadatos (nombre, símbolo, decimales, icono, hash de referencia).
• Relacionados con el almacenamiento: storage_deposit, storage_balance_of, storage_withdraw (del Estándar de Almacenamiento).

Requisitos del contrato receptor:

• ft_on_transfer(sender_id, amount, msg) -> String: Devuelve la cantidad de tokens que el receptor no utilizó (para ser reembolsada al remitente). El contrato de token llama posteriormente a su propio resolvedor para finalizar la transferencia y manejar los reembolsos.

Si está desarrollando en Rust, utilice las bibliotecas canónicas:

• near-sdk (framework de contratos) — docs.rs/near-sdk
• near-contract-standards (implementación de FT lista para usar) — docs.rs/near-contract-standards

Patrón FT mínimo en Rust (near-contract-standards)

A continuación, se presenta un esquema simplificado; los contratos de producción deben depender de near_contract_standards::fungible_token e implementar los estándares de almacenamiento y eventos.

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
    }

    // Exponer métodos NEP-141 delegando a `ft` (transfer, transfer_call, balance_of, etc.)
}

Utilice los ayudantes de gestión de almacenamiento para que los usuarios puedan registrar cuentas y usted pueda realizar un seguimiento preciso del uso del almacenamiento. Implemente registros estructurados de acuerdo con el Estándar de Eventos para los indexadores.

Mejores prácticas para contratos de tokens

• Reforzar los depósitos de almacenamiento adecuados: Exija storage_deposit antes de las transferencias y acuñaciones a nuevas cuentas para evitar la hinchazón del estado y los casos extremos — Storage.md.
• Seguir los estándares de metadatos y eventos: Los metadatos completos y los registros estructurados mejoran la descubribilidad y el análisis — FungibleTokenMetadata.md, Events.md.
• Usar ft_transfer_call con cuidado: Trate la lógica del receptor como no fiable. Valide las cantidades, maneje los reembolsos a través del resolvedor y evite suposiciones inseguras — FungibleToken.md.
• Mantener los saldos en enteros de 128 bits y decimales consistentes: NEAR utiliza comúnmente 24 decimales; documente claramente su elección en los metadatos.
• Emitir registros legibles por humanos y analizables por máquina: Los indexadores y el análisis dependen de registros estandarizados; no invente su propio formato.
• Proporcionar métodos administrativos claros con control de acceso: La acuñación, la pausa y la actualización deben ser transparentes y auditables.

El impacto en el ecosistema en 2025

NEP-141 potencia una diversa gama de activos en NEAR, incluidas las principales stablecoins. Por ejemplo, Tether integró USDT en NEAR, mejorando las opciones de liquidación y la liquidez para los usuarios de DeFi — Tether lanza USDT en NEAR. Los tokens fluyen entre ecosistemas a través de puentes como el Rainbow Bridge y cotizan en plataformas como Ref Finance.

En el lado del protocolo, NEAR continúa avanzando en la abstracción de cadenas y las experiencias de usuario multichain, de manera destacada a través de iniciativas como Chain Signatures, que tienen como objetivo simplificar las interacciones entre cadenas y la gestión de claves. Puede seguir las versiones en curso y las actualizaciones técnicas en el blog oficial — Blog de NEAR y el análisis profundo sobre la abstracción de cadenas — Chain Signatures.

Para los constructores, esto significa que los tokens NEP-141 participan cada vez más en flujos entre cadenas, incorporación compatible con dispositivos móviles y componibilidad de front-end a través de la pila de desarrolladores del ecosistema NEAR. Cumplir con los estándares ahora garantiza que sus activos permanezcan compatibles a medida que estas capacidades se expanden.

Consejos de integración para billeteras y dApps

• Maneje los flujos de almacenamiento en la interfaz de usuario: Pida a los usuarios que se registren con storage_deposit antes de las primeras transferencias o intercambios.
• Soporte tanto para ft_transfer como para ft_transfer_call: Muchas dApps utilizan esta última para realizar operaciones atómicas y reembolsos.
• Muestre los metadatos de forma clara: Utilice los decimales para formatear correctamente los saldos; muestre los iconos y los hashes de referencia cuando estén disponibles.
• Analice los registros estandarizados: Indexe los eventos NEP-141 para potenciar notificaciones, análisis y vistas históricas.

Los usuarios pueden rastrear saldos y transferencias de tokens a través de NEAR Explorer, y las dApps pueden inspeccionar contratos o verificar implementaciones utilizando las especificaciones oficiales en el repositorio de NEPs de NEAR — NEPs en GitHub.

Custodia y seguridad

Las bajas tarifas y la rápida finalidad de NEAR lo hacen conveniente para transferencias frecuentes, pero la custodia sigue siendo crítica. Si posee una cantidad significativa de tokens NEP-141 o interactúa con DeFi, considere mover las claves a una billetera de hardware sin conexión para la verificación de transacciones y la reducción del riesgo de phishing. OneKey proporciona confirmaciones en el dispositivo y soporte multichain, lo que ayuda a garantizar que está aprobando los parámetros ft_transfer o ft_transfer_call previstos durante las operaciones críticas. Para los usuarios activos de NEAR, emparejar una billetera de hardware con permisos de cuenta sensatos y dApps auditadas puede reducir materialmente su superficie de ataque.

Puntos clave

• NEP-141 es el estándar FT autoritativo en NEAR, combinando transferencias, depósitos de almacenamiento, metadatos y registro de eventos en una interfaz componible — FungibleToken.md.
• El modelo asíncrono y la semántica de reembolso proporcionan interacciones entre contratos más seguras que los patrones basados en aprobaciones.
• Implemente los estándares de almacenamiento y metadatos; emita registros estructurados para los indexadores.
• Los tokens que cumplen con NEP-141 se integran sin problemas en puentes, billeteras y aplicaciones DeFi en el creciente ecosistema de NEAR — Rainbow Bridge, Ref Finance, NEAR Explorer.
• A medida que NEAR evoluciona su abstracción de cadenas y la incorporación de usuarios en 2025, el cumplimiento de los estándares garantiza que sus tokens permanezcan portátiles y preparados para el futuro — Blog de NEAR, Chain Signatures.

Ya sea que esté emitiendo un nuevo activo o posea tokens NEP-141 existentes, trate el estándar como su plano, y luego agregue una seguridad robusta y una UX clara.