FA1.2 (Tezos)

¿Qué es FA1.2 en Tezos?

FA1.2 es un estándar de tokens fungibles para contratos inteligentes en la blockchain de Tezos.

Define una interfaz común para transferir tokens, autorizar su gasto, consultar saldos y autorizaciones, y leer la oferta total de tokens.

FA1.2 está definido formalmente por la Propuesta de mejora de Tezos 7, también conocida como TZIP-7.

El estándar está diseñado específicamente para tokens fungibles, lo que significa que cada unidad de un activo FA1.2 concreto es intercambiable por cualquier otra unidad del mismo activo.

Un contrato FA1.2 puede representar un token de pago, un token de gobernanza, una criptomoneda wrapped, un activo de valor estable, un punto de fidelidad, una moneda de una aplicación u otro activo digital divisible.

FA1.2 es una interfaz para contratos inteligentes, no una criptomoneda en sí misma.

Cada token FA1.2 se crea y gestiona mediante su propio contrato inteligente de Tezos.

El contrato mantiene un registro que vincula las direcciones de las cuentas de Tezos con los saldos de tokens.

Los usuarios interactúan con el contrato para transferir tokens o autorizar a otra cuenta o aplicación a gastar en su nombre una cantidad limitada.

FA1.2 no determina el precio, la situación jurídica, la finalidad económica, la oferta máxima ni la estructura administrativa de un token.

Estas características dependen del contrato de cada token y del proyecto que lo controle.

¿Qué significa FA1.2?

FA significa Financial Application (aplicación financiera).

El número 1.2 identifica la versión de la interfaz de activos fungibles definida por TZIP-7.

El estándar se desarrolló a partir de trabajos anteriores sobre interfaces de tokens fungibles de Tezos y añadió un sistema formal de autorización para las transferencias delegadas de tokens.

El término FA1.2 suele referirse tanto al estándar como a los tokens implementados conforme a él.

Sin embargo, el componente que técnicamente sigue FA1.2 es el contrato inteligente.

Un token no pasa a ser compatible con FA1.2 por el mero hecho de que su emisor utilice ese término en un nombre, símbolo, sitio web o descripción de marketing.

El contrato desplegado debe exponer los puntos de entrada requeridos con los tipos de parámetros y el comportamiento esperados.

¿Por qué se creó FA1.2?

Los contratos inteligentes pueden definir el comportamiento de los tokens de muchas formas distintas.

Sin un estándar común, cada wallet y aplicación descentralizada necesitaría código de integración personalizado para cada token fungible.

Un token podría utilizar un nombre para las transferencias, mientras que otro podría emplear una estructura de parámetros completamente distinta.

Las consultas de saldos y los permisos de gasto también podrían comportarse de forma diferente entre contratos.

FA1.2 ofrece una interfaz predecible que reduce esta fragmentación.

Las wallets pueden preparar transferencias de tokens mediante un punto de entrada de transferencia conocido.

Las aplicaciones pueden solicitar permiso para gastar mediante un punto de entrada de aprobación conocido.

Los indexadores pueden identificar cambios en los saldos y mostrar la actividad de los tokens en un formato coherente.

Las herramientas de desarrollo pueden comprobar si un contrato expone la interfaz FA1.2 esperada.

La documentación actual de FA1.2 de Octez incluye herramientas específicas para comprobar la compatibilidad, transferir tokens, aprobar gastadores y consultar información de los tokens.

La estandarización mejora la interoperabilidad, pero no garantiza que un contrato concreto sea seguro, tenga valor o se gestione de forma honesta.

¿Cómo funciona un token FA1.2?

Un token FA1.2 se gestiona mediante un contrato inteligente de Tezos que almacena un registro de los saldos de las cuentas.

Al emitirse los tokens, el contrato asigna saldos a una o varias direcciones de cuenta.

El titular transfiere tokens llamando al contrato, en lugar de enviarlos directamente mediante el registro de saldos a nivel de protocolo de Tezos.

El contrato verifica la cuenta de origen, la cuenta de destino, la cantidad solicitada, la autorización del llamante y el saldo disponible.

Si las comprobaciones se completan correctamente, el contrato resta la cantidad del saldo de origen y la añade al saldo de destino.

Si alguna comprobación falla, la transacción se revierte y el registro permanece sin cambios.

Una cuenta también puede aprobar que otra cuenta o contrato inteligente gaste una cantidad limitada de su saldo.

La cantidad aprobada se conoce como autorización de gasto (allowance).

Normalmente, cada transferencia delegada reduce la autorización restante en la cantidad transferida.

El contrato puede proporcionar información sobre saldos, autorizaciones de gasto y oferta total mediante interfaces de consulta estandarizadas.

¿Qué es la fungibilidad?

La fungibilidad significa que las unidades individuales de un activo son intercambiables.

Una unidad de un token FA1.2 concreto tiene las mismas propiedades definidas por el contrato que otra unidad de ese token.

