Comprar cripto
Mercados
Spot
Centro de eventos
Centro de Recompensas
Mais
0-Fee Fest
ERC-777: O que é ERC-777?ERC-777 é um padrão de token da Ethereum para ativos cripto fungíveis que adiciona hooks de transferência, permissões de operador, dados de transação e verificações mais seguras de conERC-777: O que é ERC-777?ERC-777 é um padrão de token da Ethereum para ativos cripto fungíveis que adiciona hooks de transferência, permissões de operador, dados de transação e verificações mais seguras de con

ERC-777

2026/10/13 15:31
#Advanced
Humanity
H$0.05704-0.60%
o1.exchange
O$0.4138+0.60%
PX
PX$0.0112+2.75%
TokenFi
TOKEN$0.001841-1.76%
AO
AO$3.671+2.51%

O que é ERC-777?

ERC-777 é um padrão de token da Ethereum para ativos cripto fungíveis que adiciona hooks de transferência, permissões de operador, dados de transação e verificações mais seguras de contratos destinatários ao modelo básico de token.

Assim como o ERC-20, ele representa unidades intercambiáveis, nas quais uma unidade do token tem o mesmo valor e as mesmas propriedades que outra unidade do mesmo token.

A especificação oficial do ERC-777 é um padrão Final de Ethereum Request for Comments criado para melhorar a interação de tokens fungíveis com carteiras e contratos inteligentes.

Seus principais recursos são a função

send
, hooks de remetente e destinatário, operadores autorizados, funções de queima integradas e dados opcionais anexados à movimentação de tokens.

O ERC-777 foi projetado para manter compatibilidade retroativa com o ERC-20, permitindo que um contrato de token oferecesse suporte às duas interfaces.

No entanto, a adoção do ERC-777 foi limitada em comparação com a do ERC-20, pois o comportamento de callback e a dependência do ERC-1820 tornam as integrações mais complexas e podem introduzir sérios riscos de reentrância.

O ERC-777 ainda é um padrão ativo?

O ERC-777 continua listado como padrão Final no repositório oficial de Ethereum Improvement Proposals.

O status Final significa que a especificação concluiu o processo de padronização EIP, mas não garante ampla adoção, suporte ativo de bibliotecas nem adequação a todos os novos tokens.

Uma importante biblioteca de contratos inteligentes descontinuou sua implementação do ERC-777 na versão 4.9 e a removeu na versão 5.0.

O changelog atual do OpenZeppelin Contracts registra o fim do suporte à implementação, enquanto as interfaces relacionadas ao padrão continuam disponíveis.

Essa decisão da biblioteca não cancelou o ERC-777 nem alterou seu status Final.

Isso significa que os desenvolvedores não devem esperar uma implementação mantida de token ERC-777 nas versões atuais dessa biblioteca.

Contratos ERC-777 existentes podem continuar operando de acordo com o código implantado, mas novas integrações devem avaliar cuidadosamente o comportamento de callback, as dependências, as auditorias e o suporte do ecossistema.

Por que o ERC-777 foi criado?

O ERC-777 foi criado para resolver diversas limitações de usabilidade e segurança associadas a transferências básicas de ERC-20.

Uma transferência ERC-20 para um contrato não exige que o contrato destinatário reconheça ou processe os tokens.

Isso pode deixar tokens presos quando o contrato não tem uma função para recuperá-los ou contabilizá-los.

Aplicativos ERC-20 também costumam usar um fluxo em duas etapas, no qual o usuário primeiro aprova um spender e depois o spender chama

transferFrom
.

O ERC-777 introduziu

send
para que os tokens pudessem ser transferidos com dados anexados e, ao mesmo tempo, notificar um destinatário compatível na mesma transação.

Também introduziu operadores como um modelo de autorização identificado por nome para contas ou contratos que movimentam tokens em nome dos detentores.

O padrão buscava fazer com que tokens fungíveis se comportassem mais como transferências nativas de ETH, permitindo que remetentes e destinatários controlassem de forma programável as movimentações de tokens.

Como funciona o ERC-777

Um contrato ERC-777 armazena saldos de tokens e a oferta total, além de expor funções padronizadas para enviar, queimar e delegar o controle dos tokens.

