Buy Crypto
Markets
Spot
FuturesBTC
Earn
Event Center
More
0-Fee Fest
ERC-777: ¿Qué es ERC-777?ERC-777 es un estándar de tokens de Ethereum para activos cripto fungibles que añade hooks de transferencia, permisos de operador, datos de transacción y comprobaciones más seguras de ERC-777: ¿Qué es ERC-777?ERC-777 es un estándar de tokens de Ethereum para activos cripto fungibles que añade hooks de transferencia, permisos de operador, datos de transacción y comprobaciones más seguras de

ERC-777

2026/10/13 15:31
#Advanced
Humanity
H$0.05659+2.48%
PX
PX$0.0105-7.07%
MemeCore
M$0.91661+6.40%
TokenFi
TOKEN$0.001837+0.71%
ELYSIA
EL$0.001515-2.75%

¿Qué es ERC-777?

ERC-777 es un estándar de tokens de Ethereum para activos cripto fungibles que añade hooks de transferencia, permisos de operador, datos de transacción y comprobaciones más seguras de los contratos receptores al modelo básico de token.

Al igual que ERC-20, representa unidades intercambiables: una unidad de token tiene el mismo valor y las mismas propiedades que otra unidad del mismo token.

La especificación oficial de ERC-777 es un estándar Final de Ethereum Request for Comments creado para mejorar la interacción de los tokens fungibles con wallets y contratos inteligentes.

Sus principales funciones son la función

send
, los hooks del emisor y del destinatario, los operadores autorizados, las funciones de quema integradas y los datos opcionales adjuntos a los movimientos de tokens.

ERC-777 se diseñó para mantener la compatibilidad con ERC-20, de modo que un mismo contrato de token pudiera admitir ambas interfaces.

Sin embargo, su adopción ha sido limitada en comparación con ERC-20, ya que el comportamiento de las devoluciones de llamada y la dependencia de ERC-1820 complican las integraciones y pueden introducir graves riesgos de reentrancia.

¿Sigue activo el estándar ERC-777?

ERC-777 sigue figurando como estándar Final en el repositorio oficial de propuestas de mejora de Ethereum.

El estado Final significa que la especificación completó el proceso de estandarización EIP, pero no garantiza una adopción generalizada, compatibilidad activa de las bibliotecas ni que sea adecuado para todos los tokens nuevos.

Una importante biblioteca de contratos inteligentes marcó como obsoleta su implementación de ERC-777 en la versión 4.9 y la eliminó en la versión 5.0.

El registro de cambios actual de OpenZeppelin Contracts recoge el fin de la compatibilidad con la implementación, aunque las interfaces relacionadas con el estándar siguen disponibles.

Esta decisión sobre la biblioteca no anuló ERC-777 ni modificó su estado Final.

Significa que los desarrolladores no deben esperar encontrar una implementación mantenida de tokens ERC-777 en las versiones actuales de esa biblioteca.

Los contratos ERC-777 existentes pueden seguir funcionando conforme al código desplegado, pero las nuevas integraciones deben evaluar cuidadosamente su comportamiento de devolución de llamada, dependencias, auditorías y compatibilidad con el ecosistema.

¿Por qué se creó ERC-777?

ERC-777 se creó para abordar varias limitaciones de usabilidad y seguridad asociadas a las transferencias ERC-20 básicas.

Una transferencia ERC-20 a un contrato no obliga al contrato receptor a reconocer o procesar los tokens.

Esto puede dejar los tokens atrapados si el contrato no tiene una función para recuperarlos o contabilizarlos.

Las aplicaciones ERC-20 también suelen utilizar un proceso en dos pasos: primero, el usuario aprueba a un gastador y, después, este llama a

transferFrom
.

ERC-777 introdujo

send
para permitir transferencias de tokens con datos adjuntos y notificar a un destinatario compatible en la misma transacción.

También introdujo los operadores como un modelo de autorización con nombre para cuentas o contratos que mueven tokens en nombre de sus titulares.

El estándar pretendía que los tokens fungibles se comportaran de forma más parecida a las transferencias nativas de ETH, a la vez que ofrecía a emisores y destinatarios control programable sobre los movimientos de tokens.

Cómo funciona ERC-777

Un contrato ERC-777 almacena saldos de tokens y la oferta total, y expone funciones estandarizadas para enviar, quemar y delegar el control de tokens.