Por lo general, el titular no necesita hacer un seguimiento de la unidad exacta del token que ha recibido.

El registro de la cuenta almacena cantidades, no identidades únicas de tokens.

Esto hace que FA1.2 sea adecuado para activos concebidos como monedas, créditos, unidades de voto, garantías o derechos fraccionables.

FA1.2 no está diseñado para asignar una identidad única y un registro de metadatos independiente a cada unidad individual.

Los activos digitales únicos suelen implementarse mediante un estándar de tokens más flexible, diseñado para admitir tokens no fungibles.

¿Cómo se identifica un token FA1.2?

Un token FA1.2 se identifica principalmente por la dirección del contrato inteligente de Tezos que lo gestiona.

FA1.2 representa un tipo de token fungible por contrato, en lugar de utilizar numerosos ID de token para activos no relacionados.

Cuando los metadatos de FA1.2 utilizan la estructura de metadatos de tokens asociada a estándares posteriores de Tezos, el ID del token debe ser 0.

El nombre y el símbolo del token no son identificadores únicos fiables.

Distintos contratos pueden utilizar el mismo nombre, símbolo, imagen y configuración de decimales.

Un emisor malicioso también puede copiar la identidad visual de un activo legítimo.

Antes de transferir, aprobar o comprar un token FA1.2, los usuarios deben verificar la dirección completa del contrato mediante documentación fiable del proyecto.

¿Cuáles son los principales puntos de entrada de FA1.2?

La interfaz FA1.2 define puntos de entrada para transferencias, aprobaciones, consultas de saldos, consultas de autorizaciones y consultas de la oferta total.

La referencia oficial de la interfaz Octez enumera transfer, approve, getBalance, getAllowance y getTotalSupply como las principales operaciones de FA1.2.

Los contratos individuales pueden incluir puntos de entrada adicionales para acuñar, quemar, pausar, administrar, canjear u otras funciones específicas del proyecto.

Los puntos de entrada adicionales no forman parte automáticamente del estándar FA1.2.

Punto de entrada Transfer

El punto de entrada transfer mueve una cantidad de tokens especificada de una dirección a otra.

La llamada indica una dirección de origen, una dirección de destino y la cantidad que se transferirá.

Si el llamante transfiere tokens desde su propia cuenta, el contrato comprueba que la cuenta tenga suficientes tokens.

Si el llamante transfiere tokens desde otra cuenta, debe disponer de una autorización de gasto suficiente del titular de esa cuenta.

Una transferencia delegada reduce la autorización restante del gastador.

La transferencia falla si el saldo o la autorización son insuficientes.

El punto de entrada transfer de FA1.2 combina en una sola interfaz las transferencias directas del titular y las transferencias delegadas.

Punto de entrada Approve

El punto de entrada approve permite al titular de un token autorizar a un gastador a transferir una cantidad limitada de sus tokens.

El gastador puede ser la cuenta de otro usuario o un contrato inteligente.

Las aplicaciones pueden utilizar este mecanismo para cobrar pagos, aportar liquidez, bloquear garantías, completar operaciones u otras acciones autorizadas.

La aprobación no mueve los tokens de inmediato.

Crea una autorización de gasto que puede utilizarse en llamadas de transferencia posteriores.

El titular sigue siendo propietario de los tokens hasta que se efectúe una transferencia permitida.

Punto de entrada GetBalance

El punto de entrada getBalance devuelve el saldo de tokens FA1.2 asociado a una dirección especificada.

El saldo indicado se almacena en el contrato del token, no en el saldo de tez a nivel de protocolo.

Una wallet, un indexador o una aplicación puede utilizar esta información para mostrar cuántos tokens controla una cuenta.

Las herramientas actuales de Octez pueden consultar saldos compatibles off-chain sin que el usuario tenga que enviar una transacción independiente para devolver la información.

Punto de entrada GetAllowance

El punto de entrada getAllowance devuelve la cantidad restante que una dirección puede transferir desde otra.

La consulta identifica tanto al titular del token como al gastador autorizado.

Un resultado de cero significa que, en ese momento, el gastador no dispone de autorización FA1.2 restante de ese titular.

Un resultado positivo indica la cantidad máxima que aún puede transferirse con el permiso registrado.

Punto de entrada GetTotalSupply

El punto de entrada getTotalSupply devuelve el número total de unidades de tokens FA1.2 reconocidas por el contrato.

La oferta total puede cambiar si la implementación incluye funciones de acuñación o quema.

Una consulta de la oferta total no revela hasta qué punto se concentran los tokens entre los titulares.

Tampoco revela si podrán crearse más tokens en el futuro.

¿Qué es una autorización de gasto FA1.2?

Una autorización de gasto FA1.2 es un permiso limitado que el titular de un token concede a otra dirección.

Supongamos que un titular autoriza a una aplicación a gastar 100 tokens.

La aplicación puede transferir hasta 100 tokens del saldo del titular, conforme a las reglas del contrato.