Quando os tokens são enviados, o contrato verifica se o remetente registrou um hook de remetente por meio do ERC-1820.

Se houver um hook de remetente, o token o chama antes de alterar os saldos.

Em seguida, o token reduz o saldo do remetente e aumenta o saldo do destinatário.

Após atualizar os saldos, ele verifica se o destinatário registrou um hook de destinatário e o chama quando necessário.

Um hook pode aceitar a movimentação, executar lógica adicional ou reverter toda a transação.

Como a operação é atômica, uma reversão em um hook obrigatório normalmente cancela a movimentação dos tokens e todas as alterações de estado relacionadas naquela transação.

Principais funções do ERC-777

A interface ERC-777 inclui funções para metadados de tokens, saldos, granularidade, operadores, transferências e queimas.

As funções

name
,
symbol
,
totalSupply
e
balanceOf
fornecem informações conhecidas dos tokens ERC-20.

A função

granularity
informa a menor quantidade indivisível que pode ser emitida, enviada ou queimada.

A função

defaultOperators
retorna os operadores autorizados por padrão para todos os detentores, sujeitos ao direito de cada detentor de revogá-los.

A função

isOperatorFor
verifica se um endereço pode atuar como operador de um determinado detentor.

As funções

authorizeOperator
e
revokeOperator
permitem que um detentor gerencie a autorização de operadores.

As funções

send
e
operatorSend
movimentam tokens, enquanto
burn
e
operatorBurn
reduzem permanentemente a oferta.

A função send

A função

send
permite que um detentor transfira tokens diretamente para outro endereço e anexe um campo bytes chamado
data
.

Os dados anexados podem descrever um pagamento, uma ação de aplicativo, um número de referência ou outras informações compreendidas pelo sistema destinatário.

A função aciona os hooks registrados de remetente e destinatário de acordo com as regras do ERC-777.

Quando o destinatário é um contrato, uma operação nativa

send
de ERC-777 deve ser revertida se o contrato não tiver registrado uma implementação de destinatário ERC-777 por meio do ERC-1820.

Essa verificação do destinatário busca reduzir transferências acidentais para contratos incapazes de lidar com os tokens.

Ela não comprova que um destinatário registrado seja honesto, seguro ou financeiramente confiável.

A função operatorSend

A função

operatorSend
permite que um operador autorizado movimente tokens de um detentor para um destinatário.

O operador já precisa estar autorizado para aquele detentor de acordo com as regras do operador do token.

Os campos

data
fornecidos pelo detentor e
operatorData
fornecidos pelo operador podem acompanhar a movimentação.

O endereço do operador, o detentor, o destinatário, a quantidade e os dados são incluídos no evento padronizado

Sent
.

Uma chamada feita por um operador não autorizado deve ser revertida.

A autorização de operador deve ser tratada como sensível, pois pode permitir que outro endereço movimente ou queime os tokens do detentor.

O que é um operador ERC-777?

Um operador é um endereço autorizado a enviar ou queimar tokens ERC-777 em nome de um detentor.

O detentor do token é sempre operador de seu próprio saldo.

Um detentor pode autorizar outra conta ou contrato inteligente e, posteriormente, revogar essa autorização.

Os operadores podem viabilizar pagamentos automatizados, gerenciamento de contas baseado em contratos, atividades programadas, sistemas de recuperação ou outros fluxos de trabalho de delegação de tokens.

Diferentemente de uma allowance numérica ERC-20, a autorização normal de operador não se limita a uma quantidade especificada de tokens.

Essa autoridade mais ampla pode melhorar a usabilidade, mas aumenta o potencial de perdas caso o operador seja malicioso ou comprometido.

Uma carteira deve explicar claramente que autorizar um operador pode conceder a ele controle contínuo sobre o saldo do detentor.

Operadores padrão

Um token ERC-777 pode definir operadores padrão que são autorizados inicialmente para todos os detentores.

A lista de operadores padrão deve ser definida quando o contrato do token é criado e não pode ser ampliada nem reduzida posteriormente de acordo com o padrão.

Cada detentor deve poder revogar um operador padrão para seus próprios tokens.

O detentor também deve poder voltar a autorizar um operador padrão que tenha revogado anteriormente.

Os operadores padrão podem oferecer serviços para todo o sistema sem exigir que cada detentor faça uma transação inicial de autorização.

