Buy Crypto
Markets
Spot
FuturesBTC
Earn
Event Center
More
0-Fee Fest
ERC-20: ¿Qué es ERC-20?ERC-20 es un estándar de tokens de Ethereum que define una interfaz común para activos cripto fungibles creados mediante contratos inteligentes.Fungible significa que las unidades equivERC-20: ¿Qué es ERC-20?ERC-20 es un estándar de tokens de Ethereum que define una interfaz común para activos cripto fungibles creados mediante contratos inteligentes.Fungible significa que las unidades equiv

ERC-20

2026/10/13 15:30
#Intermediate
Humanity
H$0.05615-1.33%
PX
PX$0.0112+0.90%
TokenFi
TOKEN$0.001848-0.37%
PortugalNationalTeam
POR$0.06725-1.98%
ELYSIA
EL$0.001551+0.32%

¿Qué es ERC-20?

ERC-20 es un estándar de tokens de Ethereum que define una interfaz común para activos cripto fungibles creados mediante contratos inteligentes.

Fungible significa que las unidades equivalentes de un mismo token son intercambiables según las reglas contables del contrato.

Por ejemplo, una unidad completa de un token ERC-20 normal tiene las mismas propiedades definidas por el contrato que otra unidad completa de ese token.

La especificación oficial de ERC-20 define funciones para consultar la oferta y los saldos de tokens, transferirlos y autorizar a terceros a gastarlos.

También define eventos estandarizados que permiten a las carteras y aplicaciones observar transferencias y cambios en las aprobaciones.

ERC-20 es un estándar Final de Ethereum Request for Comments y sigue siendo la principal base técnica de los tokens fungibles en los ecosistemas compatibles con Ethereum.

El estándar mejora la interoperabilidad, ya que las carteras, los contratos inteligentes, los exploradores de blockchain, los sistemas de custodia y otras aplicaciones cripto pueden utilizar los mismos métodos básicos para muchos tokens distintos.

ERC-20 no determina el precio de un token, su política de oferta, clasificación legal, utilidad, respaldo mediante garantías, derechos de gobernanza ni calidad como inversión.

¿Qué significa ERC?

ERC son las siglas de Ethereum Request for Comments.

Un ERC describe un estándar o una convención de nivel de aplicación que los desarrolladores pueden implementar en contratos inteligentes de Ethereum y software relacionado.

El número 20 identifica la propuesta que introdujo esta interfaz para tokens fungibles.

No se refiere al número de tokens, decimales, redes admitidas ni funciones del contrato.

ERC-20 también suele denominarse EIP-20, ya que el documento forma parte del proceso de Ethereum Improvement Proposal.

¿Por qué se creó ERC-20?

Antes de que existiera un estándar compartido para tokens fungibles, cada contrato inteligente podía tener nombres y reglas diferentes para consultar saldos, transferir tokens y delegar su gasto.

Una cartera necesitaba código de integración personalizado para cada token.

Una aplicación descentralizada no podía suponer de forma segura que dos contratos de tokens admitieran las mismas operaciones.

ERC-20 creó una interfaz común mínima que permite a una aplicación interactuar con muchos tokens fungibles.

Esta interoperabilidad ayudó a que los saldos de tokens pudieran utilizarse en pagos, gobernanza, préstamos, sistemas de liquidez, bóvedas, juegos, programas de recompensas y otras aplicaciones cripto.

El estándar sigue siendo deliberadamente limitado para que los desarrolladores puedan añadir comportamientos especializados sin cambiar su interfaz básica.

Cómo funciona ERC-20

Un token ERC-20 está controlado por un contrato inteligente desplegado en Ethereum o en una blockchain compatible.

El contrato registra cuántas unidades de token posee cada dirección.

También registra la oferta total de tokens y las autorizaciones que los titulares han concedido a quienes pueden gastarlos.

Cuando se realiza una transferencia válida, el contrato reduce el saldo del remitente y aumenta el del destinatario.

El contrato emite un evento

Transfer
para que el software externo pueda observar el movimiento.

Cuando un titular autoriza a un gastador, el contrato actualiza una autorización y emite un evento

Approval
.

Los nodos de la blockchain ejecutan las reglas del contrato y verifican que cada cambio de estado aceptado sea válido.

El contrato del token no mantiene una blockchain independiente, ya que opera dentro del estado y del modelo de seguridad de la red anfitriona.

Funciones principales de ERC-20

La interfaz ERC-20 obligatoria incluye seis funciones principales.

Son

totalSupply
,
balanceOf
,
transfer
,
allowance
,
approve
y
transferFrom
.

El estándar también describe las funciones opcionales de metadatos

name
,
symbol
y
decimals
.

La acuñación, la quema, la pausa, los impuestos, la votación, la congelación y los límites de oferta no son obligatorios en la interfaz básica.