Al enviar tokens, el contrato comprueba mediante ERC-1820 si el emisor ha registrado un hook de emisor.

Si existe un hook de emisor, el token lo llama antes de modificar los saldos.

A continuación, el token reduce el saldo del emisor y aumenta el del destinatario.

Tras actualizar los saldos, comprueba si el destinatario ha registrado un hook de destinatario y lo llama cuando corresponde.

Un hook puede aceptar el movimiento, ejecutar lógica adicional o revertir toda la transacción.

Como la operación es atómica, una reversión en un hook obligatorio normalmente cancela el movimiento del token y todos los cambios de estado relacionados con esa transacción.

Funciones principales de ERC-777

La interfaz ERC-777 incluye funciones para consultar los metadatos, los saldos, la granularidad, los operadores, las transferencias y las quemas de tokens.

Las funciones

name
,
symbol
,
totalSupply
y
balanceOf
proporcionan información familiar para quienes conocen los tokens ERC-20.

La función

granularity
indica la cantidad indivisible más pequeña que se puede acuñar, enviar o quemar.

La función

defaultOperators
devuelve los operadores autorizados por defecto para todos los titulares, sujetos al derecho de cada titular a revocarlos.

La función

isOperatorFor
comprueba si una dirección puede actuar como operador de un titular concreto.

Las funciones

authorizeOperator
y
revokeOperator
permiten al titular gestionar la autorización de operadores.

Las funciones

send
y
operatorSend
mueven tokens, mientras que
burn
y
operatorBurn
reducen permanentemente la oferta.

La función send

La función

send
permite al titular transferir tokens directamente a otra dirección y adjuntar un campo de bytes llamado
data
.

Los datos adjuntos pueden describir un pago, una acción de una aplicación, un número de referencia u otra información que el sistema receptor pueda interpretar.

La función activa los hooks registrados del emisor y del destinatario conforme a las reglas de ERC-777.

Cuando el destinatario es un contrato, un envío nativo de ERC-777 debe revertirse si el contrato no ha registrado mediante ERC-1820 una implementación receptora de ERC-777.

Esta comprobación del receptor pretende reducir el riesgo de enviar accidentalmente tokens a contratos que no pueden gestionarlos.

No demuestra que un destinatario registrado sea honesto, seguro o fiable desde el punto de vista económico.

La función operatorSend

La función

operatorSend
permite a un operador autorizado mover tokens de un titular a un destinatario.

El operador debe estar ya autorizado para ese titular conforme a las reglas del token.

Tanto los datos

data
proporcionados por el titular como los datos
operatorData
proporcionados por el operador pueden acompañar el movimiento.

La dirección del operador, el titular, el destinatario, la cantidad y los datos se incluyen en el evento estandarizado

Sent
.

Una llamada de un operador no autorizado debe revertirse.

La autoridad de un operador debe tratarse como información sensible, ya que puede permitir que otra dirección mueva o queme los tokens del titular.

¿Qué es un operador de ERC-777?

Un operador es una dirección autorizada para enviar o quemar tokens ERC-777 en nombre de un titular.

El titular del token siempre es operador de su propio saldo.

El titular puede autorizar otra cuenta o contrato inteligente y revocar esa autorización más adelante.

Los operadores pueden facilitar pagos automatizados, la gestión de cuentas mediante contratos, actividades programadas, sistemas de recuperación u otros flujos de trabajo delegados con tokens.

A diferencia de una asignación numérica de ERC-20, la autorización normal de un operador no está limitada a una cantidad concreta de tokens.

Esta autoridad más amplia puede mejorar la usabilidad, pero también aumenta las posibles pérdidas si el operador es malicioso o se ve comprometido.

Una wallet debe explicar con claridad que autorizar a un operador puede concederle control continuado sobre el saldo del titular.

Operadores por defecto

Un token ERC-777 puede definir operadores por defecto que estén autorizados inicialmente para todos los titulares.

La lista de operadores por defecto debe fijarse al crear el contrato del token y, conforme al estándar, no se puede ampliar ni reducir más adelante.

Todo titular debe poder revocar un operador por defecto para sus propios tokens.

El titular también debe poder volver a autorizar a un operador por defecto que haya revocado anteriormente.

Los operadores por defecto pueden facilitar servicios para todo el sistema sin que cada titular tenga que realizar una transacción inicial de autorización.