Eles também criam uma importante consideração de confiança, pois um operador padrão começa com ampla autoridade sobre os detentores do token.

Os usuários devem verificar a lista de operadores padrão e entender a finalidade de cada operador antes de manter uma quantidade significativa de um token ERC-777.

Hooks de remetente

O hook de remetente do ERC-777 é chamado

tokensToSend
.

Um detentor pode registrar um contrato que implemente esse hook por meio do registro ERC-1820.

O contrato do token deve chamar o hook antes de reduzir o saldo do detentor durante um envio ou uma queima de ERC-777.

O hook recebe o operador, o remetente, o destinatário, a quantidade, os dados do detentor e os dados do operador.

Ele pode analisar a movimentação proposta e revertê-la se as regras programadas pelo detentor a rejeitarem.

Uma carteira inteligente poderia usar um hook de remetente para aplicar políticas de gastos, notificações ou lógica de autorização adicional.

O contrato do hook deve verificar se as chamadas vêm de um contrato de token esperado, pois o mesmo hook registrado pode receber chamadas relacionadas a diferentes tokens ERC-777.

Hooks de destinatário

O hook de destinatário do ERC-777 é chamado

tokensReceived
.

Um endereço destinatário pode registrar um contrato que implemente esse hook por meio do registro ERC-1820.

O token chama o hook após aumentar o saldo do destinatário durante um envio ou uma emissão.

O hook pode atualizar a contabilidade interna, acionar outra ação de contrato, registrar dados de pagamento ou rejeitar o recebimento ao reverter a operação.

Esse design permite que a transferência do token e a resposta do destinatário aconteçam em uma única transação atômica.

Isso também significa que o recebimento de tokens ERC-777 pode executar código externo antes de a chamada original do token ser concluída.

Qualquer protocolo que receba tokens ERC-777 deve levar esse comportamento de callback em conta em todas as funções relevantes que alterem o estado.

O que é ERC-1820?

O ERC-777 depende do ERC-1820 para localizar hooks de remetente, hooks de destinatário e interfaces compatíveis.

A especificação do ERC-1820 define um registro universal no qual um endereço pode publicar quais interfaces oferece e qual contrato as implementa.

O registro pode representar interfaces tanto de contas comuns quanto de contratos inteligentes.

Uma conta pode se registrar como implementadora ou designar outro contrato para gerenciar uma interface em seu nome.

Antes de chamar um hook ERC-777, o token consulta o registro para localizar a implementação pertinente de remetente ou destinatário.

Essa dependência do registro adiciona uma consulta a um contrato externo às operações ERC-777.

Uma rede compatível precisa ter a implantação esperada do registro ERC-1820 e o comportamento de integração adequado para que uma implementação padrão funcione corretamente.

Eventos ERC-777

O ERC-777 define os eventos

Sent
,
Minted
,
Burned
,
AuthorizedOperator
e
RevokedOperator
.

O evento

Sent
identifica o operador, o remetente, o destinatário, a quantidade, os dados do detentor e os dados do operador.

O evento

Minted
registra a criação de novos tokens e o endereço destinatário.

O evento

Burned
registra a destruição de tokens e o detentor afetado.

Os eventos de operador permitem que carteiras e serviços de monitoramento acompanhem alterações na autoridade delegada.

Um token que também ofereça suporte ao ERC-20 pode emitir eventos ERC-20

Transfer
, além dos eventos ERC-777 exigidos pela especificação.

Os aplicativos devem evitar contabilizar duas vezes uma movimentação econômica quando os dois tipos de evento descrevem a mesma transferência.

Granularidade e exibição de decimais

A granularidade é a menor quantidade interna de token que um contrato ERC-777 permite emitir, enviar ou queimar.

O valor é definido quando o contrato é criado e não pode ser alterado de acordo com o padrão.

Todos os valores de saldo e de movimentação devem ser múltiplos da granularidade do token.

A maioria dos tokens usa granularidade igual a um, o que permite movimentar cada unidade interna inteira.

O ERC-777 define a denominação de exibição como 18 casas decimais em relação à unidade interna.

Se um token ERC-777 também expuser a função opcional ERC-20

decimals
, a especificação exige que ela retorne 18.

