ERC-777 Explicado: El estándar de token moderno con "hooks"

Claro, aquí tienes la traducción al español del artículo, manteniendo el formato Markdown y la estructura original, y utilizando expresiones idiomáticas:

ERC-777 es un estándar de token más reciente en Ethereum diseñado para abordar las limitaciones de larga data de ERC-20, al tiempo que introduce "hooks" (ganchos) programables para flujos de tokens más ricos. Si has estado siguiendo las conversaciones de desarrolladores sobre la componibilidad, las aprobaciones más seguras y la automatización de protocolos, ERC-777 se encuentra en la intersección de estas necesidades. Este artículo explica cómo funciona ERC-777, por qué existe, dónde brilla, los compromisos de seguridad a tener en cuenta y cómo los usuarios y constructores pueden abordarlo en 2025.

El problema que ERC-777 se propuso resolver

ERC-20 se convirtió en el estándar de token fungible por defecto, pero tiene puntos débiles notables:

• Las aprobaciones son torpes y propensas a errores (por ejemplo, olvidar restablecer las asignaciones).
• Los contratos no pueden reaccionar automáticamente cuando llegan tokens; necesitan interacciones de tipo "pull" (tirar).
• La semántica de las transferencias es limitada, lo que dificulta flujos complejos (tarifas, callbacks, flujos de trabajo de varios pasos).

ERC-777 intenta modernizar esto ofreciendo:

• "Hooks" de envío/recepción integrados para que los contratos puedan reaccionar a las transferencias dentro de la misma transacción.
• Transferencias basadas en operadores, que simplifican la gestión de tokens para custodios y servicios.
• Compatibilidad retroactiva con las interfaces ERC-20 para facilitar la adopción del ecosistema.

Para una especificación formal, consulta el estándar canónico ERC-777 en el sitio de Propuestas de Mejora de Ethereum: EIP-777. Para situarlo dentro del ecosistema de tokens más amplio, la documentación para desarrolladores de Ethereum sobre estándares de tokens proporciona contexto y enlaces a EIPs relacionadas: Visión general de los estándares de tokens de Ethereum.

Cómo funciona ERC-777: "hooks" y operadores

Dos ideas centrales impulsan ERC-777.

1. "Hooks" (Ganchos)

• tokensToSend: Un "hook" del lado del remitente llamado antes de que se muevan los tokens.
• tokensReceived: Un "hook" del lado del receptor llamado después de que llegan los tokens.
• Estos son opcionales y se descubren a través del registro de interfaces global, EIP-1820.

Utilizando "hooks", los contratos pueden implementar lógica de negocio durante las transferencias: auto-staking, división de tarifas, registro, control de acceso o rechazo de tokens inesperados. Los "hooks" aumentan la componibilidad y reducen la necesidad de flujos separados de "aprobar y llamar".

2. Operadores

• Un operador está autorizado para transferir tokens en nombre de un titular, similar a un custodio delegado.
• Los operadores por defecto pueden ser establecidos por un token, y los usuarios pueden revocarlos en cualquier momento.
• Los operadores en ERC-777 son un modelo más explícito y flexible en comparación con las asignaciones de ERC-20.

En la práctica, la mayoría de los equipos confían en bibliotecas auditadas. OpenZeppelin proporciona una implementación ampliamente utilizada con APIs y salvaguardas claras: Contratos ERC-777 de OpenZeppelin.

Un ejemplo mínimo para desarrolladores

