¿Qué es un estándar de tokens?

Un estándar de tokens es una especificación técnica que establece qué funciones debe ofrecer un programa de token, qué entradas acepta y cómo comunica los resultados a billeteras y otras aplicaciones. Permite que tokens creados por distintas personas que desarrollan puedan reconocerse y llamarse con un mismo conjunto de reglas.

Conviene entender un estándar como un acuerdo de interfaz: define «cómo comunicarse hacia afuera», pero no decide por ningún proyecto la emisión, el uso, los permisos de administración ni los derechos fuera de la cadena. Dos tokens pueden seguir el mismo estándar y, aun así, usar código distinto, tener permisos distintos y representar objetos completamente diferentes.

Qué pasaría sin un estándar común

Si cada token nombrara a su manera sus funciones de consulta de saldo, transferencia y autorización, billeteras y aplicaciones tendrían que escribir una conexión aparte para cada uno. Un token nuevo, incluso si se transfiere con normalidad, podría no mostrarse en las billeteras existentes ni ser llamado por otros programas en cadena.

Un estándar común fija puntos de entrada uniformes para las operaciones habituales. Una billetera sabe cómo pedir un saldo, una aplicación sabe cómo solicitar una transferencia, un explorador de bloques sabe qué eventos leer, y otros programas pueden llamar a varios tokens con el mismo formato. Quienes desarrollan no necesitan conocer de antemano cada token para ofrecer un soporte básico.

Lo que mejora un estándar es la compatibilidad del software, no la calidad del token. Una vez uniformadas las interfaces, una implementación con errores o malintencionada también puede conectarse más fácilmente a aplicaciones existentes, así que quien lo use igual debe verificar el código y los permisos concretos.

Qué suele definir un estándar

El alcance de un estándar de tokens varía según la red y el tipo de token. Los contenidos habituales se agrupan en las siguientes categorías.

Funciones de consulta

Un estándar puede definir cómo consultar el saldo de una dirección, la emisión total de un token, o quién controla actualmente un número determinado. Una forma uniforme de consulta permite que billeteras y aplicaciones muestren la información básica.

Los resultados de una consulta solo reflejan los datos que el programa devuelve en ese momento. Un estándar no verifica si un nombre de visualización es auténtico, si la emisión tiene respaldo fuera de la cadena, ni garantiza que el material adicional que describe un token —sus metadatos— siga disponible en su enlace a largo plazo.

Funciones de transferencia

Un estándar puede definir cómo quien envía transfiere tokens a quien recibe, qué parámetros exige la llamada y cómo debe responder en caso de éxito o de falla. Para los tokens con número propio, la transferencia además debe indicar el número concreto.

Algunos estándares ofrecen un método de transferencia más seguro, que revisa si el programa receptor sabe manejar los tokens que recibe. Eso puede reducir ciertos envíos por error, pero no evita pérdidas por una dirección equivocada, una autorización maliciosa o una falla de programa.

Funciones de autorización

Una autorización permite a quien tiene el token dejar que otra dirección o programa actúe en su nombre dentro de límites definidos. Por ejemplo, quien lo tiene puede autorizar a una aplicación a transferir cierta cantidad de tokens fungibles, o habilitar a un operador para gestionar un conjunto de tokens con número propio.

Un estándar define cómo crear, consultar y revocar una autorización, pero no decide si una persona debería otorgarla. El tamaño del límite, su duración y el comportamiento del programa autorizado igual deben valorarse según la implementación concreta y por quien la usa.

Eventos y formatos de registro

Cuando un programa en cadena ejecuta una transferencia, una acuñación o una autorización, puede emitir eventos estructurados. Un evento es un aviso de registro de ejecución para que lo lean las aplicaciones, y billeteras, exploradores de bloques y servicios de datos pueden usarlo para actualizar una interfaz o armar un índice.

Un evento no sustituye al estado final. Una aplicación igual debe confirmar si la transacción tuvo éxito y leer los datos actuales según las reglas de la red; ver un solo evento sin confirmar, o proveniente del contrato equivocado, no alcanza para probar que un saldo cambió de forma válida.

Funciones opcionales y extensiones

Un estándar puede considerar opcionales el nombre, el código de cotización, los metadatos o una función que enumere todos los números propios —la enumeración—, y también puede permitir activar comisiones de transferencia, congelamiento, pausa u otras extensiones. Una aplicación no puede suponer que todas las funciones opcionales existen solo porque un token declara adoptar cierto estándar.

Las extensiones además pueden ser incompatibles entre sí, o requerir que las billeteras se adapten a propósito. Que la transferencia básica sea igual no significa que una aplicación antigua pueda entender todos los permisos y campos de datos agregados después.