Os aplicativos devem usar aritmética de inteiros e formatar valores para exibição, em vez de calcular saldos de tokens com números de ponto flutuante.

Compatibilidade entre ERC-777 e ERC-20

O ERC-777 foi projetado para que um token pudesse implementar funções ERC-20 junto à interface ERC-777.

O padrão ERC-20 define funções conhecidas, como

transfer
,
approve
,
allowance
e
transferFrom
.

Um token compatível com os dois padrões pode funcionar com carteiras e aplicativos antigos que conhecem apenas o ERC-20.

Os hooks do ERC-777 ainda podem ser acionados em transferências compatíveis com ERC-20 quando o remetente ou destinatário pertinente tiver registrado um hook.

No entanto, a proteção de contratos destinatários difere entre as duas interfaces.

Uma operação nativa

send
de ERC-777 para um contrato destinatário não registrado deve ser revertida, enquanto uma transferência compatível com ERC-20 pode continuar e deixar os tokens naquele contrato.

Os integradores precisam identificar qual função está sendo chamada, em vez de presumir que toda movimentação do mesmo token tem comportamento idêntico de callback e recebimento.

ERC-777 vs. allowances ERC-20

O ERC-20 normalmente concede a um spender uma allowance numérica que limita quantos tokens ele pode transferir de um proprietário.

O ERC-777 concede a um operador autoridade sobre o saldo de um detentor até que essa autoridade seja revogada.

O modelo de operador oferece uma função identificada por nome mais clara e oferece suporte a ações padronizadas de envio e queima.

O modelo de allowance pode impor um limite de quantidade mais restrito, embora às vezes os usuários aprovem quantidades muito maiores do que o necessário.

Ambos os sistemas podem causar perdas quando os usuários autorizam contratos maliciosos ou comprometidos.

As carteiras devem indicar se uma ação cria uma allowance fixa, uma allowance ilimitada ou autoridade de operador ERC-777.

Revogar um tipo de permissão não necessariamente revoga o outro quando um token oferece suporte aos dois padrões.

Risco de reentrância do ERC-777

O principal risco de integração do ERC-777 vem de seus hooks.

Um hook de destinatário executa código de contrato externo durante a transferência do token.

Esse código externo pode chamar de volta o protocolo remetente antes de a função original do protocolo terminar.

Esse comportamento é chamado de reentrância.

Um protocolo vulnerável pode calcular um saldo, enviar tokens ERC-777, receber um callback e permitir que a chamada repetida execute uma ação com base em uma contabilidade interna desatualizada.

O problema pode ocorrer até quando o protocolo chama uma função no estilo ERC-20, pois um token ERC-777 compatível com ERC-20 pode continuar acionando hooks registrados.

Os desenvolvedores nunca devem presumir que uma transferência de token fungível não aciona callbacks apenas porque o nome da função parece o de uma transferência ERC-20 comum.

Como reduzir o risco de reentrância

Quando a lógica pretendida permitir, um protocolo deve atualizar sua contabilidade crítica antes de fazer uma chamada externa ao token.

Ele deve usar uma proteção adequada contra reentrância em pontos de entrada sensíveis.

As funções relacionadas devem ser analisadas em conjunto, pois impedir a reentrada em uma função ainda pode deixar outra vulnerável a exploits.

O protocolo deve validar o contrato do token, em vez de aceitar ativos arbitrários com comportamento de callback desconhecido.

Os testes devem incluir um hook de remetente malicioso, um hook de destinatário malicioso, movimentação de tokens aninhada, callback revertido e reentrada entre funções.

Os desenvolvedores também devem analisar os fluxos de emissão e queima, pois os hooks do ERC-777 não se limitam a envios comuns.

Uma auditoria pode reduzir os riscos, mas não pode garantir que toda interação de callback seja segura.

Proteção do destinatário e suas limitações

As verificações de destinatário do ERC-777 buscam reduzir o risco de tokens ficarem permanentemente presos em contratos incapazes de processá-los.

Um contrato que recebe tokens por meio de

send
precisa registrar uma implementação de destinatário ERC-777, caso contrário a operação é revertida.

Isso oferece mais proteção do que uma transferência ERC-20 básica, que pode ser concluída mesmo quando o contrato destinatário não tem lógica para lidar com tokens.