También plantean una importante cuestión de confianza, ya que un operador por defecto comienza con una amplia autoridad sobre los titulares del token.

Antes de conservar una cantidad significativa de un token ERC-777, los usuarios deben revisar la lista de operadores por defecto y entender su finalidad.

Hooks de emisor

El hook de emisor de ERC-777 se llama

tokensToSend
.

Un titular puede registrar mediante el registro ERC-1820 un contrato que implemente este hook.

El contrato del token debe llamar al hook antes de reducir el saldo del titular durante un envío o una quema de ERC-777.

El hook recibe el operador, el emisor, el destinatario, la cantidad, los datos del titular y los datos del operador.

Puede inspeccionar el movimiento propuesto y revertirlo si las reglas programadas por el titular lo rechazan.

Una smart wallet podría utilizar un hook de emisor para aplicar políticas de gasto, enviar notificaciones o añadir lógica de autorización.

El contrato del hook debe verificar que las llamadas proceden del contrato de token esperado, ya que el mismo hook registrado puede recibir llamadas relacionadas con distintos tokens ERC-777.

Hooks de destinatario

El hook de destinatario de ERC-777 se llama

tokensReceived
.

Una dirección receptora puede registrar mediante ERC-1820 un contrato que implemente este hook.

El token llama al hook después de aumentar el saldo del destinatario durante un envío o una acuñación.

El hook puede actualizar la contabilidad interna, activar una acción en otro contrato, registrar datos de pago o rechazar la recepción mediante una reversión.

Este diseño permite que la transferencia de tokens y la respuesta del destinatario se produzcan en una sola transacción atómica.

También implica que recibir tokens ERC-777 puede ejecutar código externo antes de que finalice la llamada original al token.

Todo protocolo que reciba tokens ERC-777 debe tener en cuenta este comportamiento de devolución de llamada en todas las funciones pertinentes que modifican el estado.

¿Qué es ERC-1820?

ERC-777 depende de ERC-1820 para detectar hooks de emisor y destinatario, así como interfaces compatibles.

La especificación ERC-1820 define un registro universal en el que una dirección puede publicar qué interfaces admite y qué contrato las implementa.

El registro puede incluir interfaces de cuentas convencionales y de contratos inteligentes.

Una cuenta puede registrarse como implementadora o designar a otro contrato para gestionar una interfaz en su nombre.

Antes de llamar a un hook de ERC-777, el token consulta en el registro la implementación correspondiente del emisor o del destinatario.

Esta dependencia del registro añade una consulta a un contrato externo a las operaciones ERC-777.

Para que una implementación estándar funcione correctamente, la red compatible debe contar con el despliegue esperado del registro ERC-1820 y con el comportamiento de integración correspondiente.

Eventos de ERC-777

ERC-777 define los eventos

Sent
,
Minted
,
Burned
,
AuthorizedOperator
y
RevokedOperator
.

El evento

Sent
identifica al operador, el emisor, el destinatario, la cantidad, los datos del titular y los datos del operador.

El evento

Minted
registra la creación de nuevos tokens y la dirección receptora.

El evento

Burned
registra la destrucción de tokens y el titular afectado.

Los eventos de operador permiten a las wallets y los servicios de supervisión realizar un seguimiento de los cambios en la autoridad delegada.

Un token que también admita ERC-20 puede emitir eventos ERC-20

Transfer
además de los eventos ERC-777 exigidos por la especificación.

Las aplicaciones deben evitar contabilizar dos veces un mismo movimiento económico cuando ambos tipos de evento describen la misma transferencia.

Granularidad y visualización de decimales

La granularidad es la menor cantidad interna de tokens que un contrato ERC-777 permite acuñar, enviar o quemar.

El valor se fija al crear el contrato y no puede cambiar según el estándar.

Todos los saldos y cantidades de movimiento deben ser múltiplos de la granularidad del token.

La mayoría de los tokens utiliza una granularidad de uno, que permite mover cada unidad interna entera.

ERC-777 establece que la unidad de visualización tiene 18 decimales respecto a la unidad interna.

Si un token ERC-777 también expone la función opcional ERC-20

decimals
, la especificación exige que devuelva 18.

Las aplicaciones deben utilizar aritmética con números enteros y dar formato a los valores para mostrarlos, en lugar de calcular los saldos de tokens con números de coma flotante.

