¿Qué es ERC-677: Facilitando las interacciones de contratos inteligentes

Los contratos inteligentes potencian casi todas las interacciones significativas en las cadenas EVM, desde el intercambio de tokens y el staking, hasta el puente de activos y la activación de actualizaciones de oráculos. Sin embargo, el estándar base de tokens ERC-20 a menudo requiere patrones de experiencia de usuario de varios pasos como "aprobar" seguido de "llamar", lo que añade fricción, cuesta más gas y aumenta la posibilidad de errores del usuario. ERC-677 es una extensión pragmática de ERC-20 que agiliza estos flujos al combinar una transferencia de token con una llamada de contrato inmediata.

Este artículo explica qué es ERC-677, cómo funciona, dónde es útil y qué deben tener en cuenta los desarrolladores y usuarios en 2025.

El problema con ERC-20 solo

ERC-20 define una interfaz simple para tokens fungibles: transferir, aprobar y transferirDesde. Esa simplicidad ayudó a ERC-20 a convertirse en la columna vertebral de DeFi y las stablecoins, pero también obliga a flujos de trabajo comunes a realizarse en dos transacciones:

• Aprobar al gastador
• Llamar al contrato del protocolo (que luego usa transferirDesde)

Este patrón de dos pasos:

• Aumenta el número de transacciones y el consumo de gas.
• Crea fricción y confusión en la experiencia del usuario.
• Puede introducir condiciones de carrera en las aprobaciones y permisos pendientes. Consulte la guía de OpenZeppelin sobre cómo ajustar los permisos para mitigar problemas con la semántica de aprobación. Recomendaciones de permisos ERC-20 de OpenZeppelin

Para obtener información general sobre ERC-20 en sí, consulte la documentación de Ethereum.org. Descripción general del estándar ERC-20

Lo que añade ERC-677

ERC-677 extiende ERC-20 con una función clave: transferAndCall. En una sola transacción, el token se transfiere a un contrato receptor e invoca inmediatamente una devolución de llamada predefinida (comúnmente onTokenTransfer) en ese receptor con datos arbitrarios.

Flujo de alto nivel:

1. El usuario firma un transferAndCall en el token ERC-677.
2. El contrato del token transfiere tokens al receptor.
3. El contrato del token llama a receptor.onTokenTransfer(remitente, cantidad, datos).
4. El contrato receptor ejecuta la lógica, por ejemplo, depositar, apostar, intercambiar o activar un oráculo.

Este patrón elimina la necesidad de un paso de aprobación separado y permite que los contratos reaccionen a la recepción de tokens de inmediato.

El token LINK de Chainlink es una implementación conocida de ERC-677, diseñada para que los contratos puedan reaccionar a las transferencias de LINK de inmediato para pagar servicios de oráculo e interacciones relacionadas. Token LINK de Chainlink y ERC-677

Usos típicos

• Depósitos en staking y bóvedas: los usuarios depositan en una transacción, y la bóveda contabiliza el depósito en la devolución de llamada.
• Flujos de DEX y liquidez: los protocolos pueden recibir los tokens y ejecutar la lógica de intercambio o adición de liquidez directamente.
• Oráculos y pagos de servicios: transfiera tokens a un contrato de servicio y active el uso o la facturación en la misma llamada. Así es como ERC-677 de LINK permite pagos fluidos de oráculos. Token LINK de Chainlink y ERC-677
• Puentes y protocolos entre cadenas: combine la entrega de tokens con una carga útil de instrucciones para puentear o enviar mensajes.
• Interoperabilidad entre cadenas: A medida que crece el uso entre cadenas, combinar la transferencia de valor con la ejecución es útil. El diseño de Chainlink CCIP ilustra la creciente demanda de flujos de tokens programables a través de redes. ¿Qué es CCIP?

Cómo se compara ERC-677 con las alternativas

• ERC-1363 (tokens "pagables" similares a transferAndCall): Objetivo similar: permitir que los contratos reaccionen cuando reciben tokens, con devoluciones de llamada estandarizadas para flujos de gasto y aprobación. Bueno para experiencias similares a pagos. Especificación ERC-1363

• ERC-777 (tokens basados en "hooks"): proporciona semántica de tokens más rica y "hooks" para receptores. Potente, pero históricamente con más complejidad y riesgo de reentrada si los receptores no están diseñados cuidadosamente. Especificación ERC-777

• EIP-2612 ("permit") y Permit2: se centran en aprobaciones sin gas mediante mensajes firmados, lo que reduce la necesidad de transacciones de aprobación. Ideal para DEX y billeteras, pero a menudo todavía deja una llamada de contrato posterior. ERC-677 reduce los pasos del usuario al agrupar la transferencia y la ejecución. Permit EIP-2612, Permit2 de Uniswap

• Abstracción de Cuentas (EIP-4337): permite que las billeteras y los patrocinadores agrupen múltiples operaciones y patrocinen el gas, mejorando la experiencia del usuario. ERC-677 complementa AA al reducir aún más los pasos del lado del protocolo. Abstracción de Cuentas EIP-4337

En resumen: permit y AA reducen la fricción desde el lado de la billetera; ERC-677 reduce la fricción al permitir que la transferencia de tokens active la lógica del contrato inteligente.

Consideraciones para desarrolladores y seguridad

Con las devoluciones de llamada al recibir tokens, la precaución es esencial:

• Reentrada: El contrato del token llama a la lógica del receptor. Si los receptores vuelven a llamar al token u otros contratos externos, puede introducir vulnerabilidades de reentrada. Utilice patrones de "comprobaciones-efectos-interacciones" o "guardas" cuando sea apropiado. SWC-107 Reentrada, ReentrancyGuard de OpenZeppelin