Si la aplicación transfiere 30 tokens, la autorización restante normalmente pasa a ser de 70 tokens.

La aplicación no puede transferir más tokens que los disponibles en el saldo del titular, aunque la autorización registrada sea superior.

La aplicación tampoco puede utilizar la autorización para otro contrato de tokens FA1.2.

Las autorizaciones permanecen registradas on-chain hasta que se utilizan, modifican o restablecen.

Desconectar una wallet de un sitio web no cancela automáticamente una autorización.

Para revocar el permiso, el titular debe enviar una actualización de aprobación on-chain.

¿En qué se diferencia FA1.2 de un permiso de operador?

FA1.2 utiliza autorizaciones de gasto numéricas.

El titular elige la cantidad máxima que puede transferir el gastador.

Por lo general, la autorización disminuye a medida que se realizan transferencias.

Un modelo de token basado en operadores suele conceder permiso para un tipo de token concreto sin especificar una cantidad numérica decreciente.

Esta diferencia puede afectar a las interfaces de las wallets y a la seguridad de las aplicaciones.

Una aprobación FA1.2 por 50 unidades no debe mostrarse como si concediera control ilimitado.

Del mismo modo, una autorización de operador no debe interpretarse como una autorización numérica de un solo uso.

¿Por qué deben gestionarse con cuidado los cambios en las autorizaciones FA1.2?

Modificar una autorización de gasto existente para un token puede crear una condición de carrera.

Un gastador podría intentar utilizar la autorización anterior antes de que se confirme la nueva aprobación del titular.

Después podría intentar utilizar la nueva autorización cuando se active.

TZIP-7 aborda parte de este problema prohibiendo el cambio directo de una autorización distinta de cero a otra autorización distinta de cero.

Por lo general, el titular debe establecer la autorización en cero antes de asignar una nueva cantidad distinta de cero.

La especificación de autorizaciones de TZIP-7 también explica que restablecer la autorización a cero no garantiza por sí solo la protección completa frente a cualquier escenario de sincronización adversarial.

Un usuario prudente debe esperar a que la transacción que establece la autorización en cero se incluya antes de conceder una autorización nueva.

Las aplicaciones con activos de gran valor también deberían comprobar si el gastador utilizó alguna autorización mientras la actualización estaba pendiente.

Ejemplo de autorización FA1.2

Supongamos que una wallet contiene 1.000 unidades de un token FA1.2.

El titular autoriza a una aplicación descentralizada a gastar 200 unidades.

Más adelante, la aplicación transfiere 75 unidades a un contrato inteligente.

El saldo de tokens del titular se reduce a 925 unidades.

La autorización restante de la aplicación se reduce a 125 unidades.

Si la aplicación intenta transferir otras 150 unidades, la transacción falla porque la autorización restante es insuficiente.

El titular puede reducir la autorización a cero cuando la aplicación ya no necesite acceso.

¿Admite FA1.2 aprobaciones ilimitadas?

Un titular de FA1.2 puede aprobar una cantidad numérica muy elevada si el contrato la acepta.

Algunas aplicaciones pueden tratarla como una aprobación prácticamente ilimitada.

Una autorización elevada reduce la necesidad de realizar repetidamente transacciones de aprobación.

También aumenta la cantidad en riesgo si el contrato aprobado se ve comprometido, es malicioso o se utiliza incorrectamente.

Siempre que sea posible, los usuarios solo deberían aprobar la cantidad que necesiten razonablemente.

Las autorizaciones antiguas o innecesarias deberían restablecerse a cero.

¿Cómo se almacenan los saldos FA1.2?

Una implementación FA1.2 normalmente almacena los saldos en un registro dentro del contrato del token.

El registro vincula la dirección de cada titular con una cantidad de tokens expresada como número natural.

Algunas implementaciones almacenan conjuntamente los saldos y las autorizaciones en una entrada de registro estructurada.

TZIP-7 describe una estructura indexable estandarizada en la que el registro de un titular puede contener tanto su saldo como un mapa de las autorizaciones de sus gastadores.

No todas las implementaciones históricas tienen que utilizar un almacenamiento interno idéntico, siempre que su comportamiento público coincida con la interfaz requerida.

Las aplicaciones deberían interactuar mediante los puntos de entrada estándar o datos indexados fiables, en lugar de presuponer una estructura de almacenamiento privada concreta.

¿Utiliza FA1.2 ID de token?

FA1.2 es un estándar para contratos de un solo token y no utiliza ID de token para distinguir varios tipos de tokens independientes en las transferencias habituales.

Cuando los metadatos de tokens FA1.2 se representan mediante el formato compartido con estándares más recientes, el ID del token se fija en 0.

Para un contrato que necesite gestionar varios tokens fungibles distintos bajo una misma dirección, suele ser más adecuado un estándar multi-activo.

Los usuarios no deberían asumir que el ID de token 0 identifica de forma única un activo FA1.2 sin conocer también la dirección de su contrato.

¿Cómo funcionan los metadatos de FA1.2?