Un token puede añadir estas funciones mediante lógica personalizada o extensiones estandarizadas.

La función totalSupply

La función

totalSupply
devuelve el número de unidades de token incluidas actualmente en la oferta declarada por el token.

El valor se expresa en la unidad interna más pequeña del token.

No indica automáticamente la oferta máxima posible.

Un contrato puede permitir acuñar más tokens en el futuro aunque la oferta total actual sea muy inferior a un máximo declarado.

Un token también puede admitir la quema, que puede reducir la oferta total actual.

Los usuarios deben revisar los permisos de acuñación y los controles de oferta, en lugar de interpretar

totalSupply
como prueba de escasez permanente.

La función balanceOf

La función

balanceOf
devuelve el saldo del token registrado para una dirección concreta.

El resultado se expresa en la unidad interna más pequeña del token.

Normalmente, el saldo que muestra una cartera se calcula dando formato a este entero según la configuración decimal del token.

La función informa únicamente del saldo dentro de un contrato de token.

No incluye tokens con nombres similares creados en otras direcciones de contrato o redes.

Algunos tokens inusuales pueden modificar los saldos mediante rebases u otra lógica contable sin emitir una transferencia ordinaria para cada titular.

La función transfer

La función

transfer
mueve un importe determinado del saldo de quien la llama a un destinatario.

Quien realiza la llamada debe tener suficientes tokens para completar la operación.

Una transferencia satisfactoria debe emitir un evento

Transfer
.

La especificación ERC-20 exige que una transferencia de valor cero se trate como una transferencia normal y emita el evento.

Según el estándar, la función devuelve un valor booleano que indica si se ha completado correctamente.

Las aplicaciones no deben suponer que nunca puede devolverse

false
.

Muchas implementaciones modernas revierten la transacción en caso de error en lugar de devolver

false
, pero las integraciones deben tener en cuenta el comportamiento del token concreto.

La función approve

La función

approve
permite al titular de un token establecer cuántos tokens puede transferir un gastador desde su saldo.

El gastador no recibe los tokens inmediatamente.

En su lugar, el contrato registra una autorización que el gastador puede utilizar más adelante mediante

transferFrom
.

La aprobación se aplica a un titular, un gastador y un contrato de token.

Una aprobación en una red o contrato de token no autoriza automáticamente el gasto en otra parte.

Los usuarios deben tratar las transacciones de aprobación como permisos financieros, no como conexiones inocuas a una cartera.

La función allowance

La función

allowance
informa de cuántos tokens está autorizado actualmente un gastador a transferir desde el titular.

El valor puede disminuir cuando el gastador utiliza

transferFrom
.

El titular puede actualizar el importe mediante otra transacción de aprobación.

Algunas implementaciones tratan el entero sin signo de valor máximo como una aprobación ilimitada y quizá no reduzcan ese valor después de cada transferencia.

Una aprobación ilimitada sigue siendo peligrosa mientras el gastador mantenga el acceso y el titular tenga saldo de tokens.

Los usuarios deben revisar y revocar los permisos que ya no necesiten.

La función transferFrom

La función

transferFrom
permite a un gastador aprobado transferir tokens del titular a un destinatario.

El gastador debe disponer de autorización suficiente y el titular debe tener saldo suficiente.

Una llamada satisfactoria suele reducir la autorización disponible, salvo que la implementación la considere ilimitada.

La función debe emitir un evento

Transfer
para el movimiento de los tokens.

Este modelo de transferencia delegada permite que los contratos inteligentes cobren pagos, acepten depósitos, bloqueen garantías o realicen otras acciones autorizadas.

También genera riesgos, porque un gastador malicioso o comprometido puede utilizar la autorización restante sin pedir al titular que apruebe cada transferencia.

Eventos ERC-20

El estándar ERC-20 define los eventos

Transfer
y
Approval
.

Los eventos son registros de transacciones que las aplicaciones off-chain pueden indexar de forma eficiente.

Las carteras, las herramientas de análisis, los sistemas contables y los exploradores de blockchain utilizan estos registros para seguir la actividad de los tokens.

Los eventos siempre deben interpretarse junto con la dirección del contrato que los ha emitido.

Un contrato malicioso puede utilizar nombres de eventos conocidos sin representar un token auténtico o valioso.

El evento Transfer

El evento

Transfer
registra al remitente, al destinatario y el importe del token.

Las transferencias normales utilizan direcciones de remitente y destinatario distintas de cero.

La creación de tokens suele representarse mediante una transferencia desde la dirección cero al destinatario.

La destrucción de tokens suele representarse mediante una transferencia del titular a la dirección cero.

La especificación ERC-20 exige que los tokens recién creados generen un evento

Transfer
desde la dirección cero cuando la implementación crea oferta.