Estándar, implementación y token no son lo mismo

Un estándar es un acuerdo de funcionalidades que indica cómo debe responder hacia afuera un programa compatible. Una implementación es el código concreto que alguien escribe y despliega siguiendo ese acuerdo. Un token es el registro en cadena y las unidades que gestiona una implementación particular.

Un estándar puede tener muchas implementaciones de código; una misma implementación también puede servir para crear varios tokens distintos. Una implementación puede además agregar comisiones, congelamiento, listas, actualizaciones u otra lógica más allá de lo que exige el estándar.

Por eso «adoptar un estándar» solo indica la intención de admitir un conjunto de interfaces. No prueba que el código esté libre de fallas, ni muestra que todas las interfaces se hayan implementado correctamente. Al integrarlo, una aplicación debe revisar la dirección desplegada, los resultados que realmente devuelve, los permisos adicionales y los comportamientos excepcionales.

Cómo se forma y se adopta un estándar

Un estándar de tokens normalmente aparece primero como propuesta técnica, documento de especificación o programa compartido. Quienes lo escriben exponen el problema a resolver, los requisitos de interfaz y las razones del diseño; después de que la comunidad y quienes desarrollan lo discuten, la propuesta puede llegar a un estado relativamente estable, seguir cambiando o dejar de avanzar.

El estado del documento y la adopción en el mercado son dos cosas distintas. Una propuesta puede estar redactada por completo y usarse poco; otro estándar puede tener muchas implementaciones antes de quedar finalizado. Que billeteras y aplicaciones lo admitan depende de los despliegues reales, de las necesidades de uso y de las decisiones de quienes desarrollan, no del número en sí.

Que un estándar se actualice tampoco cambia necesariamente los tokens ya desplegados. Un contrato antiguo puede seguir funcionando con la interfaz anterior, mientras las funciones nuevas llegan por un contrato nuevo, una versión nueva o una extensión opcional. Al leer un estándar hay que confirmar a la vez la red, la versión, el estado y la implementación concreta.

La interfaz común de los tokens fungibles

Los tokens fungibles se registran por cantidad, y las unidades iguales normalmente se pueden intercambiar entre sí. Este tipo de estándar suele definir la consulta de saldo, la emisión total, la transferencia y una función de autorización que permite a otra dirección transferir en nombre de quien lo tiene hasta un límite definido.

En Ethereum, por ejemplo, las propuestas de estándares de capa de aplicación se llaman Ethereum Request for Comments (ERC). ERC-20 es el estándar ERC que define las interfaces básicas de los tokens fungibles, de modo que billeteras y aplicaciones en cadena puedan consultar saldos, pedir transferencias y manejar autorizaciones de una forma común.

ERC-20 no exige que un token tenga emisión fija ni prohíbe que quienes desarrollan agreguen lógica adicional como pausa, comisiones de transferencia o listas. La información de visualización como nombre, código de cotización y cantidad de decimales tampoco sustituye a la dirección del contrato para identificar un token de forma única.

La interfaz común de los tokens con número propio

Los tokens no fungibles (non-fungible token, NFT) requieren seguir cada número por separado. Los estándares correspondientes normalmente definen cómo consultar quién tiene un número, transferir un número determinado y autorizar a otra dirección a operar sobre un token o un conjunto de ellos.

Estas interfaces se implementan de forma distinta en cada red. En Ethereum, por ejemplo, ERC-721 define operaciones básicas de tenencia, transferencia y autorización de tokens con número propio, mientras los metadatos y la lista completa de números corresponden a extensiones opcionales. Adoptar ese estándar no significa que una imagen u otro contenido esté necesariamente almacenado en cadena, ni prueba que el objeto fuera de la cadena que el token representa exista realmente.

Algunos estándares también permiten que un mismo programa gestione a la vez unidades fungibles, unidades con número propio o varias copias bajo un mismo número. Sirven a necesidades de registro distintas; eso no significa que un estándar sea en general mejor que otro.

Cómo estandarizan las distintas redes

Un estándar de tokens no tiene que significar «desplegar un contrato por token, cada uno implementando la misma interfaz». Distintas blockchains pueden lograr compatibilidad mediante reglas de protocolo, un programa compartido o extensiones opcionales.

Por ejemplo, el programa de tokens de Solana ofrece en un solo lugar instrucciones de acuñación, registro de cuentas, transferencia y autorización. Cada mint registra la emisión y los permisos de cierto token, mientras billeteras y aplicaciones manejan muchos mints a través del mismo programa de tokens.

Solana también ofrece Token Extensions, un programa de tokens al que se pueden agregar funciones adicionales. Al crear un token, quien desarrolla puede elegir extensiones según lo que necesite; algunas no se pueden agregar después de la inicialización, y algunas pueden ser incompatibles entre sí. Eso muestra que «usar el mismo programa de tokens» todavía no alcanza para concluir que dos tokens se comportan igual.