La interfaz original de FA1.2 se centra principalmente en el comportamiento del registro y las autorizaciones.

TZIP-7 no define por sí sola un sistema completo de metadatos de contratos.

Sus directrices actuales sobre metadatos de tokens utilizan el mismo formato general asociado al estándar multi-activo de Tezos.

El ID del token utilizado en los metadatos FA1.2 debe ser 0.

Los metadatos pueden incluir el nombre del token, el símbolo, los decimales, la descripción y otra información para mostrar.

La información del contrato también puede publicarse conforme a los metadatos de contratos TZIP-16.

TZIP-16 admite metadatos almacenados on-chain o referenciados mediante ubicaciones off-chain, como almacenamiento direccionado por contenido o servicios web.

Los metadatos ayudan a las wallets y a los exploradores a mostrar un activo, pero no controlan el registro real, salvo que el contrato los utilice explícitamente en su lógica de negocio.

¿Qué significan los decimales en un token FA1.2?

Los saldos FA1.2 se almacenan como unidades enteras expresadas en números naturales.

El campo de metadatos decimals indica a las wallets dónde colocar la coma decimal al mostrar el saldo.

Supongamos que el saldo bruto del contrato es 1.500.000 y que el token utiliza seis decimales.

Una wallet mostraría un saldo de 1,5 tokens.

El contrato inteligente sigue registrando 1.500.000 unidades mínimas.

Los decimales no determinan el precio de mercado, la oferta total ni la escasez del token.

Un valor de decimales incorrecto puede hacer que una wallet o aplicación muestre una cantidad engañosa.

¿Define FA1.2 una oferta máxima?

No, FA1.2 no exige una oferta máxima fija.

El contrato ofrece una forma de consultar la oferta total, pero el emisor puede añadir funciones personalizadas de acuñación o quema.

Un token puede comenzar con una oferta fija sin ningún método para crear más unidades.

Otro token puede permitir que un administrador, un contrato de gobernanza o un proceso protocolario definido acuñe unidades adicionales.

Antes de asumir que la oferta está limitada de forma permanente, los usuarios deberían inspeccionar el contrato desplegado y los permisos administrativos.

Una cifra de oferta publicada describe el estado actual y no necesariamente la emisión futura.

¿Exige FA1.2 la acuñación?

No, la acuñación no es uno de los puntos de entrada obligatorios de FA1.2.

Un contrato puede crear toda su oferta durante el despliegue.

También puede incluir una función de acuñación personalizada controlada por un administrador u otro contrato inteligente.

La política de acuñación debería especificar quién puede crear tokens, si existe un límite de oferta y si la autoridad puede transferirse o eliminarse.

La acuñación no autorizada o ilimitada puede diluir a los titulares existentes y alterar los mercados de tokens.

¿Exige FA1.2 la quema?

No, la quema también es opcional.

Una función de quema personalizada puede reducir permanentemente los saldos y la oferta total conforme a las reglas del contrato.

La función puede permitir que los titulares quemen sus propios tokens o estar restringida a un administrador.

Enviar tokens a una dirección inaccesible no siempre actualiza la oferta total comunicada por el contrato.

Una quema real a nivel de contrato debería reducir tanto el saldo correspondiente como el registro de la oferta total, si ese es el diseño previsto.

FA1.2 frente a tez

Tez es la criptomoneda nativa de la blockchain de Tezos.

Los tokens FA1.2 se crean y gestionan mediante contratos inteligentes.

Los saldos de tez se mantienen directamente en el protocolo de Tezos.

Los saldos FA1.2 se mantienen en el almacenamiento de cada contrato de token.

Las comisiones de transacción de Tezos suelen pagarse en tez, incluso cuando la transacción transfiere un token FA1.2.

Tener un saldo FA1.2 no proporciona automáticamente suficiente tez para pagar una transferencia de tokens o una transacción de aprobación.

La documentación de tokens de Tezos explica la diferencia entre tez a nivel de protocolo y los tokens representados mediante registros de contratos inteligentes.

FA1.2 frente a FA2

FA1.2 está diseñado específicamente para un token fungible gestionado por un contrato inteligente.

FA2 es una interfaz de tokens más reciente y flexible.

FA2 puede admitir tokens fungibles, NFT, activos intransferibles, modelos híbridos y varios ID de token en un solo contrato.

FA1.2 utiliza autorizaciones numéricas de gasto.

El estándar FA2 suele utilizar permisos de operador específicos para cada token, en lugar de autorizaciones numéricas decrecientes.

FA1.2 ofrece estructuras de transferencia independientes para una sola solicitud, mientras que FA2 utiliza estructuras de transferencia y consulta de saldos por lotes.

FA2 también ofrece un soporte más explícito para políticas de transferencia personalizadas.

Las directrices actuales de SmartPy recomiendan FA2 para los contratos de tokens nuevos, ya que admite una gama más amplia de casos de uso.

Esta recomendación no invalida los contratos FA1.2 existentes.