No entanto, o registro apenas comprova que uma implementação foi registrada para a interface.

Ele não comprova que o destinatário contabilize os saldos corretamente, permita saques ou tenha passado por uma auditoria de segurança.

Um destinatário malicioso pode aceitar tokens intencionalmente e, em seguida, aplicar uma lógica prejudicial.

Os usuários ainda precisam verificar o contrato de destino e a finalidade da transação.

Benefícios do ERC-777

O ERC-777 pode notificar contratos quando eles recebem tokens fungíveis.

Ele pode combinar a transferência e o processamento pelo destinatário em uma única transação.

Ele permite que remetentes e destinatários rejeitem movimentações por meio de hooks programáveis.

Ele oferece suporte a dados anexados que os aplicativos podem usar para interpretar um pagamento ou uma ação.

Seu modelo de operador fornece controle delegado padronizado e revogação explícita.

Envios nativos de ERC-777 reduzem transferências acidentais para contratos que não registram suporte a recebimento de tokens.

A compatibilidade retroativa pode permitir que um token funcione com a infraestrutura ERC-20 enquanto oferece comportamento mais avançado a aplicativos compatíveis com ERC-777.

Limitações do ERC-777

Os hooks tornam mais difícil para os contratos inteligentes analisar com segurança a movimentação de tokens.

A consulta ao ERC-1820 adiciona uma dependência externa e mais complexidade de integração.

A autoridade dos operadores pode ser mais ampla do que os usuários esperam.

Operadores padrão introduzem uma consideração importante de confiança e permissões.

A compatibilidade dupla com ERC-20 cria comportamentos diferentes conforme a interface de transferência usada.

Os aplicativos podem contabilizar transferências duas vezes quando processam incorretamente eventos ERC-777 e ERC-20.

Muitas ferramentas e aplicativos de desenvolvimento atuais se concentram principalmente no ERC-20, reduzindo o benefício prático da implementação do ERC-777.

A remoção de uma implementação mantida do ERC-777 de uma biblioteca de contratos amplamente usada aumenta o trabalho necessário para criar e manter uma nova implantação com segurança.

Por que o ERC-777 teve adoção limitada

O ERC-20 já contava com amplo suporte em carteiras, aplicativos, ferramentas de análise e sistemas de contratos inteligentes quando o ERC-777 foi introduzido.

Substituir esse efeito de rede exigia benefícios suficientes para justificar a nova lógica de callbacks e registros.

Muitos protocolos foram desenvolvidos em torno do comportamento previsível de transferências e allowances do ERC-20.

Os hooks do ERC-777 introduziram chamadas externas inesperadas em operações que alguns integradores presumiam ser simples atualizações de saldo.

A seção de motivação da ERC-2612 observa que o ERC-777 adicionou funcionalidades substanciais que poderiam gerar comportamentos inesperados em contratos de uso geral.

Os desenvolvedores passaram cada vez mais a resolver problemas específicos de usabilidade com extensões mais restritas do ERC-20, em vez de adotar um ciclo de transferência completamente diferente.

Por isso, o ERC-777 continua sendo tecnicamente importante, mas não é a escolha padrão de token fungível para a maioria dos novos projetos Ethereum.

Os desenvolvedores devem criar um novo token ERC-777?

Primeiro, o desenvolvedor deve identificar qual recurso do ERC-777 é essencial para o token proposto.

Se o objetivo principal forem aprovações assinadas, uma extensão mais restrita do ERC-20 pode oferecer esse recurso sem introduzir hooks universais de transferência.

Se callbacks de destinatário forem necessários, o desenvolvedor deve avaliar se um contrato de aplicativo específico pode oferecer um comportamento mais seguro e explícito.

Uma nova implementação de ERC-777 exige uma análise cuidadosa da especificação completa, do registro ERC-1820, dos hooks, operadores, eventos, emissão, queima e compatibilidade com ERC-20.

Reutilizar uma implementação antiga sem manutenção, sem analisar as alterações do compilador e as premissas de segurança conhecidas, não é seguro.

Antes de controlar ativos valiosos, o contrato deve passar por testes unitários extensos, fuzz testing, testes de invariantes, testes de integração e análise independente de segurança.

