ERC-20

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

ERC-20 es una interfaz estándar para contratos de tokens fungibles en Ethereum. Permite que las billeteras, los exchanges y las aplicaciones descentralizadas usen las mismas llamadas para consultar la oferta o un saldo, transferir tokens y autorizar a otra dirección a gastar una cantidad limitada. Fungible significa que las unidades equivalentes de un mismo token están destinadas a ser intercambiables.

La interfaz principal incluye:

• totalSupply y balanceOf para consultar la oferta y los saldos de las cuentas;
• transfer para enviar los tokens de quien realiza la llamada;
• approve y allowance para establecer y consultar el límite de gasto de una dirección autorizada;
• transferFrom para gastar del saldo de un propietario dentro de ese límite; y
• los eventos Transfer y Approval para registrar transferencias y aprobaciones.

El estándar define interoperabilidad, no calidad del activo. La conformidad con ERC-20 no garantiza una oferta fija, un valor de mercado justo, convertibilidad, liquidez, una administración segura ni siquiera un comportamiento idéntico entre implementaciones.

Cómo funciona

Un saldo ERC-20 es una entrada en el estado del contrato del token asociada a una dirección. Una billetera muestra ese estado; no guarda un archivo de token independiente. Cuando transfer(to, amount) se ejecuta correctamente, el contrato reduce el saldo de quien realiza la llamada, aumenta el del destinatario y emite un evento Transfer. Por lo general, el usuario paga el gas de la red en ETH. Si la ejecución se revierte, los cambios en el estado del token se deshacen, pero el gas ya consumido no se reembolsa por completo.

El gasto delegado utiliza un límite de gasto. La llamada approve(spender, amount) establece cuánto puede usar la dirección autorizada del saldo de quien realiza la llamada. A continuación, esa dirección puede llamar a transferFrom(owner, to, amount), y allowance(owner, spender) indica el límite restante. Una aprobación corresponde a una sola pareja de propietario y dirección autorizada, en un contrato de token y una red concretos; no otorga permiso sobre todos los activos de la billetera.

Volver a llamar a approve sobrescribe el límite de gasto anterior. La especificación EIP-20 advierte a las interfaces de usuario que establezcan un límite existente en 0 antes de fijar otro valor distinto de cero, porque, de lo contrario, el orden de las transacciones puede permitir que una dirección autorizada use tanto el límite anterior como el nuevo. Establecer el límite en 0 puede impedir futuras llamadas a transferFrom para esa combinación de propietario, dirección autorizada y token, pero no permite recuperar tokens ya transferidos.

name, symbol y decimals son métodos opcionales de metadatos en EIP-20. decimals afecta a las unidades mostradas, no a la contabilidad de números enteros del contrato. El estándar tampoco prescribe cómo se acuñan o queman los tokens, si las transferencias pueden pausarse o gravarse, si pueden bloquearse direcciones o si puede actualizarse la lógica de un proxy. Estos comportamientos deben comprobarse en el código desplegado, la implementación vigente y los permisos administrativos.

Ejemplo

Supongamos que una billetera tiene 1,000 unidades de un token ERC-20 y que un usuario quiere que el enrutador de un exchange descentralizado intercambie 100. Primero, el usuario envía approve(router, 100). Si la operación se ejecuta correctamente, el enrutador puede llamar a transferFrom(user, pool, 100); después de gastar la totalidad, el límite restante habitual es 0. La transacción de aprobación y la de intercambio son acciones independientes en la cadena, por lo que cada una puede requerir gas y fallar por separado.

Aprobar el valor máximo posible puede evitar aprobaciones repetidas, pero deja una cantidad mayor expuesta durante más tiempo si se ven comprometidos el enrutador, su autoridad de actualización o la interfaz utilizada para obtener la aprobación. Un límite de gasto reducido disminuye esa exposición, aunque no elimina los riesgos de contratos inteligentes, precio del token, liquidez o transacción.

Riesgos

• Contrato o red equivocados: los nombres, símbolos e iconos pueden copiarse; verifique la dirección del contrato en la red prevista.
• Límite de gasto excesivo: una dirección autorizada maliciosa o comprometida puede utilizar un límite no consumido hasta el importe aprobado.
• Comportamiento no estándar: algunos tokens de uso extendido no devuelven valores exactamente como se espera, mientras que otros cobran comisiones de transferencia, reajustan saldos, bloquean direcciones o pausan transferencias.
• Control administrativo: la acuñación, el bloqueo, las actualizaciones u otras acciones privilegiadas pueden cambiar el riesgo del token después de que un usuario lo adquiera.
• Transferencia irrecuperable: enviar tokens a una dirección equivocada o a un contrato que no pueda gestionarlos puede imposibilitar su recuperación.

La estandarización ERC-20 reduce la fricción de integración; no elimina los riesgos del contrato, del emisor, de custodia, de mercado ni operativos. Antes de firmar, compruebe la red, el contrato del token, la dirección autorizada, la cantidad aprobada y la llamada de la transacción.

Errores comunes

Mito 1: La etiqueta ERC-20 demuestra que un token es legítimo

Cualquiera puede desplegar un contrato con un nombre o símbolo conocido. La etiqueta solo describe una afirmación sobre la interfaz. Verifique la dirección del contrato y después evalúe por separado el código, los permisos, el emisor, la liquidez y el mercado.

Mito 2: Una aprobación transfiere de inmediato los tokens aprobados

Por lo general, approve modifica un límite de gasto; por sí mismo no mueve tokens a la dirección autorizada. La llamada posterior a transferFrom es la que los mueve. Aun así, un límite pendiente es un permiso real que puede seguir utilizándose hasta que se gaste, se sustituya o se establezca en 0.

Mito 3: Todos los tokens ERC-20 se comportan de forma idéntica

El estándar especifica una interfaz común mínima. No exige una política de oferta concreta ni prohíbe comisiones, pausas, listas negras, reajustes de saldo o capacidad de actualización. Las integraciones deben tener en cuenta la implementación real en lugar de confiar únicamente en la etiqueta ERC-20.

Temas relacionados

• Billetera de recuperación social
• Estándar de token
• ¿Cuál es la diferencia entre una moneda y un token?
• Autorización de billetera
• ZK Rollup

Fuentes

• ERC-20: Token Standard - Ethereum Improvement Proposals (consultado: 2026-08-20)
• ERC-20 Token Standard - Ethereum.org (consultado: 2026-08-20)