Observar un evento de acuñación no demuestra que sea imposible acuñar más tokens en el futuro.

El evento Approval

El evento

Approval
registra al titular, al gastador y el importe autorizado.

Las aplicaciones pueden utilizarlo para seguir los cambios en la autoridad de gasto delegada.

Una aprobación no transfiere tokens ni cambia por sí sola la titularidad.

Permite que el gastador utilice

transferFrom
dentro del importe autorizado.

Revocar una autorización no revierte las transferencias realizadas mientras el permiso estaba activo.

Nombre y símbolo ERC-20

Las funciones

name
y
symbol
proporcionan información legible sobre el token.

El nombre puede describir el activo, mientras que el símbolo ofrece una etiqueta más breve para mostrarlo.

Ambas funciones son opcionales en la especificación ERC-20 original.

Los nombres y símbolos no son únicos.

Cualquiera puede desplegar un token que copie el nombre y el símbolo de otro activo.

Las carteras y los usuarios deben verificar la dirección completa del contrato y la red blockchain, en lugar de confiar únicamente en la marca.

¿Qué son los decimales ERC-20?

La función opcional

decimals
indica a las aplicaciones cómo presentar las unidades más pequeñas del token de forma legible.

Un token con 18 decimales divide su cantidad entera interna entre 10 elevado a 18 para mostrarla de forma estándar.

Por ejemplo, un importe interno de 1.000.000 de unidades representa un token cuando este utiliza seis decimales.

Los decimales no convierten el saldo en blockchain en un número de coma flotante.

Los contratos inteligentes realizan los cálculos de los tokens con enteros.

El valor decimal afecta a la visualización y la denominación, no al modelo aritmético subyacente.

Dieciocho decimales son habituales y constituyen el valor predeterminado de la implementación ERC-20 de OpenZeppelin actual, pero los tokens ERC-20 pueden utilizar otros valores.

Modelos de oferta ERC-20

ERC-20 no prescribe cómo debe crearse la oferta de tokens.

Un token de oferta fija puede acuñar toda su oferta durante el despliegue y no ofrecer ninguna función posterior de acuñación.

Un token con límite puede permitir la acuñación hasta alcanzar un máximo definido por el contrato.

Un token sin límite puede permitir que una cuenta autorizada o un proceso del protocolo cree unidades adicionales sin un máximo permanente.

Un token algorítmico puede ajustar su oferta según condiciones programadas.

Un token wrapped puede emitir unidades cuando se deposita un activo subyacente y quemarlas cuando se retira ese activo.

La guía oficial sobre la oferta ERC-20 explica que la lógica de oferta debe añadirse a la implementación básica mediante un mecanismo de acuñación adecuado.

Acuñación de tokens ERC-20

La acuñación crea nuevas unidades de token y aumenta la oferta total.

La interfaz ERC-20 básica no define una función pública de acuñación ni especifica quién puede llamarla.

Un token puede limitar la acuñación a un administrador, un proceso de gobernanza, un bridge, un sistema de staking, una bóveda u otra autoridad definida por el contrato.

Unos permisos de acuñación inseguros pueden diluir a los titulares existentes o invalidar las hipótesis sobre las garantías.

Los usuarios deben comprobar si se puede acuñar, quién controla esa función, si existe un límite y si se puede actualizar la implementación.

Las afirmaciones de que un token tiene una oferta fija deben verificarse mediante la lógica del contrato desplegado y sus permisos privilegiados.

Quema de tokens ERC-20

La quema destruye unidades de token y normalmente reduce la oferta total.

El estándar básico no exige que los titulares dispongan de una función pública de quema.

Una implementación puede permitir a los titulares quemar sus propios tokens o a los gastadores aprobados quemar tokens mediante una autorización.

Otros sistemas solo queman tokens durante el canje, la liquidación o las operaciones del protocolo.

Enviar tokens a una dirección inaccesible no siempre equivale a quemarlos mediante el contrato, ya que la oferta total declarada puede seguir sin cambios.

Los usuarios deben examinar la lógica real de quema del token antes de interpretar los datos de oferta.

Aprobaciones ERC-20 y condición de carrera de las autorizaciones

Cambiar directamente una autorización existente distinta de cero por otro importe distinto de cero puede crear un riesgo relacionado con el orden de las transacciones.

Un gastador puede utilizar la autorización antigua antes de que se confirme la nueva aprobación del titular y recibir después la nueva autorización.

La especificación ERC-20 original señala que las interfaces de usuario deberían establecer primero la autorización en cero antes de asignar otro importe distinto de cero.

El propio contrato del token no debería exigir esta secuencia, ya que reduciría la compatibilidad con aplicaciones antiguas.

Reducir o aumentar una autorización mediante funciones auxiliares diseñadas cuidadosamente puede mejorar la experiencia de uso, pero la compatibilidad varía entre implementaciones.