Las herramientas actuales de Octez siguen ofreciendo soporte específico para FA1.2.

FA1.2 frente a FA2.1

FA2.1 es una evolución propuesta de la familia FA2 que incluye funciones como autorizaciones finitas, eventos, vistas on-chain y funcionalidades relacionadas con tickets.

Su concepto de autorización finita responde a un caso de uso conocido de FA1.2 y mantiene la estructura multi-activo más amplia de FA2.

La documentación actual de SmartPy describe FA2.1 como un borrador.

Los contratos FA1.2 existentes no cambian automáticamente cuando se proponen nuevos estándares.

El soporte de wallets y aplicaciones debe verificarse por separado para cada estándar.

¿Se puede convertir un token FA1.2 a FA2?

Normalmente, un contrato FA1.2 no puede transformarse en FA2 con solo cambiarle la etiqueta.

Los dos estándares utilizan interfaces y modelos de permisos diferentes.

Un proyecto que quiera migrar puede desplegar un contrato FA2 nuevo y crear un proceso de conversión controlado.

El proceso puede bloquear o quemar los tokens antiguos y emitir otros nuevos equivalentes.

Otro diseño puede tomar una instantánea de los saldos y distribuir activos sustitutivos.

La migración conlleva riesgos técnicos, de gobernanza, de seguridad y de experiencia de usuario.

Los usuarios deben verificar el contrato oficial de migración y evitar enlaces no solicitados que afirmen intercambiar tokens antiguos.

¿Puede FA1.2 admitir activos cripto wrapped?

Sí, un contrato FA1.2 puede representar una criptomoneda wrapped en Tezos.

Un token wrapped es un activo de un contrato inteligente independiente que pretende seguir el valor de otro activo mediante custodia, un bridge, acuñación o un mecanismo de canje.

La interfaz FA1.2 estandariza las transferencias y las autorizaciones, pero no garantiza que el token wrapped esté totalmente respaldado.

Los usuarios deben evaluar las reservas, las condiciones de canje, los controles del custodio, la seguridad del bridge, la autoridad de acuñación y las pruebas de respaldo.

Las directrices oficiales de Tezos sobre tokens wrapped destacan que un activo wrapped es técnicamente distinto de la criptomoneda original.

¿Puede FA1.2 admitir tokens de valor estable?

Sí, un token FA1.2 puede diseñarse para seguir el valor de una moneda fiduciaria, una materia prima, una criptomoneda u otro activo de referencia.

FA1.2 no mantiene por sí mismo el valor objetivo.

La estabilidad del precio depende del emisor, las garantías, las reservas, el mecanismo de canje, la liquidez del mercado, el sistema de oráculos y el diseño económico.

Un token puede cumplir con FA1.2 y, aun así, perder la paridad prevista.

El cumplimiento técnico no debe considerarse una prueba de la calidad de las reservas ni de la estabilidad del precio.

¿Cómo muestran las wallets los tokens FA1.2?

Una wallet puede identificar un contrato FA1.2, consultar el saldo del usuario y leer los metadatos disponibles.

Puede mostrar el nombre y el símbolo del token, el saldo ajustado según los decimales, el logotipo y el historial de transacciones.

Algunas wallets utilizan indexadores en lugar de leer directamente cada contrato.

La documentación de indexadores de Tezos explica que estos organizan la información de los tokens FA1.2 y FA2 para facilitar el acceso desde las aplicaciones.

Es posible que un token no aparezca automáticamente si sus metadatos faltan, no son compatibles o aún no se han indexado.

Que un token no aparezca en la wallet no significa necesariamente que el saldo on-chain sea cero.

Los usuarios pueden verificar la información del contrato y del registro mediante herramientas blockchain compatibles.

¿Cómo utilizan FA1.2 las aplicaciones descentralizadas?

Una aplicación descentralizada puede solicitar autorización para gastar una cantidad definida de un token FA1.2.

Una vez aprobada, la aplicación puede llamar al contrato del token para transferir tokens desde el saldo del titular.

Este patrón puede utilizarse para depósitos, swaps, garantías, suscripciones, subastas, préstamos, pagos y otras actividades cripto.

La aplicación no debería solicitar una autorización superior a la que necesita razonablemente.

Antes de firmar, el usuario debería verificar el contrato del token, la dirección del gastador y la cantidad aprobada.

La aplicación también debería gestionar de forma segura los saldos y autorizaciones insuficientes, así como las aprobaciones modificadas.

¿Se pueden agrupar las transferencias FA1.2?

El punto de entrada principal de transferencia de FA1.2 describe un origen, un destino y una cantidad por llamada.

Sin embargo, una operación de Tezos puede contener varias llamadas a contratos.

Las herramientas actuales de Octez admiten comandos de transferencia por lotes que abarcan un único origen y varios destinatarios en contratos FA1.2.

La agrupación puede facilitar las distribuciones y las operaciones de tesorería.