Compatibilidad entre ERC-777 y ERC-20

ERC-777 se diseñó para que un token pudiera implementar funciones ERC-20 junto con la interfaz ERC-777.

El estándar ERC-20 define funciones conocidas como

transfer
,
approve
,
allowance
y
transferFrom
.

Un token compatible con ambos estándares puede funcionar con wallets y aplicaciones antiguas que solo entienden ERC-20.

Los hooks ERC-777 también pueden aplicarse a transferencias compatibles con ERC-20 si el emisor o el destinatario correspondiente ha registrado un hook.

Sin embargo, la protección de los contratos receptores difiere entre ambas interfaces.

Un envío nativo de ERC-777 mediante

send
a un contrato receptor no registrado debe revertirse, mientras que una transferencia compatible con ERC-20 puede completarse y dejar los tokens en ese contrato.

Los integradores deben identificar qué función se está llamando, en lugar de dar por sentado que todos los movimientos de un mismo token tienen el mismo comportamiento de devolución de llamada y recepción.

ERC-777 frente a las asignaciones de ERC-20

ERC-20 suele conceder a un gastador una asignación numérica que limita la cantidad de tokens que puede transferir del titular.

ERC-777 concede a un operador autoridad sobre el saldo de un titular hasta que se revoque esa autoridad.

El modelo de operador proporciona un rol con nombre más claro y admite acciones estandarizadas de envío y quema.

El modelo de asignación puede establecer un límite más acotado, aunque a veces los usuarios aprueban cantidades muy superiores a las necesarias.

Ambos sistemas pueden ocasionar pérdidas si los usuarios autorizan contratos maliciosos o comprometidos.

Las wallets deben mostrar si una acción crea una asignación fija, una asignación ilimitada o una autorización de operador ERC-777.

Si un token admite ambos estándares, revocar un tipo de permiso no revoca necesariamente el otro.

Riesgo de reentrancia en ERC-777

El riesgo más importante de integración de ERC-777 procede de sus hooks.

Un hook de destinatario ejecuta código de contrato externo durante la transferencia del token.

Ese código externo puede volver a llamar al protocolo emisor antes de que termine la función original del protocolo.

Este comportamiento se denomina reentrancia.

Un protocolo vulnerable puede calcular un saldo, enviar tokens ERC-777, recibir una devolución de llamada y permitir que esta repita una acción utilizando una contabilidad interna desactualizada.

El problema puede aparecer incluso si el protocolo llama a una función de estilo ERC-20, ya que un token ERC-777 compatible con ambos estándares puede seguir ejecutando los hooks registrados.

Los desarrolladores nunca deben dar por sentado que una transferencia de tokens fungibles está libre de devoluciones de llamada solo porque el nombre de la función se parezca al de una transferencia ERC-20 normal.

Cómo reducir el riesgo de reentrancia

Siempre que el orden previsto de la lógica lo permita, un protocolo debe actualizar su propia contabilidad crítica antes de realizar una llamada externa al token.

Debe emplear una protección adecuada contra la reentrancia en los puntos de entrada sensibles.

Las funciones relacionadas deben revisarse conjuntamente, ya que impedir la reentrada en una función puede dejar otra expuesta a una explotación.

El protocolo debe validar el contrato del token en lugar de aceptar activos arbitrarios cuyo comportamiento de devolución de llamada se desconoce.

Las pruebas deben incluir un hook de emisor malicioso, un hook de destinatario malicioso, un movimiento de tokens anidado, una devolución de llamada revertida y una reentrada entre funciones.

Los desarrolladores también deben revisar las rutas de acuñación y quema, ya que los hooks ERC-777 no se limitan a los envíos ordinarios.

Una auditoría puede reducir el riesgo, pero no garantiza que todas las interacciones con las devoluciones de llamada sean seguras.

Protección del receptor y sus límites

Las comprobaciones de receptores de ERC-777 pretenden reducir el riesgo de que los tokens queden bloqueados permanentemente en contratos que no pueden procesarlos.

Un contrato receptor de tokens mediante

send
debe registrar una implementación receptora de ERC-777 o la operación se revierte.

Esto ofrece más protección que una transferencia ERC-20 básica, que puede completarse aunque el contrato receptor no disponga de lógica para gestionar tokens.

Sin embargo, el registro solo demuestra que se registró una implementación para la interfaz.