Cuando el mismo nombre de estándar o una interfaz parecida aparece en varias redes, tampoco conviene suponer que direcciones, permisos y formatos de transacción sean directamente trasladables. El alcance de un estándar siempre está ligado a la red y al entorno de ejecución concretos.

Compatible no significa comportamiento idéntico

Cuando una billetera o aplicación dice que «admite un estándar», normalmente significa que puede manejar las interfaces básicas que ese estándar exige. La compatibilidad real todavía puede verse afectada por lo siguiente:

• el token no implementa por completo las funciones requeridas, o devuelve resultados distintos de lo esperado;
• el token agrega comisiones de transferencia, pausa, congelamiento o reglas de listas;
• la aplicación no admite ciertas extensiones opcionales;
• el programa receptor no puede manejar un método de transferencia determinado;
• una estructura de actualización por proxy, que cambia el código que se ejecuta detrás de un punto de entrada fijo, modificó la lógica real;
• tokens con el mismo nombre están desplegados en redes o direcciones distintas.

Por eso las pruebas de compatibilidad de interfaz deben enfrentarse al código concreto y a los resultados concretos de una llamada. Una etiqueta de «cumple el estándar» no es en sí una auditoría de seguridad, ni una garantía de que el comportamiento futuro no cambiará.

Qué no define un estándar

Un estándar de tokens normalmente no sustituye la siguiente información:

• quién puede seguir acuñando, congelando, pausando o actualizando el token;
• cómo se distribuye la cantidad total y si eso cambiará;
• qué uso práctico o demanda de mercado tiene el token;
• si el nombre, el icono y los metadatos los mantiene una fuente confiable;
• si existen las reservas, los bienes físicos o los servicios a los que el token dice corresponder;
• si quien lo tiene dispone de derechos de rescate, de gobernanza u otros derechos fuera de la cadena.

Estas preguntas requieren revisar la implementación, los permisos y los esquemas fuera de la cadena concretos. Un estándar técnico resuelve solo parte de los problemas de interacción del software; no puede cargar con la prueba de autenticidad, valor o efecto jurídico.

Preguntas frecuentes

¿Un token debe seguir un estándar?

No necesariamente. Quien desarrolla puede crear una interfaz propia, pero entonces billeteras y aplicaciones necesitan adaptación extra. Adoptar un estándar con amplio soporte normalmente facilita obtener compatibilidad básica.

¿Un número de estándar más nuevo es mejor?

No se puede juzgar así. Un estándar nuevo puede agregar funciones, pero también puede tener menos soporte, seguir cambiando o no servir para cierto uso. Hay que ver el estado de la propuesta, la adopción real y la necesidad concreta.

¿Un mismo token puede adoptar varios estándares?

Es posible. Una implementación puede admitir varias interfaces a la vez, o agregar extensiones sobre un estándar base. Si esas interfaces funcionan bien juntas igual hay que verificarlo en el código concreto.

¿Seguir un estándar garantiza que se vea en todas las billeteras?

No está garantizado. La billetera también debe admitir la red correspondiente, la versión del estándar y las funciones opcionales, y reconocer el contrato o mint correcto. Metadatos como el nombre y el icono pueden además requerir una fuente adicional.

¿Un estándar garantiza que un token es seguro?

No. Un estándar solo define interfaces comunes o requisitos de comportamiento. Fallas de código, permisos de administración, datos externos, autorizaciones de las personas y la red subyacente igual pueden generar riesgos.

Conceptos relacionados

Continúa con token cripto, contrato inteligente, blockchain y billetera de criptomonedas, o vuelve al glosario de criptomonedas.

Fuentes

• NISTIR 8301: Blockchain Networks: Token Design and Management Overview — modelos de datos de tokens, operaciones de protocolo y de cuenta, y el alcance distinto de los estándares.
• Ethereum.org: estándares de tokens — el papel de las interfaces de tokens en la compatibilidad entre billeteras, aplicaciones y programas en cadena.
• Proceso de estándares de capa de aplicación de Ethereum — la categoría ERC, los estados de las propuestas de estándar y el alcance de la interoperabilidad entre aplicaciones.
• Estándar de tokens fungibles de Ethereum ERC-20 — interfaces básicas de saldos, transferencias, autorizaciones y eventos.
• Estándar de tokens no fungibles de Ethereum ERC-721 — tenencia, transferencia, autorización y extensiones opcionales de tokens con número propio.
• Solana Docs: tokens y extensiones — programa de tokens compartido, mints, cuentas de tokens y extensiones opcionales.