• Valide el remitente y el token: Asegúrese de que los contratos receptores verifiquen que msg.sender sea igual al contrato de token de confianza y valide la dirección del token si se admiten varios tokens.

• Lista blanca: Considere poner en lista blanca los contratos receptores permitidos (o validar interfaces) para tokens donde la devolución de llamada puede realizar operaciones sensibles.

• Diseño de eventos: Emitir eventos enriquecidos ayuda a la indexación y al análisis. Mantenga eventos Transfer compatibles con ERC-20 junto con datos específicos de ERC-677 cuando sea factible para la compatibilidad con herramientas.

• Seguridad de la función de respaldo: Si el receptor no implementa la devolución de llamada esperada, la transferencia debe revertirse o seguir una ruta de fallo segura y explícita para evitar la pérdida "silenciosa" de funcionalidad.

• Gas y modos de fallo: la devolución de llamada puede revertirse; maneje los fallos con mensajes de error claros y asegúrese de que los usuarios entiendan si la transferencia tuvo éxito o si toda la transacción se revirtió.

Para la seguridad general de los contratos inteligentes, la lectura de las consideraciones de seguridad de la documentación de Solidity sigue siendo esencial. Consideraciones de seguridad de Solidity

Experiencia de usuario en billeteras: por qué esto es importante para los usuarios

Al eliminar la secuencia "aprobar y luego llamar", ERC-677 puede hacer que las interacciones complejas se sientan como una acción única y con propósito. Eso reduce la fatiga de las firmas, disminuye la carga cognitiva y, a menudo, ahorra gas. Sin embargo, la transacción única es más compleja: está transfiriendo tokens y ejecutando lógica de contrato. Esto exige vistas previas claras, simulación y datos de llamada legibles por parte de las billeteras.

Si usted es un usuario consciente de la seguridad que interactúa con protocolos que utilizan ERC-677, usar una billetera de hardware que muestre nombres de funciones, parámetros y cambios de valor estimados legibles por humanos puede ayudarle a firmar con confianza.

Contexto 2025: adopción y componibilidad

En 2025, la tendencia continúa hacia la agrupación de la transferencia de valor y la ejecución de intenciones:

• Más protocolos prefieren depósitos, intercambios o pagos de servicios de "un clic" que se sientan nativos y reduzcan el desorden de las aprobaciones.
• Los marcos entre cadenas enfatizan los movimientos de tokens programables y las cargas útiles de mensajes: la semántica similar a ERC-677 se adapta bien a estas arquitecturas. Vea cómo CCIP formaliza los mensajes programables junto con la transferencia de tokens para casos de uso entre cadenas. ¿Qué es CCIP?

Espere un mayor soporte de billeteras e intermediarios para simular flujos de devolución de llamada, exponer riesgos y proporcionar indicaciones inteligibles que hagan que las operaciones combinadas de transferencia y ejecución sean más seguras.

Esquema de interfaz mínima

Conceptualmente, ERC-677 se ve así (las implementaciones pueden variar ligeramente):

interface IERC677 {
    function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
    event Transfer([address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) indexed from, [address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) indexed to, uint256 value, bytes data);
}

interface IERC677Receiver {
    function onTokenTransfer([address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) sender, uint256 value, bytes calldata data) external;
}

El contrato del token llama a onTokenTransfer en el receptor inmediatamente después de transferir el valor, lo que permite al receptor reaccionar en una sola transacción.

Consejos prácticos

• Para desarrolladores de protocolos: Documente claramente las interfaces de devolución de llamada esperadas y los motivos de reversión. Cuando corresponda, publique listas blancas o verificaciones de interfaz para que los integradores puedan verificar el comportamiento.
• Para integradores: Simule transferAndCall para previsualizar los cambios de estado posteriores a la devolución de llamada. Marque a los receptores riesgosos o las devoluciones de llamada desconocidas para los usuarios.
• Para usuarios: Prefiera protocolos de confianza e inspeccione las vistas previas de las transacciones. Si su billetera admite la decodificación legible, tómese un momento para revisar los parámetros pasados a la devolución de llamada.

¿Debería usar ERC-677?

Use ERC-677 cuando:

• Desea eliminar el patrón de aprobación + llamada para los flujos de usuario principales.
• El protocolo se beneficia de una reacción inmediata y atómica a la recepción de tokens.
• Puede endurecer las devoluciones de llamada del receptor contra la reentrada y validar exhaustivamente las fuentes de tokens.

Si su caso de uso se centra puramente en la aprobación (por ejemplo, permitir que un DEX gaste tokens más adelante), EIP-2612 o Permit2 podrían ser suficientes. Si necesita semántica de "hooks" más rica en muchos receptores, evalúe ERC-777, pero tenga en cuenta su complejidad.

Una nota para los usuarios de OneKey

Las transacciones ERC-677 combinan una transferencia de token con una llamada de contrato. Al firmar, es útil ver exactamente qué función se ejecutará y con qué parámetros. El enfoque de código abierto de OneKey y su soporte EVM tienen como objetivo proporcionar vistas previas de llamadas transparentes y firmas confiables para interacciones avanzadas como transferAndCall, para que los usuarios avanzados puedan mantener una seguridad sólida mientras disfrutan de una experiencia de usuario optimizada.

Al comprender ERC-677 y utilizar una billetera que muestre los detalles de la transacción de forma clara, puede beneficiarse de forma segura de interacciones de contratos inteligentes más sencillas y en una sola transacción.