No demuestra que el destinatario contabilice correctamente los saldos, permita retiradas o haya superado una auditoría de seguridad.

Un destinatario malicioso puede aceptar tokens intencionadamente y después aplicar una lógica perjudicial.

Los usuarios deben verificar igualmente el contrato de destino y la finalidad de la transacción.

Ventajas de ERC-777

ERC-777 puede notificar a los contratos cuando reciben tokens fungibles.

Puede combinar en una misma transacción la transferencia y el procesamiento del destinatario.

Permite a emisores y destinatarios rechazar movimientos mediante hooks programables.

Admite datos adjuntos que las aplicaciones pueden utilizar para interpretar un pago o una acción.

Su modelo de operador proporciona un control delegado estandarizado y una revocación explícita.

Los envíos nativos de ERC-777 reducen las transferencias accidentales a contratos que no registran compatibilidad con la recepción de tokens.

La compatibilidad con versiones anteriores puede permitir que un token funcione con la infraestructura ERC-20 y, al mismo tiempo, ofrezca un comportamiento más avanzado a las aplicaciones compatibles con ERC-777.

Limitaciones de ERC-777

Los hooks dificultan que los contratos inteligentes gestionen de forma segura los movimientos de tokens.

La consulta a ERC-1820 añade una dependencia externa y más complejidad de integración.

La autoridad de los operadores puede ser más amplia de lo que esperan los usuarios.

Los operadores por defecto plantean una cuestión importante de confianza y permisos.

La compatibilidad simultánea con ERC-20 genera comportamientos distintos en función de la interfaz de transferencia utilizada.

Las aplicaciones pueden contabilizar dos veces las transferencias si procesan incorrectamente los eventos ERC-777 y ERC-20.

Muchas herramientas y aplicaciones de desarrollo actuales se centran principalmente en ERC-20, lo que reduce las ventajas prácticas de implementar ERC-777.

La eliminación de una implementación mantenida de ERC-777 de una biblioteca de contratos ampliamente utilizada aumenta el trabajo necesario para crear y mantener de forma segura un nuevo despliegue.

Por qué ERC-777 tuvo una adopción limitada

Cuando se introdujo ERC-777, ERC-20 ya contaba con una amplia compatibilidad en wallets, aplicaciones, herramientas de análisis y sistemas de contratos inteligentes.

Para sustituir ese efecto de red hacían falta ventajas suficientes que justificasen la nueva lógica de registro y devolución de llamadas.

Muchos protocolos se habían creado en torno al comportamiento predecible de transferencias y asignaciones de ERC-20.

Los hooks de ERC-777 introdujeron llamadas externas inesperadas en operaciones que algunos integradores consideraban simples actualizaciones de saldo.

La sección de motivación de ERC-2612 señala que ERC-777 añadió una funcionalidad considerable que podía generar comportamientos inesperados en los contratos más extendidos.

Los desarrolladores optaron cada vez más por abordar problemas concretos de usabilidad mediante extensiones más limitadas de ERC-20, en lugar de adoptar un ciclo de transferencia completamente distinto.

Por tanto, ERC-777 sigue teniendo importancia técnica, pero no es la opción predeterminada para la mayoría de los nuevos proyectos de tokens fungibles en Ethereum.

¿Deberían los desarrolladores crear un nuevo token ERC-777?

El primer paso es determinar qué función de ERC-777 es esencial para el token propuesto.

Si el objetivo principal son las aprobaciones firmadas, una extensión más limitada de ERC-20 puede ofrecer esa función sin introducir hooks de transferencia universales.

Si se necesitan devoluciones de llamada del destinatario, el desarrollador debe valorar si un contrato de aplicación específico puede ofrecer un comportamiento más seguro y explícito.

Una nueva implementación de ERC-777 exige revisar cuidadosamente la especificación completa, el registro ERC-1820, los hooks, los operadores, los eventos, la acuñación, la quema y la compatibilidad con ERC-20.

No es seguro reutilizar una implementación antigua sin mantenimiento sin revisar los cambios del compilador y los supuestos de seguridad conocidos.

Antes de controlar activos valiosos, el contrato debe someterse a pruebas unitarias, pruebas fuzz, pruebas de invariantes, pruebas de integración y una revisión de seguridad independiente exhaustivas.