Os desenvolvedores também devem confirmar se as carteiras, os sistemas de custódia, as bridges e os aplicativos descentralizados pretendidos oferecem suporte ao comportamento de callback do token.

Como os usuários podem avaliar um token ERC-777

O primeiro passo é verificar o endereço do contrato do token por meio de uma fonte confiável.

O segundo é confirmar se o contrato oferece suporte apenas ao ERC-777 ou também expõe funções ERC-20.

O terceiro é analisar os operadores padrão e determinar que autoridade eles têm.

O quarto é revisar as permissões de emissão, queima, pausa, congelamento, atualização e administração.

O quinto é verificar se o contrato usa um proxy cuja lógica pode mudar após a compra.

O sexto é conferir auditorias, verificação do código-fonte, cobertura de testes e histórico de incidentes.

O sétimo é inspecionar as autorizações de operadores e revogar permissões que não sejam mais necessárias.

O oitavo é verificar se o aplicativo destinatário oferece suporte explícito ao ERC-777 e a seus hooks.

O nono é testar uma transação de baixo valor antes de transferir uma quantia significativa.

O décimo é lembrar que a conformidade com uma interface de token não comprova valor financeiro, solvência ou segurança de investimento.

Exemplo de pagamento com ERC-777

Suponha que um usuário queira pagar por uma assinatura on-chain usando um token ERC-777.

O contrato da assinatura registra uma implementação

ERC777TokensRecipient
por meio do registro ERC-1820.

O usuário chama

send
com o endereço do contrato, o valor do pagamento e a referência da assinatura codificada.

Quando há um hook de remetente registrado, o token verifica se ele existe e o chama antes de alterar os saldos.

O token reduz o saldo do usuário e aumenta o saldo do contrato da assinatura.

Em seguida, chama o hook

tokensReceived
do contrato com os detalhes do pagamento.

O contrato da assinatura verifica o endereço do token, o pagador, o valor e a referência anexada antes de renovar a assinatura.

Se o hook rejeitar o pagamento, toda a transação é revertida e os saldos de tokens voltam ao estado anterior.

Esse fluxo demonstra o recurso de pagamento e notificação atômicos que motivou o ERC-777.

Erros comuns relacionados ao ERC-777

Um erro comum é presumir que o ERC-777 é simplesmente uma versão mais nova do ERC-20.

Outro erro é tratar uma transferência de token como uma operação sem callback.

Um terceiro erro é aceitar chamadas a

tokensReceived
sem verificar o contrato de token que fez a chamada.

Um quarto erro é autorizar um operador sem entender que a permissão pode abranger o saldo total do detentor.

Um quinto erro é ignorar os operadores padrão definidos na criação do token.

Um sexto erro é processar os eventos

Sent
e
Transfer
como movimentações econômicas distintas.

Um sétimo erro é enviar tokens a um contrato pela interface ERC-20 e presumir que a proteção de destinatário do ERC-777 obrigará a reversão.

Um oitavo erro é implantar uma implementação antiga sem testes modernos nem análise das dependências.

Um nono erro é presumir que o status Final de um EIP significa que há suporte atual em bibliotecas ou ampla adoção no ecossistema.

Um décimo erro é tratar a conformidade com padrões como prova de que um token é legítimo ou seguro.

Perguntas frequentes

O que significa ERC-777?

ERC-777 é um padrão Final da Ethereum para tokens fungíveis que define hooks, operadores, campos de dados, envio e queima de tokens.

O ERC-777 é fungível ou não fungível?

ERC-777 é um padrão de token fungível no qual as unidades do mesmo token são intercambiáveis.

O ERC-777 ainda é válido?

Sim. A proposta oficial continua Final, embora a adoção seja limitada e uma importante biblioteca de contratos tenha removido sua implementação do ERC-777.

ERC-777 é igual ao ERC-20?

Não. O ERC-777 adiciona hooks, operadores, dados anexados e verificações de destinatário, embora um token possa oferecer suporte aos dois padrões.

Qual é o principal recurso do ERC-777?

Seu recurso mais conhecido é a capacidade de notificar contratos registrados de remetente e destinatário durante as movimentações de tokens.

O que é tokensReceived?

tokensReceived
é o hook de destinatário chamado após o aumento do saldo ERC-777 por meio de envio ou emissão.