Los usuarios deben evitar mantener autorizaciones superiores a las que una aplicación necesita razonablemente.

Aprobaciones ilimitadas de tokens

Una aprobación ilimitada suele establecer la autorización en el valor máximo que admite un entero sin signo de 256 bits.

Este método reduce la necesidad de enviar una nueva aprobación antes de cada interacción.

También concede al gastador autoridad continuada sobre los saldos actuales y futuros de ese token.

Si se explota el contrato del gastador, se actualiza de forma maliciosa o queda bajo el control de un administrador comprometido, la autorización puede utilizarse para retirar los tokens del titular.

Conviene sopesar la comodidad frente al importe y la duración del permiso.

Una autorización limitada puede reducir la pérdida máxima derivada del compromiso de un gastador.

¿Qué es ERC-2612 Permit?

ERC-2612 es una extensión que permite al titular de un token ERC-20 crear una autorización mediante un mensaje firmado.

Otra cuenta o contrato inteligente puede enviar on-chain el permiso firmado.

Esto puede combinar una aprobación y una acción de una aplicación en un único flujo para el usuario.

La especificación oficial de ERC-2612 Permit añade

permit
,
nonces
y
DOMAIN_SEPARATOR
a ERC-20.

Cada permiso aceptado consume un nonce para evitar normalmente que se reutilice la misma firma.

Una fecha límite restringe el periodo de validez de la firma.

La compatibilidad con Permit es opcional y no forma parte de la interfaz ERC-20 básica original.

Riesgos de las firmas Permit

Una firma Permit puede autorizar el gasto de tokens, aunque firmarla no envíe inmediatamente una transacción on-chain desde la cuenta del titular.

Los sitios de phishing pueden presentar un Permit como un inicio de sesión, una verificación o un mensaje sin consecuencias que no requiere comisiones de gas.

El gastador puede enviar más adelante un Permit firmado válido y utilizar la autorización resultante antes de que venza.

Antes de firmar, los usuarios deben revisar el token, el gastador, el importe, la red, el nonce y la fecha de vencimiento.

Una solicitud de firma no debe considerarse segura únicamente porque la cartera indique que no requiere pagar gas.

Las carteras de contratos pueden necesitar compatibilidad adicional para validar firmas, más allá del patrón básico de cuenta de propiedad externa.

¿Admite ERC-20 funciones de retorno automáticas del destinatario?

Las funciones de transferencia ERC-20 básicas no exigen que un contrato inteligente receptor confirme los tokens.

Por tanto, una transferencia puede completarse aunque el contrato destinatario no tenga ninguna función para registrar o devolver los tokens.

Esto puede dejar activos atrapados en contratos incompatibles.

ERC-20 tampoco llama automáticamente al código del destinatario después de una transferencia normal.

La extensión ERC-1363 añade operaciones de transferencia con llamada y aprobación con llamada para aplicaciones que necesitan ese comportamiento.

Las extensiones con funciones de retorno añaden llamadas externas y deben revisarse para detectar riesgos de reentrada y seguridad del receptor.

SafeERC20 y tokens no estándar

La especificación ERC-20 indica que quien realiza las llamadas debe gestionar los valores devueltos

false
.

En la práctica, algunos contratos de tokens antiguos o inusuales no devuelven un valor booleano aunque la transferencia se complete.

Otras implementaciones revierten la transacción si hay un error, en lugar de devolver

false
.

Una llamada directa a la interfaz que dé por supuesto un solo comportamiento puede fallar o interpretar mal el resultado.

La utilidad SafeERC20 actual envuelve las operaciones con tokens y gestiona tanto los tokens que devuelven

false
como ciertos tokens que no devuelven ningún valor.

Una envoltura mejora la compatibilidad, pero no puede hacer que un token malicioso sea seguro desde el punto de vista económico.

Tokens con comisión de transferencia

Un token con comisión de transferencia deduce un cargo al mover tokens.

El destinatario recibe menos del importe solicitado por el remitente o el contrato que realiza la llamada.

Un protocolo que contabilice el importe solicitado en lugar del importe realmente recibido puede quedar infragarantizado.

Las aplicaciones que admitan este comportamiento deben comparar los saldos del token antes y después de la transferencia.

Las reglas de las comisiones también pueden cambiar si el contrato es actualizable o está controlado por un administrador.

Los nombres de las funciones ERC-20 estándar no garantizan un resultado de transferencia fijo.

Tokens ERC-20 rebasables

Un token rebasable modifica los saldos de las cuentas según un proceso de ajuste definido por el contrato.

El saldo que muestra

balanceOf
puede aumentar o disminuir sin que el titular inicie una transferencia normal.

Los rebases positivos aumentan los saldos mostrados, mientras que los negativos los reducen.