A continuación, se presenta un esquema de un contrato receptor que utiliza tokensReceived a través de EIP-1820. Utiliza siempre bibliotecas verificadas y realiza auditorías para el código de producción.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC777/IERC777.[sol](https://onekey.so/blog/es/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/interfaces/IERC1820Registry.[sol](https://onekey.so/blog/es/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/es/ecosystem/what-is-a-smart-contract/) ExampleReceiver {
    IERC1820Registry constant _ERC1820 =
        IERC1820Registry(0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24);

    bytes32 constant TOKENS_RECIPIENT_INTERFACE_HASH =
        keccak256("ERC777TokensRecipient");

    event Received(address operator, address from, uint256 amount, bytes data, bytes operatorData);

    constructor() {
        _ERC1820.setInterfaceImplementer(address(this), TOKENS_RECIPIENT_INTERFACE_HASH, address(this));
    }

    // Hook ERC777 tokensReceived
    function tokensReceived(
        [address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) operator,
        [address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) from,
        [address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) /*to*/,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external {
        // Lógica personalizada, por ejemplo, registrar depósito o activar contabilidad interna
        emit Received(operator, from, amount, data, operatorData);
    }
}

Conclusión clave: los "hooks" permiten a los contratos "escuchar" los movimientos de tokens sin llamadas a funciones separadas, reduciendo la fricción y haciendo que los flujos complejos se sientan nativos.

Consideraciones de seguridad: reentrada y diseño de protocolos

Los "hooks" son potentes, pero introducen riesgo de reentrada si los contratos no están diseñados de forma defensiva. En las primeras etapas de DeFi, una serie de incidentes destacaron cómo los callbacks de tokens podían interactuar inesperadamente con protocolos que asumían un comportamiento similar a ERC-20. Esas lecciones impulsaron mejores prácticas que siguen siendo relevantes hoy en día:

• Favorece las comprobaciones-efectos-interacciones en funciones que cambian el estado.
• Utiliza guardas de reentrada en las rutas de llamadas externas.
• Diseña cuidadosamente la lógica de piscina/contabilidad para que sea robusta frente a la ejecución de callbacks a mitad de la transferencia.
• Considera un modelo de "pull" para operaciones sensibles siempre que sea posible.
• Evita asumir que las transferencias no tienen efectos secundarios.

Aunque los exploits específicos de la era de Uniswap v1 son historia, el principio se mantiene: los "hooks" hacen que las transferencias de tokens sean activas, no pasivas. Las auditorías y bibliotecas modernas han evolucionado en consecuencia. Para una referencia fundamental sobre el estándar y sus notas de seguridad, consulta EIP-777. Para estudiar patrones y salvaguardas bien mantenidas, consulta la documentación de ERC-777 de OpenZeppelin.

Interoperabilidad y migración desde ERC-20

Los tokens ERC-777 son generalmente retrocompatibles con las interfaces ERC-20, pero las suposiciones difieren:

• Las transferencias pueden activar "hooks", que pueden tener efectos secundarios.
• Los operadores reemplazan o complementan las asignaciones, cambiando la forma en que interactúan los servicios.
• Las billeteras y dApps deben manejar correctamente los metadatos y los flujos basados en "hooks".

Algunos equipos se quedan con ERC-20 más mejoras como EIP-2612 permit (aprobaciones sin gas), dada la amplia familiaridad del ecosistema. Otros adoptan ERC-777 donde la recepción programable o la semántica de operadores mejoran materialmente la experiencia del usuario o la lógica del protocolo.

Panorama 2025: dónde encajan los "hooks"

Mientras que ERC-20 todavía domina los tokens fungibles, los "hooks" han influido en el diseño en otros lugares. Un ejemplo claro es la arquitectura de Uniswap v4, que adopta "hooks" programables a nivel de pool de liquidez para habilitar características como tarifas dinámicas y lógica a medida, haciendo el protocolo más componible por diseño. Para contextualizar esta evolución, consulta la descripción general de Uniswap v4 y la discusión sobre "hooks": Anuncio de Uniswap v4 y hooks.

A nivel de token, la adopción de ERC-777 sigue siendo selectiva, particularmente en contextos donde los callbacks automáticos y la semántica de operadores ofrecen valor tangible, como:

• Flujos de custodia o proveedores de servicios que se benefician de las transferencias de operadores.
• Programas de fidelización en cadena o pagos en streaming que reaccionan al recibirlos.
• Capas de infraestructura que desean callbacks nativos del token para contabilidad o cobro de tarifas.

Mientras tanto, las redes de Capa 2 continúan mejorando el rendimiento y los perfiles de costos, haciendo viable una lógica más compleja del ciclo de vida del token. Este entorno hace que la programabilidad de ERC-777 sea una opción oportuna para los equipos que necesitan una semántica de transferencia más rica pero pueden invertir en una ingeniería de seguridad robusta.

Mejores prácticas para constructores

• Utiliza bibliotecas auditadas y prefiere implementaciones conocidas. Comienza con ERC-777 de OpenZeppelin.
• Diseña la lógica de los "hooks" para modos de fallo: rechaza tokens inesperados, valida el origen y mantén comprobaciones de invariantes.
• Documenta claramente los operadores por defecto; proporciona rutas de revocación sencillas para los usuarios.
• Aplica protecciones contra reentrada, especialmente alrededor de tokensReceived, y evita llamadas externas durante pasos de contabilidad críticos a menos que sea estrictamente necesario.
• Considera si realmente necesitas "hooks". Si no es así, ERC-20 más EIP-2612 permit puede simplificar la integración y las expectativas del usuario.
• Prueba en billeteras y dApps que puedan tratar ERC-777 de manera diferente. Utiliza el registro EIP-1820 correctamente para registrar implementadores.

Consejos prácticos para usuarios

• Entiende que los tokens ERC-777 pueden activar lógica cuando llegan a ciertos contratos. Esto suele ser beneficioso, pero cambia las suposiciones en comparación con las transferencias "pasivas" de ERC-20.
• Revisa lo que estás aprobando y a quién. Si un token utiliza operadores o callbacks, asegúrate de confiar en el código y la reputación del contrato receptor.
• Prefiere billeteras que muestren detalles claros de los métodos del contrato, no solo "transferir" o "enviar". Si algo parece desconocido o incluye campos de datos arbitrarios, detente y verifica.

Cuándo considerar ERC-777

ERC-777 tiene sentido cuando:

• Necesitas un comportamiento de token impulsado por eventos en el momento de la transferencia (por ejemplo, depósito automático, enrutamiento de tarifas, control de acceso personalizado).
• Los operadores simplifican significativamente tu modelo de servicio o custodia.
• Estás comprometido con una ingeniería de seguridad rigurosa y auditorías para manejar de forma segura la semántica basada en callbacks.

ERC-777 puede ser menos ideal cuando:

• La simplicidad y la amplia compatibilidad del ecosistema son primordiales.
• Puedes lograr tus objetivos a través de ERC-20 más "permit", o mecánicas de protocolo de nivel superior (por ejemplo, controladores específicos de la aplicación sin "hooks" de token).

Una perspectiva desde hardware wallets

Para estándares de tokens con comportamiento más rico y posibles efectos secundarios, la introspección clara de transacciones y la firma offline son invaluables. OneKey es una hardware wallet de código abierto que enfatiza confirmaciones transparentes en el dispositivo y un amplio soporte de tokens EVM. Si interactúas habitualmente con estándares de tokens avanzados o protocolos DeFi que utilizan callbacks, usar una hardware wallet ayuda a garantizar que verificas exactamente lo que estás firmando y reduce la exposición a contratos maliciosos. En otras palabras, la sofisticación de ERC-777 hace que la gestión segura de claves y las confirmaciones explícitas y legibles por humanos sean aún más importantes, áreas donde un dispositivo como OneKey puede proporcionar una tranquilidad significativa.

Conclusión

ERC-777 introduce características de token modernas —"hooks" y operadores— que desbloquean flujos de tokens más ricos y componibles en Ethereum y cadenas EVM. Su poder conlleva responsabilidad: los "hooks" son activos, no pasivos, y exigen programación defensiva y una experiencia de usuario cuidadosa. En 2025, el concepto de "hooks" ha influido en el diseño de protocolos más allá de los tokens, como se ve en Uniswap v4, mientras que ERC-777 en sí mismo sigue siendo una opción dirigida para los equipos que realmente se benefician de la recepción programable y la semántica de operadores. Ya sea que adoptes ERC-777 o te quedes con patrones ERC-20 mejorados, combina buenas prácticas de ingeniería con flujos de trabajo seguros para el usuario —y considera la firma respaldada por hardware— para que tu lógica de token sea potente y segura.