O que é tokensToSend?

tokensToSend
é o hook de remetente chamado antes da redução do saldo ERC-777 por meio de envio ou queima.

O que é um operador ERC-777?

Um operador é um endereço autorizado a enviar ou queimar tokens em nome de um detentor.

Um operador ERC-777 pode movimentar todos os tokens de um usuário?

A autorização normal de operador não é uma allowance numérica; portanto, um operador autorizado pode ter amplo controle até que o detentor revogue a permissão.

O que é um operador padrão?

Um operador padrão é um endereço autorizado para todos os detentores na criação do token, embora cada detentor deva poder revogar essa autorização individualmente.

Por que o ERC-777 usa ERC-1820?

O ERC-1820 permite que o token descubra quais contratos implementam hooks de remetente, hooks de destinatário e interfaces de token compatíveis.

É possível enviar tokens ERC-777 para um contrato inteligente?

Sim, mas uma operação nativa de envio ERC-777 deve ser revertida se o contrato destinatário não tiver registrado o hook de destinatário obrigatório.

Os tokens ERC-777 podem ficar presos em um contrato?

As verificações de destinatário reduzem esse risco em envios nativos, mas transferências compatíveis com ERC-20 e uma lógica defeituosa do destinatário ainda podem criar saldos inacessíveis.

O ERC-777 tem decimais?

O padrão usa uma denominação de exibição com 18 casas decimais, e uma função opcional

decimals
compatível com ERC-20 deve retornar 18.

O que é granularidade no ERC-777?

Granularidade é a menor quantidade interna que pode ser emitida, enviada ou queimada.

Por que o ERC-777 pode causar reentrância?

Seus hooks executam código de contrato externo durante as operações com tokens, permitindo que uma implementação de remetente ou destinatário chame outras funções antes de a chamada original terminar.

Todos os tokens ERC-777 são inseguros?

Não, mas toda integração precisa lidar deliberadamente com callbacks, permissões de operadores, consultas ao ERC-1820 e a lógica específica do contrato do token.

Por que a implementação ERC-777 foi removida do OpenZeppelin Contracts?

A implementação tinha adoção limitada, e seu comportamento complexo de hooks era difícil de oferecer com segurança como componente de uso geral.

Um token ERC-777 existente pode continuar funcionando?

Sim. Os contratos implantados continuam funcionando de acordo com seu código, a menos que seu próprio mecanismo de atualização ou administração os altere.

Um novo token deve usar ERC-777?

A decisão depende de os hooks e operadores oferecerem benefícios essenciais que justifiquem a complexidade adicional de segurança, integração e manutenção.

Conclusão

ERC-777 é um padrão Final da Ethereum para tokens fungíveis, projetado para melhorar as interações com tokens por meio de hooks, operadores, dados de transação e verificações de contratos destinatários.

Sua função

send
pode transferir tokens e notificar um contrato destinatário compatível em uma única transação atômica.

Os hooks

tokensToSend
e
tokensReceived
permitem regras programadas para remetentes e destinatários.

Os operadores oferecem controle delegado padronizado, enquanto os operadores padrão podem disponibilizar funcionalidades para todo o sistema, sujeitas à revogação pelo detentor.

O ERC-1820 fornece o registro usado para localizar esses hooks e interfaces.

O ERC-777 pode manter compatibilidade com o ERC-20, mas as transferências pelas duas interfaces nem sempre têm o mesmo comportamento em relação ao destinatário.

Os mesmos recursos de callback que melhoram a componibilidade podem viabilizar reentrância e dificultar a análise das integrações.

Os desenvolvedores devem verificar os chamadores, proteger todas as funções relacionadas que alteram o estado, inspecionar a autoridade dos operadores, testar hooks maliciosos e entender todo o ciclo de vida da transferência.

Embora o padrão continue Final, sua adoção limitada e a remoção de uma importante biblioteca de contratos atual fazem dele uma opção especializada, e não padrão, para novos tokens.

Entender o ERC-777 ajuda usuários e desenvolvedores de cripto a reconhecer tanto os benefícios dos callbacks de tokens quanto os riscos de segurança criados quando transferências de tokens fungíveis podem executar código externo.

Você também pode gostar

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?