Algunos sistemas utilizan participaciones internas y calculan los saldos visibles mediante un tipo de cambio.

Las aplicaciones que supongan que los saldos solo cambian mediante transferencias pueden contabilizar incorrectamente los tokens rebasables.

Los usuarios deben comprender si un token representa un saldo de unidades fijo o un derecho proporcional variable.

Tokens ERC-20 wrapped

Un token ERC-20 wrapped representa otro activo mediante un contrato inteligente o un acuerdo de custodia.

Los usuarios pueden depositar un activo subyacente y recibir unidades ERC-20 correspondientes.

Normalmente, el canje quema o devuelve las unidades wrapped y libera el activo subyacente.

El valor del wrapper depende de la disponibilidad y la integridad del mecanismo de respaldo.

Las vulnerabilidades de contratos inteligentes, los fallos de custodia o de bridges, las garantías congeladas o una contabilidad incorrecta pueden romper la relación prevista.

El cumplimiento de ERC-20 solo demuestra compatibilidad con la interfaz, no que exista respaldo suficiente.

Tokens de gobernanza ERC-20

Un token ERC-20 puede ampliarse para representar poder de voto en un sistema de gobernanza on-chain.

La votación puede depender de los saldos actuales, los saldos delegados o las instantáneas históricas de saldos.

La biblioteca de implementación ERC-20 actual incluye una extensión de votación ERC-20 para la delegación y las consultas históricas de votos.

Ser titular de tokens de gobernanza no activa necesariamente el poder de voto de forma automática, ya que algunos sistemas exigen delegarlo.

La votación con tokens también puede verse influida por la concentración de la titularidad, los activos prestados, una baja participación y los permisos administrativos.

El estándar ERC-20 básico no define reglas de gobernanza.

Participaciones de bóvedas ERC-20

Los tokens ERC-20 pueden representar participaciones en una bóveda tokenizada.

Cada participación representa un derecho proporcional sobre los activos gestionados por la bóveda, no una unidad fija del token subyacente.

El estándar de bóvedas tokenizadas ERC-4626 amplía ERC-20 con funciones estandarizadas de depósito, retirada, acuñación, canje y conversión.

El valor de las participaciones de una bóveda en activos subyacentes puede aumentar o disminuir según el rendimiento de la estrategia, las comisiones, las pérdidas y las reglas contables.

La compatibilidad con ERC-20 por sí sola no explica qué respalda un token de participación ni cómo puede canjearse.

Mensajes de error ERC-20

El estándar ERC-20 original es anterior a los errores personalizados de Solidity y no define un conjunto estandarizado de mensajes de error.

Los distintos tokens pueden devolver

false
, revertir la transacción con un mensaje de texto o un error personalizado, o comportarse incorrectamente.

El estándar Final ERC-6093 define errores personalizados estructurados para fallos habituales de los tokens.

Entre los ejemplos figuran saldo insuficiente, remitente no válido, destinatario no válido, autorización insuficiente, aprobador no válido y gastador no válido.

Los errores estandarizados pueden ayudar a las carteras y aplicaciones a explicar los fallos de forma más coherente.

ERC-6093 no modifica la interfaz ERC-20 básica ni exige que todos los tokens existentes adopten esos errores.

¿Utiliza ERC-20 ERC-165?

El estándar ERC-20 original no exige la detección de interfaces ERC-165.

Una aplicación no puede dar por hecho que la llamada a

supportsInterface
identificará todos los tokens ERC-20.

El software suele identificar la compatibilidad mediante el ABI del contrato, el código fuente verificado, listas de tokens conocidos, datos de registros y pruebas directas de funciones.

La existencia de selectores de función conocidos no demuestra el cumplimiento completo del estándar.

Un contrato malicioso puede imitar partes de la interfaz y aplicar comportamientos perjudiciales o inesperados.

ERC-20 frente a ETH nativo

ETH es el activo cripto nativo de Ethereum y no es en sí mismo un token ERC-20.

Las cuentas de Ethereum pueden enviar ETH nativo mediante transferencias de valor a nivel de protocolo.

Los saldos ERC-20 existen dentro de contratos inteligentes individuales.

Para pagar las comisiones de transacción de Ethereum se necesita ETH, aunque el activo transferido sea un token ERC-20, salvo que otro sistema patrocine o abstraiga la comisión.

Se puede crear una representación ERC-20 de ETH para las aplicaciones que necesitan esa interfaz de token, pero ese activo wrapped sigue siendo distinto de ETH nativo.

ERC-20 frente a ERC-721

ERC-20 representa saldos fungibles, mientras que ERC-721 representa tokens no fungibles identificados individualmente.

Una cuenta ERC-20 posee una cantidad de unidades intercambiables.

Una cuenta ERC-721 posee ID de token distintos.

ERC-20 suele utilizar decimales para mostrar cantidades, mientras que cada token ERC-721 se transfiere normalmente como una unidad única completa.