Si se produce un error en una secuencia atómica, la operación relacionada puede fallar en lugar de dejar un resultado parcialmente completado.

Los lotes grandes también pueden consumir una cantidad considerable de gas y requieren pruebas cuidadosas.

Errores habituales del estándar FA1.2

TZIP-7 define errores asociados a autorizaciones insuficientes y cambios de autorización no seguros.

Una transferencia puede fallar si el titular no dispone de suficientes tokens.

Una transferencia delegada puede fallar si la autorización del gastador es inferior a la cantidad solicitada.

Una aprobación puede fallar si intenta sustituir directamente una autorización distinta de cero por otra también distinta de cero.

Las implementaciones individuales pueden utilizar nombres de error adicionales para administración, pausas, acuñación, quema u otras funciones personalizadas.

Las aplicaciones deberían mostrar errores con un lenguaje que ayude a los usuarios a entender si el problema está relacionado con el saldo, la autorización, los permisos o las políticas del contrato.

Riesgos de seguridad de los tokens FA1.2

La compatibilidad con FA1.2 no demuestra que un contrato inteligente sea seguro.

Un contrato puede exponer los puntos de entrada correctos y, aun así, contener una lógica interna defectuosa o maliciosa.

Un administrador puede tener capacidad para acuñar oferta nueva, pausar transferencias, congelar cuentas, cambiar metadatos o sustituir direcciones importantes.

Un gastador autorizado que se vea comprometido puede transferir tokens hasta el límite de la autorización disponible.

Un nombre y símbolo copiados pueden hacer que un token fraudulento parezca legítimo.

Un token wrapped puede quedar insuficientemente garantizado aunque su registro FA1.2 funcione correctamente.

Los usuarios deberían examinar el código fuente del contrato, la información de auditoría, la administración, los controles de oferta, las autorizaciones y las reglas de canje.

Riesgo de seguridad de las autorizaciones

Una autorización concede a otra dirección autoridad directa sobre parte del saldo de tokens del titular.

Una aplicación maliciosa puede utilizarla inmediatamente después de recibir la aprobación.

Un contrato comprometido puede utilizar los permisos concedidos antes del incidente.

Una autorización elevada sin utilizar puede permanecer activa durante mucho tiempo.

Los usuarios deben revisar cuidadosamente la dirección del gastador y evitar aprobar transacciones que no entiendan.

Las autorizaciones que ya no sean necesarias deberían restablecerse a cero.

Para conceder o revocar una autorización FA1.2 nunca se necesitan claves privadas ni frases de recuperación.

Riesgo de control administrativo

Los contratos FA1.2 personalizados pueden incluir un administrador con privilegios.

El administrador puede controlar la acuñación, la quema, las pausas, la congelación de cuentas, las listas negras, las comisiones o las actualizaciones del contrato.

Estos poderes pueden facilitar las operaciones de seguridad y cumplimiento.

También pueden crear riesgos de centralización y abuso.

Los usuarios deberían averiguar si el administrador es una cuenta individual, un contrato multifirma, un sistema de gobernanza o una regla inmutable.

También deberían comprobar si los poderes administrativos pueden transferirse o eliminarse de forma permanente.

Riesgo de oferta y dilución

Un token puede mostrar una oferta actual limitada y, aun así, conservar la capacidad de acuñar tokens ilimitadamente en el futuro.

Una emisión adicional puede reducir la proporción de la oferta total que representa cada unidad existente.

Un límite de oferta solo es efectivo si lo aplica el contrato desplegado o una restricción de gobernanza igual de sólida.

Las promesas publicadas en sitios web o redes sociales no invalidan los permisos de acuñación on-chain.

Los usuarios deberían distinguir entre la oferta en circulación, la oferta total y la posible oferta futura.

Riesgo de tokens falsos

Cualquiera puede desplegar un contrato inteligente de Tezos con un nombre o símbolo de token conocido.

Los metadatos de una wallet pueden hacer que un token no relacionado parezca similar a un activo reconocido.

La dirección del contrato es más fiable que el nombre mostrado.

Los usuarios deberían obtener la dirección verificada del contrato a través de fuentes primarias fiables del proyecto.

Un token no solicitado que aparezca en una wallet no debe considerarse valioso sin una verificación independiente.

Los enlaces incluidos en metadatos de tokens desconocidos pueden dirigir a sitios web de phishing.

Riesgo de los contratos inteligentes

Un error de programación puede permitir transferencias no autorizadas, saldos incorrectos, tokens bloqueados o errores en el registro de la oferta.

El cumplimiento formal de una interfaz no demuestra que todas las ramas de la lógica interna funcionen correctamente.

Una auditoría independiente puede reducir el riesgo, pero no garantiza que no haya vulnerabilidades.

Los contratos con lógica compleja de acuñación, canje, comisiones, actualización o garantías requieren un análisis que vaya más allá de los puntos de entrada básicos de FA1.2.