Los desarrolladores también deben confirmar que las wallets, los sistemas de custodia, los puentes y las aplicaciones descentralizadas previstas admiten el comportamiento de devolución de llamada del token.

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

El primer paso es verificar la dirección del contrato del token mediante una fuente autorizada.

El segundo es confirmar si el contrato solo admite ERC-777 o si también expone funciones ERC-20.

El tercero es inspeccionar los operadores por defecto y determinar qué autoridad tienen.

El cuarto es revisar los permisos de acuñación, quema, pausa, congelación, actualización y administración.

El quinto es averiguar si el contrato utiliza un proxy cuya lógica pueda cambiar después de la compra.

El sexto es comprobar las auditorías, la verificación del código fuente, la cobertura de las pruebas y el historial de incidentes.

El séptimo es revisar las autorizaciones de operadores y revocar los permisos que ya no sean necesarios.

El octavo es verificar que la aplicación receptora admita explícitamente ERC-777 y sus hooks.

El noveno es probar una transacción pequeña antes de transferir una cantidad significativa.

El décimo es recordar que cumplir una interfaz de token no demuestra su valor financiero, solvencia ni seguridad como inversión.

Ejemplo de un pago con ERC-777

Supongamos que un usuario quiere pagar una suscripción on-chain con un token ERC-777.

El contrato de suscripción registra mediante el registro ERC-1820 una implementación de

ERC777TokensRecipient
.

El usuario llama a

send
con la dirección del contrato, la cantidad del pago y la referencia de suscripción codificada.

Si el usuario ha registrado un hook de emisor, el token lo comprueba y lo llama antes de modificar los saldos.

El token reduce el saldo del usuario y aumenta el saldo del contrato de suscripción.

A continuación, llama al hook

tokensReceived
del contrato con los detalles del pago.

El contrato de suscripción verifica la dirección del token, el pagador, la cantidad y la referencia adjunta antes de ampliar la suscripción.

Si el hook rechaza el pago, toda la transacción se revierte y los saldos de tokens vuelven a su estado anterior.

Este flujo muestra la función de pago y notificación atómicos que motivó ERC-777.

Errores habituales con ERC-777

Un error habitual es suponer que ERC-777 es simplemente un sustituto más reciente de ERC-20.

Otro es considerar que una transferencia de tokens no activa devoluciones de llamada.

Un tercer error es aceptar llamadas a

tokensReceived
sin verificar el contrato de token que las realiza.

Un cuarto error es autorizar a un operador sin entender que el permiso puede abarcar todo el saldo del titular.

Un quinto error es ignorar los operadores por defecto definidos al crear el token.

Un sexto error es procesar los eventos

Sent
y
Transfer
como movimientos económicos independientes.

Un séptimo error es enviar tokens a un contrato mediante la interfaz ERC-20 y suponer que la protección de receptores ERC-777 obligará a revertir la operación.

Un octavo error es desplegar una implementación antigua sin pruebas modernas ni revisión de dependencias.

Un noveno error es asumir que el estado Final de una EIP implica compatibilidad con las bibliotecas actuales o una adopción amplia en el ecosistema.

Un décimo error es considerar que cumplir un estándar demuestra que un token es legítimo o seguro.

Preguntas frecuentes

¿Qué significa ERC-777?

ERC-777 es un estándar Final de Ethereum para tokens fungibles que define hooks, operadores, campos de datos, envíos y quemas de tokens.

¿ERC-777 es fungible o no fungible?

ERC-777 es un estándar de tokens fungibles cuyas unidades son intercambiables entre sí dentro de un mismo token.

¿Sigue siendo válido ERC-777?

Sí. La propuesta oficial sigue en estado Final, aunque la adopción es limitada y una importante biblioteca de contratos eliminó su implementación de ERC-777.

¿ERC-777 es lo mismo que ERC-20?

No. ERC-777 añade hooks, operadores, datos adjuntos y comprobaciones de receptores, aunque un token puede admitir ambos estándares.

¿Cuál es la principal función de ERC-777?

Su función más conocida es notificar a los contratos registrados del emisor y del destinatario durante los movimientos de tokens.

¿Qué es tokensReceived?

tokensReceived
es el hook del destinatario que se llama después de aumentar el saldo ERC-777 mediante un envío o una acuñación.

¿Qué es tokensToSend?

tokensToSend
es el hook del emisor que se llama antes de reducir un saldo ERC-777 mediante un envío o una quema.