ERC-721 también incluye comprobaciones de recepción en las transferencias seguras, ausentes en el estándar ERC-20 básico.

ERC-20 frente a ERC-1155

ERC-20 gestiona un tipo de token fungible por interfaz de contrato.

ERC-1155 permite que un contrato gestione muchos ID de token con saldos independientes.

Esos ID ERC-1155 pueden representar activos fungibles, semifungibles o únicos.

ERC-1155 también define operaciones de transferencia por lotes y funciones de retorno del receptor.

El estándar más adecuado depende de si el proyecto necesita un activo fungible o varios tipos de activos gestionados por un mismo contrato.

Casos de uso habituales de ERC-20

Los tokens de valor estable pueden utilizar ERC-20 para representar unidades transferibles vinculadas a una reserva, un sistema de garantías o un mecanismo algorítmico.

Los sistemas de gobernanza pueden utilizar saldos ERC-20 o unidades delegadas como poder de voto.

Los juegos blockchain pueden utilizar tokens ERC-20 para monedas, recompensas o recursos intercambiables.

Las bóvedas y los sistemas de staking pueden emitir tokens de recibo ERC-20 que representen posiciones depositadas.

Los activos wrapped pueden utilizar ERC-20 para representar derechos sobre activos mantenidos en otro lugar.

Los proyectos también pueden utilizar el estándar para puntos de fidelidad, créditos de acceso, unidades de pago o derechos financieros tokenizados.

La interfaz no determina si un uso concreto es legal, está plenamente respaldado, está descentralizado o es económicamente sostenible.

Riesgos de los contratos inteligentes ERC-20

Una implementación ERC-20 puede contener errores en la lógica de transferencia, autorización, acuñación, quema, impuestos o control de acceso.

Un administrador con privilegios puede tener la capacidad de pausar transferencias, congelar saldos, bloquear direcciones, acuñar tokens, cambiar comisiones o actualizar el contrato.

Una actualización de proxy puede alterar el comportamiento del token después de que los titulares lo hayan adquirido.

Las llamadas externas en una lógica de token personalizada pueden generar riesgos de reentrada o denegación de servicio.

Las integraciones incorrectas pueden provocar pérdidas de fondos incluso si el token se comporta según su código.

El cumplimiento de los estándares mejora la interoperabilidad, pero no sustituye las auditorías, las pruebas, la revisión del código ni el análisis de permisos.

Phishing de aprobaciones de tokens

El phishing de aprobaciones intenta convencer al usuario de que autorice a un gastador malicioso.

La interfaz puede describir la acción como una verificación, una conexión, la elegibilidad para una recompensa o la recuperación de una cuenta.

Una vez confirmada la aprobación, el gastador puede utilizar

transferFrom
para retirar tokens hasta el límite autorizado.

Una firma Permit puede conceder una autoridad similar sin que la víctima envíe inmediatamente una transacción de aprobación on-chain.

Los usuarios deben verificar el contrato del token, la dirección del gastador, el importe autorizado, la red y la finalidad de cada aprobación o Permit.

Nunca se debe introducir una frase de recuperación o clave privada en una aplicación para cancelar una autorización ERC-20.

Estafas de transferencia de tokens

Los estafadores pueden enviar tokens ERC-20 desconocidos a una cartera sin el permiso de su titular.

El nombre, el símbolo o los metadatos del token pueden incluir un sitio web o una afirmación engañosa.

Interactuar con el sitio anunciado puede conducir a aprobaciones o firmas maliciosas.

Los atacantes también pueden crear direcciones visualmente similares a las de transacciones anteriores del usuario.

Los usuarios deben copiar direcciones verificadas de registros fiables, en lugar de elegir un destino solo porque coincidan los primeros y últimos caracteres.

Recibir un token desconocido no obliga al titular de la cartera a interactuar con él.

Cómo deberían implementar ERC-20 los desarrolladores

Por lo general, los desarrolladores deberían partir de una implementación revisada y mantenida activamente.

La guía de desarrollo ERC-20 actual ofrece contratos básicos y extensiones para permisos Permit, límites, quemas, pausas, votación, wrapping, bóvedas y otras funciones.

La creación de oferta debe ser explícita y protegerse mediante un control de acceso adecuado.

Las personalizaciones de transferencias deben preservar las invariantes de saldo, oferta, eventos y autorizaciones.

Los desarrolladores deben probar las transferencias de valor cero, los valores máximos, los saldos insuficientes, las autorizaciones insuficientes, la acuñación, la quema, las aprobaciones y las transferencias que impliquen direcciones inusuales.

Si se admiten esos activos, las integraciones también deben probarse con tokens que devuelvan

false
, no devuelvan ningún valor, cobren comisiones de transferencia, sean rebasables, estén pausados o habiliten funciones de retorno.