Las directrices de Tezos sobre los riesgos de los tokens recomiendan comprobar la disponibilidad del código fuente, las auditorías, los límites de oferta y las reglas de transferencia.

Seguridad de las claves privadas y las wallets

La titularidad de los tokens FA1.2 depende, en última instancia, del control de la cuenta de Tezos autorizada para gestionar el saldo registrado.

Un atacante que obtenga la clave privada de la cuenta puede firmar transferencias y aprobaciones.

Ningún contrato legítimo necesita la frase de recuperación del usuario para mostrar un saldo o preparar una transacción.

La documentación de gestión de claves de Octez destaca la importancia del almacenamiento seguro y las prácticas de firma para las operaciones con tez y tokens FA.

Antes de aprobar una operación, los usuarios deberían comprobar los detalles de la transacción en el dispositivo de firma.

Cómo verificar un token FA1.2

Confirma la dirección completa del contrato de Tezos mediante una fuente primaria fiable.

Comprueba si el contrato expone la interfaz FA1.2 requerida.

Revisa el nombre, el símbolo, los decimales y la oferta total del token.

Averigua quién puede acuñar, quemar, pausar, congelar o actualizar el token.

Inspecciona las autorizaciones existentes antes de interactuar con una aplicación nueva.

Si hay activos de valor, consulta evaluaciones de seguridad independientes.

En el caso de tokens wrapped o de valor estable, verifica las reservas y las reglas de canje por separado de la interfaz FA1.2.

No te fíes de un símbolo, un icono de wallet o un mensaje en redes sociales como prueba de autenticidad.

Buenas prácticas de desarrollo para FA1.2

Los desarrolladores deberían seguir exactamente los tipos de puntos de entrada y el comportamiento de autorización de TZIP-7.

Las transferencias directas del titular y las transferencias basadas en autorizaciones deben probarse por separado.

Las pruebas deberían abarcar saldos cero, saldos insuficientes, autorizaciones insuficientes y transferencias de valor cero.

Los cambios en las autorizaciones deberían respetar la protección estándar frente a las actualizaciones directas de un valor distinto de cero a otro también distinto de cero.

Si se incluyen funciones de acuñación, quema, pausa y administración, deben documentarse con claridad.

Siempre que sea práctico, los metadatos deberían utilizar almacenamiento estable y protegido frente a alteraciones.

Las aplicaciones deberían utilizar la identidad del llamante correspondiente a la interacción inmediata con el contrato, en lugar de confiar en un origen de transacción no relacionado.

Los desarrolladores deberían probar las integraciones con wallets, indexadores y herramientas de Octez.

Antes de desplegar contratos con activos de gran valor, deberían someterse a una revisión de seguridad independiente.

Ideas erróneas habituales sobre FA1.2

FA1.2 no es la criptomoneda nativa de Tezos.

FA1.2 no es un token ni un proyecto concreto.

Es un estándar que pueden implementar los contratos de tokens fungibles.

FA1.2 no está diseñado principalmente para admitir NFT únicos.

El cumplimiento de FA1.2 no garantiza una oferta fija.

La acuñación y la quema no son puntos de entrada obligatorios del estándar.

Una aprobación no transfiere tokens inmediatamente.

Desconectar una wallet no revoca una autorización on-chain.

El nombre o símbolo de un token no identifica de forma única su contrato.

Que FA2 sea el estándar preferido para los nuevos desarrollos no elimina los contratos FA1.2 existentes.

Una interfaz FA1.2 correcta no garantiza que el token sea seguro, esté respaldado, pueda transferirse en cualquier circunstancia o tenga valor financiero.

Preguntas frecuentes

¿Qué es FA1.2 en Tezos?

FA1.2 es un estándar de contratos inteligentes para tokens fungibles de Tezos, definido por TZIP-7.

¿Qué significa FA en FA1.2?

FA significa Financial Application.

¿FA1.2 es una criptomoneda?

No, es una interfaz utilizada para crear y gestionar criptomonedas fungibles y otros activos tokenizados.

¿Sigue siendo compatible FA1.2?

Sí, la documentación actual de Octez sigue ofreciendo herramientas específicas para la compatibilidad, las transferencias, las aprobaciones y las consultas de FA1.2.

¿Es FA1.2 el estándar de tokens más reciente de Tezos?

No, FA2 es más reciente y flexible, mientras que FA2.1 se describe actualmente como un borrador de evolución de la familia FA2.

¿Deberían los desarrolladores crear nuevos tokens FA1.2?

Las directrices actuales de desarrollo de Tezos suelen recomendar FA2 para los nuevos contratos de tokens, aunque los requisitos del proyecto y las integraciones heredadas pueden variar.

¿Puede FA1.2 crear NFT?

FA1.2 está diseñado para tokens fungibles, no para activos únicos no fungibles.

¿Puede un contrato FA1.2 gestionar muchos tipos de tokens?

El estándar representa un tipo de token fungible por contrato.

¿Cómo se identifica un token FA1.2?

Se identifica principalmente por la dirección del contrato de Tezos que gestiona su registro.

