NEP-141 (NEAR): ¿Qué es NEP-141?NEP-141 es el estándar básico de tokens fungibles para contratos inteligentes en la blockchain NEAR.En el ámbito cripto, un token fungible es aquel cuyas unidades son intercambiables eNEP-141 (NEAR): ¿Qué es NEP-141?NEP-141 es el estándar básico de tokens fungibles para contratos inteligentes en la blockchain NEAR.En el ámbito cripto, un token fungible es aquel cuyas unidades son intercambiables e
¿Qué es NEP-141?
NEP-141 es el estándar básico de tokens fungibles para contratos inteligentes en la blockchain NEAR.En el ámbito cripto, un token fungible es aquel cuyas unidades son intercambiables entre sí por otras unidades del mismo token.Un token NEP-141 puede representar un activo estable, un token de gobernanza, un token de recompensa, un token de utilidad, un activo wrapped, una moneda de juego, un token de liquidez, un activo cripto similar a puntos o un token de staking líquido en NEAR.La guía oficial del estándar de tokens fungibles de NEAR describe NEP-141 como el modelo de referencia para contratos de tokens fungibles en NEAR.
NEP-141 define la interfaz común que debe implementar un contrato para considerarse un contrato de tokens fungibles.Esta interfaz incluye métodos para consultar la oferta total, consultar los saldos de las cuentas, transferir tokens, transferir tokens a un contrato con un callback y resolver los resultados de las llamadas de transferencia.NEP-141 no es lo mismo que el token nativo NEAR.El token nativo NEAR forma parte del protocolo base y se utiliza para el gas, el staking, el almacenamiento y las operaciones de la red.Los tokens NEP-141 se crean y registran dentro de contratos inteligentes que mantienen los saldos de las cuentas de usuario.Por qué es importante NEP-141
NEP-141 es importante porque los tokens fungibles necesitan un comportamiento predecible en wallets, aplicaciones descentralizadas, protocolos DeFi, juegos, herramientas de análisis y contratos inteligentes.Sin un estándar común, cada contrato de token podría utilizar nombres de métodos, formatos de saldo, reglas de transferencia y patrones de integración diferentes.Eso dificultaría que las wallets mostraran los saldos y que las aplicaciones aceptaran tokens.NEP-141 proporciona a desarrolladores y usuarios un lenguaje común para los saldos y las transferencias de tokens en NEAR.Para los usuarios, esto significa que las aplicaciones compatibles con el estándar pueden reconocer un token NEP-141.Para los desarrolladores, significa que un contrato de token puede integrarse con otros contratos mediante métodos conocidos, en lugar de utilizar lógica personalizada para cada token.Para los proyectos, facilita el lanzamiento de tokens porque permite basarse en una interfaz existente.Para el ecosistema de NEAR, ayuda a mejorar la interoperabilidad entre tokens, wallets, contratos de staking líquido, productos DeFi, juegos, sistemas de recompensas y flujos de pago.El estándar es importante porque la compatibilidad puede ser tan relevante como la oferta o la marca del token.Cómo funciona NEP-141
NEP-141 funciona mediante un contrato inteligente que almacena los saldos de tokens y expone métodos estándar.Cuando un usuario posee un token NEP-141, el saldo se registra dentro del contrato del token, no directamente en la cuenta del usuario.El contrato actúa como sistema contable de los saldos, la oferta, las transferencias y los callbacks de los receptores.Una wallet o aplicación puede llamar a
ft_balance_of
para consultar cuántos tokens posee una cuenta.Una wallet o aplicación puede llamar a
ft_total_supply
para consultar la oferta total del token.Un usuario puede llamar a
ft_transfer
para enviar tokens a otra cuenta de NEAR.Un usuario puede llamar a
ft_transfer_call
para enviar tokens a un contrato y activar la lógica de ese contrato receptor.El contrato receptor puede devolver los tokens no utilizados mediante el flujo de llamada de transferencia.Este diseño se adapta al modelo asíncrono de contratos inteligentes de NEAR, en el que los contratos suelen comunicarse mediante llamadas entre contratos en vez de depender de una única ruta de transacción síncrona.NEP-141 frente a NEAR nativo
Los tokens NEP-141 y el token nativo NEAR son tipos de activos distintos.El token nativo NEAR está integrado en el protocolo NEAR y se utiliza para las comisiones de transacción, el staking, el almacenamiento de cuentas y la economía de los validadores.Un token NEP-141 es emitido por un contrato inteligente y se gestiona mediante el registro interno de ese contrato.Los usuarios pueden tener NEAR nativo y tokens NEP-141 en la misma cuenta de NEAR, pero los sistemas contables son distintos.Los saldos de NEAR nativo forman parte del saldo de la cuenta del protocolo.Los saldos NEP-141 los registra el contrato del token.Esta diferencia es importante porque un usuario quizá necesite una pequeña cantidad de NEAR nativo para pagar gas o depósitos de almacenamiento, aunque su intención principal sea mover un token NEP-141.Un usuario que reciba un token NEP-141 también puede tener que registrar el almacenamiento en el contrato del token antes de poder conservarlo.Entender esta diferencia ayuda a evitar transacciones fallidas y confusiones sobre saldos que no aparecen.NEP-141 frente a NEP-171
NEP-141 es el estándar de tokens fungibles, mientras que NEP-171 es el estándar de tokens no fungibles de NEAR.Una unidad de un token NEP-141 es intercambiable por otra unidad del mismo token.Un NFT NEP-171 es único y suele tener su propio ID de token, metadatos y registro de titularidad.Por ejemplo, un juego puede utilizar un token NEP-141 como moneda interna y NFT NEP-171 para representar objetos únicos del juego.Una aplicación DeFi puede utilizar tokens NEP-141 para liquidez o recompensas.Un proyecto artístico puede utilizar NFT NEP-171 para coleccionables digitales únicos.La diferencia afecta a la visualización en wallets, el comportamiento de mercado, los metadatos, los precios, el almacenamiento y la lógica de transferencia.Los usuarios no deben tratar un token NEP-141 como si fuera un NFT, ya que no representa un objeto único.Los desarrolladores deben elegir NEP-141 cuando el activo necesite saldos fungibles y NEP-171 cuando necesite registros de titularidad únicos.Métodos básicos de NEP-141
La interfaz básica de NEP-141 incluye varios métodos importantes.El método
ft_total_supply
devuelve la oferta total del token.El método
ft_balance_of
devuelve el saldo de tokens de una cuenta específica.El método
ft_transfer
transfiere una cantidad de tokens desde quien realiza la llamada a otra cuenta.El método
ft_transfer_call
transfiere tokens a un contrato receptor y llama a la lógica de ese contrato.El método receptor
ft_on_transfer
permite que un contrato receptor acepte tokens y devuelva la cantidad que no haya utilizado.El método
ft_resolve_transfer
completa el flujo de llamada de transferencia después de que responda el contrato receptor.La especificación oficial NEP-141 define estos métodos como la interfaz básica de los tokens fungibles.
Estos métodos son la base de las transferencias de tokens, los pagos a contratos, los depósitos DeFi, los pagos en juegos y los flujos de trabajo basados en tokens en NEAR.ft_total_supply
El método
ft_total_supply
devuelve el número total de unidades base del token emitidas por el contrato.Este método es de solo lectura, lo que significa que no modifica el estado del contrato.Las aplicaciones pueden utilizarlo para mostrar la oferta total, calcular métricas de mercado, comprobar las emisiones del token o supervisar su acuñación y quema.El valor devuelto suele ser una cadena porque las cantidades de tokens pueden ser muy grandes.Los desarrolladores deben evitar tratar las cantidades de tokens como números de coma flotante normales, ya que los errores de precisión pueden provocar errores contables graves.Los usuarios deben entender que la oferta total por sí sola no informa sobre la oferta en circulación, la oferta bloqueada, los saldos de tesorería, el vesting ni la demanda real del mercado.Un token puede tener una oferta total elevada y seguir siendo útil si sus decimales y su demanda son adecuados.Un token puede tener una oferta total baja y seguir siendo arriesgado si la titularidad está concentrada o la liquidez es escasa.La oferta total es solo un elemento del análisis de un token.ft_balance_of
El método
ft_balance_of
devuelve el saldo de tokens de una cuenta de NEAR determinada.Este método es de solo lectura y lo utilizan habitualmente wallets, exploradores, aplicaciones DeFi, juegos, paneles y herramientas de cartera.El saldo se devuelve en las unidades base más pequeñas del token.La cantidad que ve el usuario depende de los decimales del token especificados en sus metadatos.Por ejemplo, un token con 24 decimales puede mostrar una cantidad legible menor de lo que sugiere el valor bruto en unidades base.Las aplicaciones deben formatear los saldos con los metadatos del token, en lugar de suponer el número de decimales.Los usuarios también deben saber que la información de una wallet puede aparecer con retraso o estar almacenada en caché.Si un saldo mostrado en una wallet parece incorrecto, conviene comprobar el estado del contrato y el historial de transacciones mediante herramientas de confianza.Para mostrar correctamente el saldo, se necesita tanto el método de saldo NEP-141 como una gestión precisa de los metadatos.ft_transfer
El método
ft_transfer
envía una cantidad de tokens especificada desde quien realiza la llamada a una cuenta receptora.Es el método básico para transferir tokens NEP-141 entre cuentas de NEAR.El método puede incluir un campo memo opcional.El memo puede explicar el propósito de una transferencia, como una referencia de pago, una nota interna o un mensaje específico de la aplicación.La documentación estándar de NEAR indica que
ft_transfer
exige adjuntar exactamente 1 yoctoNEAR a la llamada.Este pequeño depósito adjunto ayuda a confirmar que la transacción está firmada con una clave de acceso completo para realizar acciones sensibles.Los usuarios siempre deben verificar la cuenta receptora antes de enviar una transferencia.Las transferencias de tokens suelen ser difíciles o imposibles de revertir si se envían a la cuenta equivocada.Los proyectos deben diseñar pantallas de transferencia claras para que los usuarios puedan ver el token, la cantidad, el destinatario, el gas y el memo antes de firmar.ft_transfer_call
El método
ft_transfer_call
envía tokens a un contrato receptor y llama a un método de ese contrato en el mismo flujo de alto nivel.Este método es una de las partes más importantes de NEP-141 porque permite utilizar tokens entre contratos.Un usuario puede utilizar
ft_transfer_call
para depositar tokens en un contrato DeFi, pagar a un contrato de servicio, unirse a un contrato de juego, poner tokens en staking, usar un bridge o activar la lógica de una aplicación.El método incluye
receiver_id
, amount
, un memo
opcional y el campo msg
.El campo
msg
permite al remitente enviar instrucciones específicas de la aplicación al contrato receptor.El contrato receptor debe implementar
ft_on_transfer
para procesar los tokens entrantes.Si el receptor no utiliza todos los tokens, puede devolver la cantidad no utilizada para que se reembolse al remitente.En muchos flujos de aplicaciones, este diseño reduce la necesidad de realizar transacciones de aprobación y pago por separado.Los usuarios solo deben utilizar flujos de llamadas de transferencia con contratos de confianza, ya que el contrato receptor determina cómo se gestionan los tokens transferidos.ft_on_transfer
Los contratos que quieren recibir tokens NEP-141 mediante
ft_transfer_call
implementan el método ft_on_transfer
.Este método recibe la cuenta del remitente, la cantidad de tokens y el mensaje enviado en la llamada de transferencia.El contrato receptor puede decidir qué hacer con los tokens.Por ejemplo, puede abonar un depósito a un usuario, comprar un objeto, registrar un pago, acuñar un token de recibo, abrir una posición de staking o rechazar la transferencia.El método devuelve la cantidad de tokens que no ha utilizado el contrato receptor.Esa cantidad no utilizada puede reembolsarse mediante el flujo de resolución.Este patrón es importante porque permite que los contratos reciban tokens fungibles de forma segura y respondan con lógica de aplicación.Los desarrolladores deben gestionar este método con cuidado, ya que los valores de retorno incorrectos pueden provocar reembolsos equivocados o saldos confusos.Los usuarios deben entender que enviar tokens a un contrato no es lo mismo que enviarlos a una cuenta normal.ft_resolve_transfer
El método
ft_resolve_transfer
completa el flujo de llamada de transferencia después de que responda el contrato receptor.Se utiliza como callback para determinar si se debe devolver al remitente alguna cantidad de tokens no utilizada.Esto es importante porque las llamadas a contratos de NEAR son asíncronas.El contrato del token no puede dar por hecho que el contrato receptor ha utilizado correctamente todos los tokens hasta conocer el resultado del callback.Si el contrato receptor rechaza la transferencia o informa de que quedan tokens sin utilizar, el contrato del token puede reembolsar la cantidad correspondiente según la lógica estándar.Este método ayuda a que los flujos de tokens a contratos sean más seguros y componibles.Los desarrolladores deben probar las llamadas fallidas del receptor, los reembolsos parciales y los casos límite antes de lanzar contratos de producción.Los usuarios deben entender que una llamada de transferencia puede tener resultados más complejos que una transferencia sencilla entre wallets.Las buenas interfaces de aplicación deben indicar si una llamada de transferencia se ha completado, ha fallado o ha reembolsado los tokens no utilizados.NEP-141 y los metadatos NEP-148
NEP-148 es el estándar de metadatos que se utiliza con los tokens fungibles NEP-141.El estándar de metadatos NEP-148 define el método
ft_metadata
y los campos de metadatos para tokens fungibles.Entre los campos de metadatos importantes están
spec
, name
, symbol
, icon
, reference
, reference_hash
y decimals
.El campo
spec
suele identificar la versión de los metadatos que admite el contrato.El campo
name
indica el nombre legible del token.El campo
symbol
indica el símbolo abreviado que se muestra del token.El campo
decimals
indica a las wallets y aplicaciones cómo formatear los saldos brutos en unidades base para mostrarlos al usuario.Los campos
reference
y reference_hash
pueden apuntar a metadatos off-chain adicionales y ayudar a protegerlos frente a modificaciones silenciosas.NEP-141 proporciona la lógica del token, mientras que NEP-148 ayuda a las wallets y aplicaciones a mostrarlo correctamente.Ejemplo de metadatos NEP-148
Un objeto sencillo de metadatos NEP-148 para un token NEP-141 podría tener este aspecto:{
"spec": "ft-1.0.0",
"name": "Example NEAR Utility Token",
"symbol": "EUT",
"icon": "data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%3E%3C/svg%3E",
"reference": "ipfs://bafyexamplecid/example-token-metadata.json",
"reference_hash": "Base64EncodedSha256HashExample",
"decimals": 24
}
El valor de
decimals
es especialmente importante, ya que los usuarios suelen esperar un saldo legible y no unidades base sin procesar.El campo
icon
puede ayudar a las wallets a mostrar la identidad visual del token.El campo
reference
puede apuntar a información adicional sobre el token.El campo
reference_hash
puede ayudar a confirmar que el fichero de metadatos referenciado no ha cambiado inesperadamente.Los proyectos deben mantener los metadatos precisos, ya que los datos incorrectos pueden inducir a error sobre la identidad del token, la visualización de la oferta o la marca.NEP-141 y la gestión de almacenamiento NEP-145
NEP-145 es el estándar de gestión de almacenamiento que se utiliza habitualmente con tokens NEP-141.El estándar de gestión de almacenamiento NEP-145 define métodos para registrar cuentas y gestionar depósitos de almacenamiento.
El almacenamiento importa porque los contratos de NEAR deben pagar por los datos persistentes guardados on-chain.Cuando un contrato de token guarda un registro de saldo para una cuenta nueva, utiliza espacio de almacenamiento.Muchos contratos de tokens NEP-141 exigen un depósito de almacenamiento antes de que una cuenta pueda tener ese token.El método
storage_deposit
puede registrar una cuenta y reservar almacenamiento.El método
storage_balance_of
puede mostrar si una cuenta tiene el almacenamiento registrado.El método
storage_unregister
puede eliminar el registro de almacenamiento de una cuenta cuando se cumplen las condiciones.Este modelo ayuda a proteger los contratos de tokens frente al pago de costes de almacenamiento ilimitados para todos los usuarios.Depósitos de almacenamiento para tokens NEP-141
Un depósito de almacenamiento es una pequeña cantidad de NEAR nativo que se adjunta para cubrir el almacenamiento persistente del contrato.En el caso de los tokens NEP-141, a menudo se necesitan depósitos de almacenamiento antes de que un usuario pueda recibir o utilizar un token.Esto puede sorprender a usuarios acostumbrados a redes en las que los saldos de tokens aparecen sin necesidad de un registro de almacenamiento aparte.El depósito no es lo mismo que el precio de compra de un token.Normalmente se reserva para cubrir el espacio de datos de la cuenta en el contrato del token.Algunos contratos permiten recuperar los depósitos de almacenamiento no utilizados anulando el registro cuando el saldo es cero.Antes de intentar una transferencia, un depósito o una operación DeFi, los usuarios deben comprobar si están registrados.Las aplicaciones deben mostrar los requisitos de almacenamiento antes de que los usuarios firmen transacciones.Una información clara sobre el almacenamiento puede evitar transferencias fallidas y confusión entre los usuarios.NEP-141 y los eventos NEP-297
NEP-297 define un formato estándar para los eventos emitidos por los contratos de NEAR.El estándar de eventos NEP-297 admite registros de eventos estructurados que pueden leer los indexadores y las aplicaciones.
La documentación de NEAR indica que los eventos estándar de tokens fungibles incluyen
ft_transfer
, ft_mint
y ft_burn
.Los eventos ayudan a wallets, exploradores, herramientas de análisis e indexadores a seguir la actividad de los tokens.Por ejemplo, un indexador puede leer los eventos de transferencia de tokens para actualizar los saldos y el historial de transacciones.Un panel DeFi puede leer eventos para conocer los depósitos, las retiradas o los flujos de recompensas.Un proyecto puede utilizar datos de eventos para crear notificaciones para los usuarios o sistemas contables.Los nombres de eventos estándar facilitan las integraciones, ya que las herramientas no necesitan analizar datos de forma personalizada para cada contrato de token.Los eventos mejoran la observabilidad, pero cuando los saldos exactos sean importantes, los usuarios deben seguir verificando el estado del contrato.Cantidades y decimales de NEP-141
Las cantidades de tokens NEP-141 suelen gestionarse como cadenas de enteros grandes.Este diseño evita problemas de precisión de coma flotante en contratos inteligentes y aplicaciones.Los metadatos
decimals
del token indican a las interfaces cómo convertir las unidades base brutas en una cantidad legible.Por ejemplo, un token con 24 decimales puede mostrar un token entero como un valor entero bruto muy grande.Los desarrolladores deben guardar y calcular los saldos en unidades base.Las wallets deben mostrar los saldos utilizando los decimales especificados en los metadatos del token.Los usuarios deben tener cuidado al leer datos brutos de transacciones, ya que la cantidad sin procesar puede parecer mucho mayor que el saldo mostrado.Una gestión incorrecta de los decimales puede provocar transferencias y precios mostrados incorrectos, así como errores contables.La precisión es uno de los detalles técnicos más importantes de las aplicaciones de tokens fungibles.NEP-141 y DeFi
Los tokens NEP-141 se utilizan ampliamente en aplicaciones DeFi de NEAR.Un contrato DeFi puede aceptar tokens NEP-141 para depósitos, swaps, préstamos, concesión de préstamos, recompensas, posiciones de liquidez, garantías o actividades de gobernanza.El método
ft_transfer_call
es especialmente útil para DeFi porque puede transferir tokens y activar la lógica del contrato en un mismo flujo.Por ejemplo, un usuario puede enviar tokens a un contrato de pool e incluir un mensaje que explique la acción prevista.El contrato receptor puede procesar el depósito y devolver los tokens no utilizados si es necesario.El uso de DeFi añade riesgos que van más allá del estándar del token.Los usuarios pueden afrontar riesgos de contratos inteligentes, liquidez, volatilidad de precios, liquidación, oráculos y tokenomics.La compatibilidad con NEP-141 facilita la integración, pero no garantiza que una estrategia DeFi sea segura.Antes de depositar fondos, los usuarios deben entender tanto el token como el protocolo.NEP-141 y el staking líquido
Los contratos de staking líquido en NEAR pueden emitir tokens que sigan NEP-141.La documentación de NEAR explica que un contrato de staking líquido puede emitir un token NEP-141 que se comporta como otros tokens fungibles de la red.En este modelo, un usuario deposita NEAR nativo en un contrato de staking y recibe un token líquido que representa su posición de staking.El token líquido suele poder transferirse o utilizarse en aplicaciones DeFi compatibles.El tipo de cambio entre el token líquido y el NEAR subyacente en staking puede cambiar con el tiempo a medida que se acumulan recompensas de staking.Los usuarios no deben asumir que un token de staking líquido es lo mismo que NEAR nativo.Conlleva riesgos de contratos inteligentes, liquidez, precio de mercado y reglas de reembolso.También pueden aplicarse depósitos de almacenamiento la primera vez que se interactúa con el contrato del token de staking líquido.NEP-141 hace que el token líquido sea interoperable, pero no elimina los riesgos del staking ni de los contratos.NEP-141 y los juegos
Los juegos de NEAR pueden utilizar tokens NEP-141 como monedas internas, recompensas, puntos de energía, materiales de creación, activos de gobernanza o tokens de pago.Un juego puede utilizar tokens NEP-141 junto con NFT, empleando el token fungible para los gastos y los NFT para representar objetos únicos.Por ejemplo, un juego podría utilizar un token NEP-141 para los pagos en el marketplace y NFT NEP-171 para los personajes o el equipamiento.Este diseño con dos tipos de token puede ofrecer flexibilidad a las economías de los juegos.Sin embargo, los tokens de juegos pueden sufrir inflación si se emiten demasiadas recompensas sin suficiente demanda.Los desarrolladores deben diseñar cuidadosamente los mecanismos de gasto, los controles de oferta, las reglas de recompensas y la utilidad.Los jugadores deben entender si el token se utiliza en un juego activo o si solo se ha prometido para futuras funciones.Un token de juego NEP-141 puede cumplir técnicamente el estándar y aun así perder valor si la economía del juego está mal diseñada.Los estándares de tokens facilitan la integración, pero la calidad del juego sustenta la demanda a largo plazo.NEP-141 y las DAO
Las DAO y los proyectos comunitarios pueden utilizar tokens NEP-141 para gobernanza, poder de voto, recompensas, operaciones de tesorería o funciones similares a una membresía.Un token de gobernanza puede permitir a sus titulares votar propuestas o expresar las preferencias de la comunidad.El contrato del token quizá solo registre los saldos y las transferencias.La lógica de gobernanza suele residir en contratos o aplicaciones independientes que consultan los saldos del token.Los usuarios deben entender si tener el token concede poder de gobernanza real o solo una influencia simbólica.Los titulares con grandes cantidades pueden tener más poder de voto que los pequeños si la gobernanza pondera los votos según el saldo.Los proyectos deben comunicar claramente la distribución del token, los saldos de tesorería, el vesting y las reglas de votación.Un token de gobernanza no debe evaluarse únicamente por su símbolo o la actividad de la comunidad.Los derechos de gobernanza reales dependen del diseño completo de gobernanza, no solo del estándar NEP-141.NEP-141 y los activos wrapped
Los activos wrapped pueden utilizar NEP-141 para representar activos de otras redes o sistemas dentro de las aplicaciones de NEAR.Un token wrapped suele depender de un bridge, un custodio, un sistema de acuñación y quema o un mecanismo de prueba que vincula el token wrapped con el activo original.NEP-141 puede hacer que el token wrapped se comporte como un token fungible normal dentro de NEAR.Sin embargo, el estándar del token no demuestra que el activo wrapped esté totalmente respaldado.Los usuarios deben entender el diseño del bridge o de la custodia que sustenta cualquier activo wrapped.Deben comprobar las reglas de reembolso, los sistemas de prueba, las comisiones, los límites, la liquidez y la seguridad de los contratos.Un token NEP-141 wrapped puede ser útil para obtener liquidez entre ecosistemas, pero añade supuestos técnicos y de confianza.Las aplicaciones deben identificar claramente los activos wrapped para que los usuarios no los confundan con activos nativos.El respaldo y el reembolso son tan importantes como la compatibilidad del token.NEP-141 y las wallets
Las wallets utilizan los métodos y metadatos de NEP-141 para mostrar saldos de tokens y herramientas de transferencia.Una wallet puede llamar a
ft_balance_of
para mostrar un saldo y a ft_metadata
para mostrar el nombre, el símbolo, el icono y los decimales del token.También puede ayudar a los usuarios a registrar el almacenamiento antes de recibir un token.Si no se muestra un token, puede deberse a que la wallet no lo ha indexado, la cuenta no está registrada, faltan metadatos o la wallet no admite el contrato del token.Antes de confiar en los activos mostrados, los usuarios deben verificar los nombres de las cuentas de contrato de los tokens.Los tokens fraudulentos pueden copiar los nombres, símbolos e iconos de activos legítimos.Que una wallet muestre un token no debe considerarse una prueba de que sea oficial.Al verificar tokens, los usuarios deben basarse en las fuentes oficiales del proyecto, los nombres de las cuentas de contrato y el historial de transacciones.Un buen diseño de wallet ayuda a los usuarios a ver tanto la identidad del token como el contrato que lo respalda.NEP-141 y los listados de tokens
La inclusión de tokens en aplicaciones suele depender de los metadatos, la verificación de la cuenta del contrato, la liquidez y el reconocimiento de la comunidad.Un token NEP-141 puede existir on-chain aunque no aparezca en una wallet, un rastreador de carteras, una interfaz DeFi o una página de análisis.Que un token aparezca en un listado no significa automáticamente que sea seguro o valioso.Que no aparezca en un listado tampoco significa automáticamente que sea inválido.Las aplicaciones pueden aplicar sus propios filtros para reducir el spam, los símbolos copiados, los contratos maliciosos y los activos de baja calidad.Los proyectos deben publicar los nombres de las cuentas de contrato oficiales y los metadatos para que los usuarios puedan verificar el token auténtico.Los usuarios deben desconfiar de los tokens con símbolos conocidos pero cuentas de contrato desconocidas.La identidad de un token procede de la cuenta de su contrato y de las fuentes verificadas del proyecto, no solo de su ticker.Una verificación clara del token reduce el riesgo de tokens falsos.NEP-141 y la seguridad
La seguridad de NEP-141 depende de la implementación del contrato, los permisos de las cuentas, las integraciones de aplicaciones y el comportamiento de los usuarios.Un token puede cumplir NEP-141 y aun así tener controles de acuñación arriesgados, permisos de administrador débiles, lógica de receptor insegura, una gestión deficiente del almacenamiento o metadatos engañosos.Antes de transferir, depositar o intercambiar tokens, los usuarios deben verificar los nombres de las cuentas de contrato.Deben tener cuidado con símbolos de tokens falsos, páginas de phishing, aplicaciones maliciosas y enlaces de reclamación enviados por mensaje directo.La guía de la FTC sobre estafas con criptomonedas advierte a los usuarios sobre oportunidades cripto falsas, suplantaciones de identidad y promesas de grandes rendimientos.
Ningún contrato de token ni cuenta de asistencia legítimos deben solicitar una frase semilla, una frase de recuperación o una clave privada.Antes del lanzamiento, los desarrolladores deben probar las transferencias, las llamadas de transferencia, el registro de almacenamiento, la acuñación, la quema y los casos límite.Cuando corresponda, los proyectos deben comunicar las claves de administrador, las reglas de actualización, la autoridad de acuñación, los controles de pausa y los saldos de tesorería.La seguridad es una cuestión que afecta al sistema completo, no solo al cumplimiento del estándar.NEP-141 y la pérdida de tokens
Los usuarios pueden perder tokens si los envían a la cuenta equivocada, utilizan el contrato incorrecto, no registran el almacenamiento o interactúan con aplicaciones inseguras.A diferencia del saldo de una cuenta centralizada, una transferencia de tokens en una blockchain puede no ser reversible.Antes de enviar tokens NEP-141, los usuarios deben confirmar la cuenta receptora.También deben confirmar que un contrato puede recibir tokens antes de utilizar
ft_transfer_call
.Enviar tokens a un contrato que no está diseñado para gestionarlos puede provocar resultados confusos o irrecuperables.Antes de que los usuarios firmen, las aplicaciones deben explicar claramente los requisitos del receptor.La primera vez que interactúen con un contrato nuevo, los usuarios deben probarlo con cantidades pequeñas.Deben conservar suficiente NEAR nativo para las operaciones de gas y almacenamiento.Revisar cuidadosamente las transacciones es la forma más sencilla de reducir la pérdida de tokens.NEP-141 e impuestos
La actividad relacionada con tokens NEP-141 puede plantear obligaciones de declaración fiscal según el país y la situación personal del usuario.La página oficial del IRS sobre activos digitales indica que quizá deban declararse las transacciones con activos digitales y que los ingresos procedentes de activos digitales pueden estar sujetos a impuestos.
Comprar, vender, intercambiar, recibir, obtener, poner en staking, transferir mediante un bridge o utilizar tokens NEP-141 puede tener consecuencias fiscales en algunas jurisdicciones.Recibir recompensas en tokens puede plantear cuestiones relacionadas con los ingresos.El intercambio de un token por otro puede generar cálculos de ganancias o pérdidas.En algunos lugares, utilizar un token para comprar un NFT o pagar un servicio también puede considerarse una disposición.Los usuarios deben conservar los hashes de transacción, las fechas, los nombres de cuenta, las cantidades de tokens, los valores razonables de mercado, las comisiones de gas, los depósitos de almacenamiento y los ingresos obtenidos.Los proyectos deben llevar un registro de la acuñación, la actividad de tesorería, las recompensas, los incentivos de liquidez y la distribución de tokens.Los usuarios con una actividad significativa con tokens deben consultar a un profesional fiscal cualificado.NEP-141 y la propiedad intelectual
Los tokens NEP-141 suelen representar saldos fungibles, aunque algunos pueden estar vinculados a una marca, un juego, una comunidad, una obra de arte o un ecosistema de medios.Ser titular de un token no concede automáticamente derechos de autor, derechos de marca ni derechos comerciales sobre la marca o los contenidos del proyecto.El estudio de la Oficina de Derechos de Autor de EE. UU. y la USPTO sobre NFT explica que la titularidad de un token y los derechos de propiedad intelectual pueden ser cuestiones distintas en las aplicaciones NFT; conviene aplicar la misma cautela a las afirmaciones sobre contenidos vinculados a tokens.
Un proyecto puede conceder a los titulares de tokens acceso, derechos de gobernanza, recompensas, descuentos o derechos de participación.Estos derechos deben explicarse en las condiciones o la documentación del proyecto.Los usuarios no deben asumir que tener un token NEP-141 significa ser titular de una marca, un protocolo, una obra de arte, un personaje de juego o una empresa.Los derechos legales dependen del diseño del token, la documentación del proyecto y la legislación aplicable.Una descripción clara de los derechos ayuda a evitar confusiones entre los usuarios.La titularidad del token debe distinguirse de la propiedad intelectual, salvo que las condiciones establezcan claramente una relación entre ambas.NEP-141 y la tokenomics
La tokenomics describe el diseño económico de un token NEP-141.Entre los factores importantes de la tokenomics están la oferta total, la oferta en circulación, las reglas de acuñación y quema, las emisiones, las recompensas, el vesting, la asignación de tesorería, la utilidad, las comisiones, la gobernanza y la liquidez.NEP-141 define el comportamiento del token, pero no determina si su tokenomics es sostenible.Un token puede cumplir el estándar y aun así tener una utilidad débil, inflación elevada, titularidad concentrada o desbloqueos poco claros.Antes de considerar valioso un token NEP-141, los usuarios deben evaluar su tokenomics.Los desarrolladores deben explicar si la oferta puede aumentar y quién controla la acuñación.Los proyectos deben comunicar claramente, en un lenguaje sencillo, las asignaciones de tesorería, los calendarios de vesting y las emisiones de recompensas.Una tokenomics sólida debe vincular la demanda del token con la actividad real del ecosistema.Una tokenomics débil suele depender únicamente del entusiasmo o de incentivos a corto plazo.NEP-141 y la acuñación
Acuñar significa crear nuevas unidades de un token y aumentar su oferta.NEP-141 incluye el comportamiento de saldos y transferencias, pero el método exacto de acuñación depende de la implementación del contrato.Algunos contratos de tokens acuñan una oferta fija al desplegarse.Algunos permiten que un titular, una DAO o un rol autorizado acuñe más tokens posteriormente.Otros acuñan recompensas en función del staking, los juegos, la liquidez o la actividad del protocolo.La autoridad de acuñación es uno de los factores de riesgo más importantes en un contrato de tokens fungibles.Si una cuenta puede acuñar tokens sin límite, los titulares pueden estar expuestos al riesgo de dilución.Los proyectos deben comunicar claramente la autoridad de acuñación y las reglas de oferta.Si es posible acuñar tokens en el futuro, los usuarios no deben evaluar el token únicamente según su oferta actual.NEP-141 y la quema
Quemar significa retirar unidades de tokens de la circulación según las reglas del contrato.Un contrato de token puede quemar tokens para reembolsos, comisiones, creación de objetos en juegos, reducción de la oferta, decisiones de gobernanza, salidas de bridges o mecanismos del protocolo.Los eventos estándar NEP-297 pueden ayudar a los indexadores a seguir la actividad
ft_burn
cuando se implementa correctamente.La quema puede reducir la oferta, pero no hace que un token sea valioso automáticamente.La demanda, la utilidad, la liquidez y la distribución siguen siendo importantes.Los usuarios deben entender por qué se queman tokens y quién puede iniciar la quema.Los proyectos deben explicar si las quemas son permanentes y si reducen la oferta total.Los mecanismos de quema deben auditarse y probarse, ya que los errores contables de la oferta pueden perjudicar la confianza.La quema solo tiene sentido si los usuarios entienden la razón económica que la motiva.NEP-141 y los permisos de las cuentas
Las cuentas de NEAR pueden utilizar claves de acceso con distintos permisos.Esto es importante para las transferencias de tokens NEP-141, ya que las acciones sensibles deben firmarse con una cuenta que tenga la autoridad adecuada.Algunas aplicaciones pueden solicitar claves de acceso limitadas para facilitar interacciones repetidas.Los permisos limitados pueden mejorar la experiencia del usuario, pero este debe entender qué acciones permite la clave.Un permiso malicioso o demasiado amplio puede poner en riesgo los tokens.Los usuarios deben revisar los permisos de las aplicaciones antes de aprobarlos.Deben eliminar las claves de acceso antiguas o que ya no utilicen.Los proyectos deben solicitar únicamente los permisos necesarios para una aplicación concreta.La seguridad de la cuenta forma parte de la seguridad de los tokens en NEAR.NEP-141 y las llamadas entre contratos
Las llamadas entre contratos son fundamentales para el diseño de aplicaciones NEP-141.El modelo asíncrono de NEAR hace que los contratos se comuniquen mediante promesas y callbacks, en lugar de una pila de llamadas síncrona sencilla.El patrón
ft_transfer_call
permite que el contrato del token y el contrato receptor coordinen la entrega de tokens y la lógica de la aplicación.Esto permite gestionar depósitos, pagos, staking, juegos, bridges, préstamos y otros flujos de contratos inteligentes.Los desarrolladores deben gestionar cuidadosamente los resultados de los callbacks, ya que los contratos receptores pueden fallar, rechazar tokens o devolver cantidades no utilizadas.Los usuarios deben entender que depositar tokens en un contrato no es lo mismo que transferirlos a una wallet.Una vez enviados los tokens a un contrato, la lógica receptora determina lo que ocurre según su código.Antes de firmar, las aplicaciones deben mostrar al usuario el contrato receptor y el mensaje de acción.La componibilidad entre contratos es potente, pero requiere un diseño cuidadoso de las interfaces.NEP-141 e indexadores
Los indexadores leen datos de la blockchain y los organizan para las aplicaciones.En el caso de los tokens NEP-141, los indexadores pueden seguir transferencias, acuñaciones, quemas, saldos, titulares, metadatos de contratos y eventos DeFi.Los registros de eventos estándar facilitan este trabajo porque las herramientas pueden analizar nombres de eventos conocidos.Las wallets, los exploradores, las herramientas fiscales, los paneles de análisis y los rastreadores de carteras pueden depender de datos indexados de tokens.Los datos indexados aún pueden estar retrasados, almacenados en caché, incompletos o ser incorrectos.Cuando los saldos exactos sean importantes, las aplicaciones deben comprobar tanto el estado del contrato como los resultados del indexador.Los usuarios deben recordar que el saldo de una interfaz suele ser una capa de visualización construida sobre datos del contrato y del indexador.Los buenos indexadores mejoran la utilidad de los tokens, pero no sustituyen al contrato del token como fuente de verdad.Los desarrolladores deben diseñar los eventos y los metadatos teniendo en cuenta la compatibilidad con los indexadores.Cómo verificar un token NEP-141
Empieza por consultar la fuente oficial del proyecto para identificar la cuenta del contrato del token.Verifica la cuenta del contrato del token en lugar de basarte únicamente en su símbolo.Llama a
ft_metadata
o consulta sus datos para confirmar el nombre, el símbolo, los decimales y el campo spec del token.Llama a
ft_total_supply
o consulta sus datos para conocer la oferta total actual.Llama a
ft_balance_of
o consulta sus datos para comprobar el saldo de una cuenta.Comprueba si la cuenta necesita
storage_deposit
antes de recibir o utilizar el token.Revisa la tokenomics, la autoridad de acuñación, las reglas de quema, los saldos de tesorería y la documentación del proyecto.Comprueba si el token tiene utilidad real, liquidez e integraciones activas.Una cuenta de contrato verificada es más importante que un nombre conocido o un icono atractivo.Buenas prácticas para usuarios de NEP-141
Los usuarios deben verificar la cuenta del contrato del token antes de enviarlo, recibirlo, intercambiarlo o depositarlo.Deben conservar suficiente NEAR nativo para el gas y los depósitos de almacenamiento.Deben registrar el almacenamiento cuando una aplicación lo requiera.Deben leer las solicitudes de la wallet antes de firmar transferencias o llamadas de transferencia.Deben probar primero las nuevas interacciones con contratos utilizando cantidades pequeñas.Deben evitar tokens promocionados mediante mensajes directos, afirmaciones urgentes o promesas de beneficios garantizados.Deben comprobar los metadatos y los decimales del token antes de confiar en el saldo mostrado.Deben entender la diferencia entre NEAR nativo y los tokens NEP-141.Deben conservar registros para impuestos, contabilidad y seguimiento personal.Deben tratar cada interacción con tokens como irreversible, salvo que el contrato ofrezca claramente una vía de reembolso.Buenas prácticas para desarrolladores de NEP-141
Los desarrolladores deben implementar correctamente la interfaz básica NEP-141.También deben implementar los metadatos NEP-148 para que las wallets puedan mostrar correctamente el token.Deben utilizar la gestión de almacenamiento NEP-145 para evitar el abuso de los costes de almacenamiento.Deben emitir eventos estándar NEP-297 para transferencias, acuñaciones y quemas.Deben gestionar cuidadosamente los casos límite de
ft_transfer_call
y ft_resolve_transfer
.Deben probar los reembolsos, las llamadas fallidas de receptores, las cantidades cero o muy pequeñas, el registro de almacenamiento y las acciones no autorizadas.Deben documentar la autoridad de acuñación, las reglas de quema, los permisos de actualización, las claves del titular, los controles de pausa y el comportamiento de la tesorería.Deben evitar permisos de administrador ocultos que puedan sorprender a los usuarios.Un buen contrato NEP-141 debe ser compatible, seguro, transparente y fácil de integrar en las aplicaciones.Errores habituales al utilizar NEP-141
Un error frecuente es pensar que los tokens NEP-141 se almacenan directamente en una cuenta de usuario.Otro error es olvidar que el contrato del token registra internamente los saldos.Un tercer error es enviar tokens antes de que el receptor haya registrado el almacenamiento.Un cuarto error es confundir NEAR nativo con un token NEP-141.Un quinto error es confiar en el símbolo de un token sin verificar la cuenta del contrato.Un sexto error es ignorar los decimales y leer mal las cantidades brutas de tokens.Un séptimo error es utilizar
ft_transfer_call
con un contrato receptor desconocido.Un octavo error es asumir que cumplir el estándar implica que la tokenomics es segura.Un noveno error es ignorar la autoridad de acuñación o los permisos de actualización.Un décimo error es no guardar registros fiscales y de transacciones.Ideas equivocadas habituales sobre NEP-141
Una idea equivocada habitual es pensar que NEP-141 es lo mismo que el token nativo NEAR.En realidad, NEP-141 es un estándar de contratos inteligentes para tokens fungibles, mientras que NEAR nativo es el activo base de la red.Otra idea equivocada es creer que todos los tokens NEP-141 son seguros porque siguen un estándar.Un token puede cumplir un estándar y seguir expuesto a estafas, escasa liquidez, tokenomics deficiente o controles de administrador peligrosos.Una tercera idea equivocada es pensar que los metadatos de un token demuestran su autenticidad.Los metadatos pueden copiarse, por lo que la cuenta del contrato y las fuentes oficiales del proyecto son más importantes que el símbolo o el icono por sí solos.Una cuarta idea equivocada es pensar que los depósitos de almacenamiento son comisiones que se pierden para siempre.Algunos contratos permiten recuperar los depósitos de almacenamiento no utilizados anulando el registro cuando se cumplen las condiciones.Una quinta idea equivocada es creer que
ft_transfer_call
es una transferencia normal.Es una transferencia que activa la lógica de un contrato receptor, por lo que los usuarios deben entender el contrato de destino antes de firmar.Resumen SEO y AEO de NEP-141 (NEAR)
NEP-141 es el estándar de tokens fungibles para contratos inteligentes en la blockchain NEAR.Define métodos estándar como
ft_total_supply
, ft_balance_of
, ft_transfer
, ft_transfer_call
, ft_on_transfer
y ft_resolve_transfer
.Los tokens NEP-141 se registran dentro de contratos inteligentes, no directamente en las cuentas de los usuarios.NEP-148 añade metadatos de tokens fungibles, como el nombre, el símbolo, el icono, los decimales, la referencia y el hash de referencia.NEP-145 gestiona el almacenamiento para que los contratos de tokens puedan registrar cuentas y cubrir los costes del almacenamiento persistente.NEP-297 admite eventos estándar como
ft_transfer
, ft_mint
y ft_burn
.NEP-141 puede utilizarse para activos estables, tokens de utilidad, tokens de gobernanza, tokens de staking líquido, monedas de juegos, tokens de recompensa, activos wrapped y tokens DeFi.Antes de interactuar con cualquier token NEP-141, los usuarios deben verificar las cuentas de contrato, los metadatos, el registro de almacenamiento, la tokenomics, los permisos, los impuestos y la seguridad.Preguntas frecuentes
¿Qué significa NEP-141?
NEP-141 es el estándar de tokens fungibles para contratos inteligentes en la blockchain NEAR.¿NEP-141 es lo mismo que NEAR nativo?
No. NEAR nativo es el activo base de la red, mientras que NEP-141 es un estándar para tokens fungibles emitidos por contratos inteligentes.¿Qué métodos incluye NEP-141?
NEP-141 incluye métodos como
ft_total_supply
, ft_balance_of
, ft_transfer
, ft_transfer_call
y ft_resolve_transfer
.¿Qué es ft_transfer?
ft_transfer
es el método estándar para enviar una cantidad de tokens NEP-141 desde quien realiza la llamada a otra cuenta de NEAR.¿Qué es ft_transfer_call?
ft_transfer_call
envía tokens a un contrato receptor y activa la lógica de ese contrato durante el mismo flujo de transferencia.¿Por qué necesitan depósitos de almacenamiento los tokens NEP-141?
Los depósitos de almacenamiento ayudan a cubrir el almacenamiento persistente on-chain que se utiliza cuando los contratos de tokens guardan registros de saldo de cuentas.¿Qué es NEP-148?
NEP-148 es el estándar de metadatos de tokens fungibles que define campos como el nombre, el símbolo, el icono, los decimales, la referencia y el hash de referencia del token.¿Se pueden utilizar tokens NEP-141 en DeFi?
Sí. Los tokens NEP-141 pueden utilizarse en depósitos DeFi, swaps, pools de liquidez, sistemas de staking, recompensas, gobernanza y otros flujos de contratos inteligentes.¿Son seguros todos los tokens NEP-141?
No. La compatibilidad con NEP-141 no garantiza la seguridad, la liquidez, una tokenomics equilibrada, contratos seguros ni un comportamiento legítimo del proyecto.¿Cómo puedo verificar un token NEP-141?
Puedes verificar un token NEP-141 comprobando la cuenta oficial del contrato, los metadatos, la oferta total, los métodos de saldo, el registro de almacenamiento, la tokenomics y la documentación del proyecto.Conclusión
NEP-141 es el principal estándar de tokens fungibles para la blockchain NEAR.Proporciona a los contratos de tokens una interfaz común para consultar la oferta y los saldos, realizar transferencias, llamadas de transferencia y resolverlas.Este estándar ayuda a wallets, protocolos DeFi, juegos, DAO, herramientas de análisis y otras aplicaciones a integrar tokens fungibles de forma más fiable.NEP-141 funciona mejor cuando se combina con los metadatos NEP-148, la gestión de almacenamiento NEP-145 y los eventos estándar NEP-297.Para los usuarios, los aspectos más importantes son verificar la cuenta del contrato, registrar el almacenamiento, conocer los decimales y el gas de NEAR nativo, y revisar las solicitudes de la wallet.Para los desarrolladores, las responsabilidades más importantes son implementar correctamente la interfaz, gestionar de forma segura la lógica de las llamadas de transferencia, definir metadatos claros, gestionar el almacenamiento de forma fiable, emitir eventos estándar y ofrecer controles de administrador transparentes.Para los proyectos, NEP-141 proporciona compatibilidad, pero no crea automáticamente una tokenomics sólida, liquidez, utilidad ni confianza.En aplicaciones DeFi y de juegos, NEP-141 permite flujos de tokens potentes mediante
ft_transfer_call
, pero la seguridad del contrato receptor sigue siendo importante.Un token NEP-141 puede ser útil, líquido y estar ampliamente integrado si se desarrolla y gestiona bien.Un token NEP-141 también puede ser arriesgado si tiene metadatos engañosos, seguridad débil, reglas de oferta poco claras, escasa liquidez o contratos inseguros.La forma más adecuada de entender NEP-141 es como una base técnica para los tokens fungibles de NEAR, no como una garantía de valor o legitimidad.Utilizado de forma responsable, NEP-141 ayuda a NEAR a admitir pagos, DeFi, juegos, recompensas, staking líquido, gobernanza y muchos otros casos de uso de tokens cripto.También te puede interesar
WhatsMiner M30S++
¿Qué es WhatsMiner M30S++? WhatsMiner M30S++ es un minero ASIC de Bitcoin de MicroBT diseñado para la minería Proof of Work con SHA-256. Forma parte de la serie WhatsMiner M30 y se utiliza principalme
2026/10/15 11:08
Dominios Web3
¿Qué son los dominios Web3? Los dominios Web3 son nombres basados en blockchain que pueden sustituir direcciones largas de carteras, dirigir a contenido descentralizado, representar una identidad on-c
2026/10/15 11:08
Proyectos Web3
¿Qué son los proyectos Web3? Los proyectos Web3 son aplicaciones, protocolos, herramientas, redes y comunidades basados en blockchain que utilizan tecnología descentralizada para dar a los usuarios ma
2026/10/15 11:06
POPULAR
Criptomonedas de moda que están acaparando la atención del mercado
Volumen TOP
Las criptomonedas con mayor volumen de trading
Recién Añadidos
Criptomonedas recientemente listadas y disponibles para operar