Cómo pueden evaluar los usuarios un token ERC-20

El primer paso es verificar la red blockchain y la dirección completa del contrato del token.

El segundo es examinar la oferta actual, las afirmaciones sobre la oferta máxima y la autoridad de acuñación.

El tercero es revisar los permisos de administración, pausa, congelación, lista de bloqueo, comisiones y actualización.

El cuarto es determinar si el token está respaldado por otro activo y cómo funciona el canje.

El quinto es averiguar si existen comisiones de transferencia, comportamiento rebasable, restricciones o efectos inusuales en la cartera.

El sexto es revisar las auditorías, el código fuente verificado y el historial de incidentes sin considerar ninguna auditoría como garantía.

El séptimo es comprobar la concentración de titulares, la liquidez disponible y las condiciones en las que esta podría desaparecer.

El octavo es comprender la fuente real de la demanda o del rendimiento, en lugar de confiar en la marca del token.

El noveno es revisar las aprobaciones antes y después de utilizar contratos inteligentes desconocidos.

El décimo es probar un token o contrato nuevo con un importe limitado antes de exponer fondos significativos.

Ejemplo de transferencia ERC-20

Supongamos que Alice posee 500 unidades de un token ERC-20 y quiere enviar 75 a Bob.

La cartera de Alice confirma que la blockchain, el contrato del token, la dirección del destinatario, el importe y la comisión de transacción son correctos.

La cartera envía una transacción que llama a la función

transfer
del token.

El contrato del token verifica que Alice tiene al menos 75 unidades.

Reduce el saldo de Alice a 425 unidades y aumenta el de Bob en 75 unidades.

El contrato emite un evento

Transfer
que contiene la dirección de Alice, la de Bob y el importe transferido.

Los validadores de Ethereum incluyen la transacción en un bloque y los nodos verifican de forma independiente el cambio de estado resultante.

Tras la confirmación, las carteras y aplicaciones pueden consultar los saldos actualizados en el contrato del token.

Ejemplo de aprobación ERC-20

Supongamos que Alice quiere que un contrato de bóveda deposite 100 unidades de un token ERC-20 en su nombre.

Primero, Alice verifica la dirección del contrato de la bóveda y el token que utilizará.

Llama a

approve
y concede a la bóveda una autorización de 100 unidades.

El contrato del token registra la autorización y emite un evento

Approval
.

A continuación, Alice llama a la función de depósito de la bóveda.

La bóveda utiliza

transferFrom
para mover 100 unidades de Alice a la bóveda.

Antes de completar la transferencia, el contrato del token comprueba el saldo de Alice y la autorización de la bóveda.

Tras la transferencia, la autorización utilizada normalmente se reduce según la implementación del token.

Errores habituales con ERC-20

Un error habitual es identificar un token únicamente por su nombre o símbolo.

Otro error es suponer que todos los tokens ERC-20 utilizan 18 decimales.

Un tercer error es conceder una aprobación ilimitada a un contrato no fiable.

Un cuarto error es creer que desconectar una cartera revoca las autorizaciones de los tokens.

Un quinto error es ignorar el valor booleano devuelto o el comportamiento no estándar de las transferencias de tokens.

Un sexto error es contabilizar un depósito sujeto a una comisión de transferencia por el importe solicitado, en lugar de por el importe recibido.

Un séptimo error es interpretar

totalSupply
como prueba de un límite permanente de oferta.

Un octavo error es suponer que el cumplimiento de ERC-20 demuestra que existen garantías o valor de canje.

Un noveno error es firmar un Permit sin comprobar el gastador, el importe y la fecha límite.

Un décimo error es considerar una auditoría o un código fuente verificado como garantía de que el token no puede fallar.

Preguntas frecuentes

¿Qué significa ERC-20?

ERC-20 es el estándar de Ethereum que define funciones y eventos comunes para tokens fungibles de contratos inteligentes.

¿ERC-20 es una criptomoneda?

ERC-20 es un estándar técnico, mientras que un contrato concreto que lo implemente puede crear un token de criptomoneda.

¿ERC-20 es lo mismo que Ethereum?

No. Ethereum es la red blockchain, mientras que ERC-20 es una interfaz de contrato inteligente utilizada por tokens que operan en esa red.

¿ETH es un token ERC-20?

No. ETH es el activo nativo de Ethereum y no utiliza por sí mismo la interfaz de contrato ERC-20.

¿Son fungibles los tokens ERC-20?

Sí. Según las reglas contables del contrato, las unidades equivalentes de un mismo token ERC-20 normal son intercambiables.

¿Cuáles son las seis funciones principales de ERC-20?

Son

totalSupply
,
balanceOf
,
transfer
,
allowance
,
approve
y
transferFrom
.

¿Qué eventos define ERC-20?