¿Qué es un operador ERC-777?

Un operador es una dirección autorizada para enviar o quemar tokens en nombre de un titular.

¿Puede un operador ERC-777 mover todos los tokens de un usuario?

La autorización normal de un operador no es una asignación numérica, por lo que un operador autorizado puede tener un control amplio hasta que el titular lo revoque.

¿Qué es un operador por defecto?

Un operador por defecto es una dirección autorizada para todos los titulares desde la creación del token, aunque cada titular debe poder revocarla personalmente.

¿Por qué ERC-777 utiliza ERC-1820?

ERC-1820 permite al token detectar qué contratos implementan hooks de emisor y destinatario e interfaces de token compatibles.

¿Se pueden enviar tokens ERC-777 a un contrato inteligente?

Sí, pero un envío nativo de ERC-777 debe revertirse si el contrato receptor no ha registrado el hook de destinatario requerido.

¿Pueden quedar bloqueados los tokens ERC-777 en un contrato?

Las comprobaciones de receptores reducen este riesgo en los envíos nativos, pero las transferencias compatibles con ERC-20 y una lógica defectuosa del destinatario todavía pueden provocar saldos inaccesibles.

¿ERC-777 tiene decimales?

El estándar utiliza una unidad de visualización con 18 decimales y, si se implementa la función opcional

decimals
compatible con ERC-20, esta debe devolver 18.

¿Qué es la granularidad de ERC-777?

La granularidad es la menor cantidad interna que se puede acuñar, enviar o quemar.

¿Por qué ERC-777 puede provocar reentrancia?

Sus hooks ejecutan código de contratos externos durante las operaciones con tokens, lo que permite a una implementación del emisor o del destinatario llamar a otras funciones antes de que finalice la llamada original.

¿Son inseguros todos los tokens ERC-777?

No, pero todas las integraciones deben gestionar deliberadamente las devoluciones de llamada, los permisos de operadores, las consultas a ERC-1820 y la lógica específica de cada contrato de token.

¿Por qué se eliminó la implementación de ERC-777 de OpenZeppelin Contracts?

La implementación tenía una adopción limitada y su complejo comportamiento de hooks dificultaba mantenerla de forma segura como componente de uso general.

¿Puede seguir funcionando un token ERC-777 existente?

Sí. Los contratos desplegados continúan funcionando conforme a su código, salvo que cambie su propio mecanismo de actualización o administración.

¿Debería utilizarse ERC-777 para un token nuevo?

La decisión depende de si los hooks y operadores aportan ventajas esenciales que justifiquen la mayor complejidad de seguridad, integración y mantenimiento.

Conclusión

ERC-777 es un estándar Final de Ethereum para tokens fungibles, diseñado para mejorar las interacciones con tokens mediante hooks, operadores, datos de transacción y comprobaciones de contratos receptores.

Su función

send
puede transferir tokens y notificar a un contrato receptor compatible en una única transacción atómica.

Los hooks

tokensToSend
y
tokensReceived
permiten aplicar reglas programadas para emisores y destinatarios.

Los operadores ofrecen un control delegado estandarizado, mientras que los operadores por defecto pueden proporcionar funciones para todo el sistema, sujetas a la revocación por parte del titular.

ERC-1820 proporciona el registro utilizado para detectar estos hooks e interfaces.

ERC-777 puede seguir siendo compatible con ERC-20, pero las transferencias realizadas mediante ambas interfaces no siempre tienen el mismo comportamiento con los destinatarios.

Las mismas funciones de devolución de llamada que mejoran la componibilidad pueden permitir la reentrancia y dificultar la comprensión de las integraciones.

Los desarrolladores deben verificar quién realiza las llamadas, proteger todas las funciones relacionadas que modifican el estado, revisar la autoridad de los operadores, probar hooks maliciosos y entender el ciclo completo de transferencia.

Aunque el estándar sigue en estado Final, su adopción limitada y su eliminación de una importante biblioteca actual de contratos lo convierten en una opción especializada, no predeterminada, para nuevos tokens.

Entender ERC-777 ayuda a usuarios y desarrolladores de criptomonedas a reconocer tanto las ventajas de las devoluciones de llamada de tokens como los riesgos de seguridad que surgen cuando las transferencias de tokens fungibles pueden ejecutar código externo.
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?