¿Qué ID de token utiliza FA1.2 para los metadatos?

El ID de token utilizado en el formato compartido de metadatos de tokens debe ser 0.

¿Dónde se almacenan los saldos FA1.2?

Se registran en el registro de almacenamiento del contrato inteligente FA1.2.

¿Qué es el punto de entrada transfer de FA1.2?

Mueve una cantidad especificada desde una dirección de origen a una dirección de destino después de comprobar el saldo y la autorización.

¿Qué es el punto de entrada approve de FA1.2?

Concede a un gastador permiso para transferir hasta una cantidad especificada del saldo de tokens del titular.

¿Qué es una autorización de gasto FA1.2?

Es la cantidad restante que una dirección aprobada puede transferir del saldo del titular de un token.

¿Disminuye una autorización después de utilizarse?

Sí, una transferencia delegada normalmente reduce la autorización restante en la cantidad transferida.

¿Conectar una wallet crea una autorización?

No, la autorización solo se crea cuando el usuario firma y envía la operación de aprobación correspondiente.

¿Desconectar una wallet revoca una autorización?

No, el titular debe actualizar la autorización on-chain, normalmente estableciéndola en cero.

¿Puedo cambiar directamente una autorización distinta de cero por otra?

TZIP-7 prohíbe los cambios directos de una autorización distinta de cero a otra para proteger frente a una condición de carrera conocida.

¿Cómo debería modificarse una autorización?

El titular debería establecer primero la autorización en cero, esperar a que se confirme y después asignar la nueva cantidad tras comprobar si se han producido gastos intermedios.

¿Exige FA1.2 la acuñación?

No, la función de acuñación es opcional y depende de cada implementación.

¿Exige FA1.2 la quema?

No, la quema también es una función personalizada opcional.

¿Garantiza FA1.2 un límite de oferta?

No, los usuarios deben revisar la autoridad de acuñación y las reglas de oferta reales del contrato.

¿Cómo puedo consultar un saldo FA1.2?

Una wallet compatible, un indexador, una consulta del contrato o un comando de saldo FA1.2 de Octez pueden leer el saldo del registro.

¿Cómo puedo consultar una autorización FA1.2?

La interfaz getAllowance o un indexador compatible pueden indicar el permiso restante entre un titular y un gastador.

¿Cómo puedo consultar la oferta total de FA1.2?

La interfaz getTotalSupply devuelve la oferta actual registrada por el contrato del token.

¿Las comisiones de transacción FA1.2 se pagan con el token?

Las comisiones de transacción del protocolo de Tezos suelen pagarse en tez.

¿Puede FA1.2 representar una criptomoneda wrapped?

Sí, pero el cumplimiento de FA1.2 no garantiza las reservas, el canje ni la seguridad del bridge.

¿Puede FA1.2 representar un activo de valor estable?

Sí, pero el estándar no garantiza por sí mismo que el activo mantenga el precio previsto.

¿Puede un administrador FA1.2 congelar tokens?

Una implementación personalizada puede incluir funciones de congelación o pausa, aunque el estándar no las exige.

¿Se puede migrar un token FA1.2 a FA2?

Un proyecto puede crear un proceso de migración independiente, pero el contrato antiguo no pasa automáticamente a ser compatible con FA2.

¿Es seguro un token FA1.2 por seguir un estándar?

No, el cumplimiento del estándar mejora la compatibilidad de la interfaz, pero no garantiza la seguridad del código, una administración honesta, respaldo, liquidez ni valor.

Conclusión

FA1.2 es el estándar de tokens fungibles de Tezos definido formalmente por TZIP-7.

Establece una interfaz común para transferencias, aprobaciones, saldos, autorizaciones y consultas de la oferta total.

Un contrato inteligente FA1.2 mantiene un registro que vincula direcciones de Tezos con saldos de tokens intercambiables.

Su sistema de autorizaciones numéricas permite a los titulares autorizar a aplicaciones u otras cuentas a transferir una cantidad limitada de tokens.

Las autorizaciones requieren una gestión cuidadosa porque permanecen activas on-chain y pueden generar riesgos de condición de carrera o de compromiso del contrato.

FA1.2 no exige acuñación, quema, pausa, congelación, administración de metadatos ni una oferta máxima fija.

Estas funciones dependen de la implementación de cada contrato.

FA2 es ahora el estándar más flexible para desarrollar nuevos tokens en Tezos, pero los contratos FA1.2 siguen siendo compatibles y continúan utilizándose.

Antes de interactuar con un token FA1.2 desconocido, los usuarios deberían verificar la dirección del contrato, la cantidad autorizada, los controles de oferta, la autoridad administrativa, los metadatos, el historial de auditorías y las condiciones de canje.

La estandarización de FA1.2 mejora la compatibilidad entre wallets, aplicaciones, indexadores y herramientas de desarrollo de Tezos, pero no garantiza que un token sea seguro, legítimo, líquido o valioso.