El estándar define los eventos

Transfer
y
Approval
.

¿Son obligatorios name, symbol y decimals?

No. Las tres funciones de metadatos son opcionales en la especificación ERC-20 original.

¿Todos los tokens ERC-20 utilizan 18 decimales?

No. Es habitual utilizar 18, pero cada token puede tener un valor decimal distinto.

¿Qué hace una aprobación ERC-20?

Concede a un gastador permiso para transferir tokens del titular hasta un importe autorizado.

¿Para qué se utiliza transferFrom?

Permite a un gastador autorizado transferir tokens del titular a un destinatario.

¿Qué es una aprobación ERC-20 ilimitada?

Es una autorización establecida en un valor máximo extremadamente elevado para que el gastador pueda seguir transfiriendo tokens sin aprobaciones repetidas.

¿Desconectar una cartera revoca las aprobaciones?

No. Las autorizaciones on-chain siguen activas hasta que se modifican mediante el contrato del token o dejan de tener efecto por otro motivo.

¿Qué es un Permit ERC-20?

Un Permit es un mensaje firmado opcional de ERC-2612 que crea o modifica una autorización sin que el titular tenga que enviar directamente la transacción de aprobación.

¿Se pueden acuñar tokens ERC-20?

Sí, si la implementación incluye un mecanismo de acuñación y puede utilizarlo una parte autorizada o una condición del protocolo.

¿Se pueden quemar tokens ERC-20?

Sí, si la implementación incluye lógica contractual para destruir unidades del token.

¿Exige ERC-20 una oferta fija?

No. La política de oferta depende de la implementación de cada token.

¿Pueden cobrarse comisiones por las transferencias ERC-20?

Sí. Los tokens personalizados pueden deducir comisiones de transferencia, aunque el estándar básico no las exige.

¿Puede cambiar un saldo ERC-20 sin una transferencia?

Sí. Los modelos rebasables y otras formas de contabilidad personalizada pueden modificar los saldos declarados sin transferencias ordinarias de los titulares.

¿Pueden quedarse bloqueados los tokens ERC-20 en un contrato?

Sí. La función de transferencia básica no exige que los contratos receptores confirmen que pueden gestionar o devolver los tokens.

¿Admite ERC-20 la detección de interfaces ERC-165?

No. La especificación ERC-20 original no exige ERC-165.

¿Garantiza ERC-20 que un token esté respaldado?

No. El estándar no verifica reservas, garantías, derechos de canje ni solvencia.

¿El cumplimiento de ERC-20 hace que un token sea seguro?

No. Un token compatible puede seguir teniendo permisos peligrosos, código defectuoso, respaldo débil, poca liquidez u operadores maliciosos.

¿Cómo pueden identificar los usuarios el token ERC-20 correcto?

Los usuarios deben verificar la red blockchain y la dirección completa del contrato a través de una fuente oficial.

¿Cuál es la principal ventaja de ERC-20?

Su principal ventaja es la interoperabilidad que ofrece una interfaz compartida, conocida por muchas carteras y contratos inteligentes cripto.

Conclusión

ERC-20 es el estándar fundamental de Ethereum para tokens fungibles de contratos inteligentes.

Define métodos comunes para consultar la oferta y los saldos, transferir tokens y conceder autoridad de gasto delegada.

Sus eventos

Transfer
y
Approval
permiten a las aplicaciones cripto supervisar los movimientos y permisos de los tokens.

Las funciones opcionales de metadatos proporcionan el nombre, el símbolo y la configuración decimal de un token, pero estos valores no demuestran su autenticidad.

El estándar no determina cómo se crea la oferta, si los tokens están respaldados, quién controla la administración ni si el activo tiene valor financiero.

Las extensiones pueden añadir permisos firmados, votación, pausas, límites, funciones de retorno, funcionalidad de bóveda, errores estandarizados y otras características.

Las aprobaciones siguen siendo uno de los principales riesgos para los usuarios, ya que un gastador malicioso puede utilizar una autorización activa mediante

transferFrom
.

Los desarrolladores deben tener en cuenta los valores devueltos

false
, los tokens que no devuelven ningún valor, las comisiones de transferencia, los rebases, las funciones de retorno, los decimales inusuales y las restricciones personalizadas.

Los usuarios deben verificar las direcciones de los contratos, revisar los permisos, comprender quién controla la acuñación y las actualizaciones e investigar el respaldo y el diseño económico del token.

La compatibilidad con ERC-20 crea un lenguaje técnico común, pero no sustituye la seguridad de los contratos inteligentes, la revisión cuidadosa de las transacciones ni la investigación financiera independiente.
BTC ETFs See $679M in Outflows
BTC ETFs See $679M in OutflowsBTC ETFs See $679M in Outflows
Citi sees BTC at $113K. What do institutions see?