O que é ERC-677: facilitando as interações com contratos inteligentes

Contratos inteligentes impulsionam quase todas as interações significativas em cadeias EVM — desde a troca de tokens e staking, até a ponte de ativos e o acionamento de atualizações de oráculos. No entanto, o padrão básico de token ERC-20 frequentemente requer padrões de UX de várias etapas, como "aprovar" seguido de "chamar", o que adiciona atrito, custa mais gás e aumenta a chance de erro do usuário. O ERC-677 é uma extensão pragmática do ERC-20 que simplifica esses fluxos combinando uma transferência de token com uma chamada de contrato imediata.

Este artigo explica o que é o ERC-677, como funciona, onde é útil e o que desenvolvedores e usuários devem observar em 2025.

O problema apenas com o ERC-20

O ERC-20 define uma interface simples para tokens fungíveis — transferir, aprovar e transferirDe. Essa simplicidade ajudou o ERC-20 a se tornar a espinha dorsal das Finanças Descentralizadas (DeFi) e das stablecoins, mas também força fluxos de trabalho comuns em duas transações:

• Aprovar o despachante (spender)
• Chamar o contrato do protocolo (que então usa transferFrom)

Este padrão de duas etapas:

• Aumenta a contagem de transações e o gás.
• Cria atrito e confusão na experiência do usuário (UX).
• Pode introduzir condições de corrida de aprovação e permissões pendentes. Veja as orientações da OpenZeppelin sobre o ajuste de permissões para mitigar problemas com a semântica de aprovação. Recomendações de permissão ERC-20 da OpenZeppelin

Para um resumo sobre o próprio ERC-20, consulte a documentação do Ethereum.org. Visão geral do padrão ERC-20

O que o ERC-677 adiciona

O ERC-677 estende o ERC-20 com uma função chave: transferAndCall. Em uma transação, o token é transferido para um contrato receptor e, imediatamente, invoca um callback predefinido (comumente onTokenTransfer) nesse receptor com dados arbitrários.

Fluxo de alto nível:

1. O usuário assina um transferAndCall no token ERC-677.
2. O contrato do token transfere tokens para o receptor.
3. O contrato do token chama recipient.onTokenTransfer(sender, amount, data).
4. O contrato receptor executa a lógica — por exemplo, depositar, fazer staking, trocar ou acionar um oráculo.

Este padrão remove a necessidade de uma etapa de aprovação separada e permite que os contratos reajam ao recebimento de tokens imediatamente.

O token LINK da Chainlink é uma implementação conhecida do ERC-677, projetada para que os contratos possam reagir às transferências de LINK imediatamente para pagar por serviços de oráculo e interações relacionadas. Token LINK da Chainlink e ERC-677

Usos típicos

• Depósitos de staking e cofres (vaults): Os usuários depositam em uma transação, e o cofre contabiliza o depósito no callback.
• Fluxos de DEX e liquidez: Os protocolos podem receber os tokens e executar a lógica de troca ou adição de liquidez diretamente.
• Oráculos e pagamentos de serviços: Transfira tokens para um contrato de serviço e acione o uso ou a cobrança na mesma chamada. É assim que o ERC-677 do LINK permite pagamentos de oráculos contínuos. Token LINK da Chainlink e ERC-677
• Pontes (Bridges) e protocolos cross-chain: Combine a entrega de tokens com um payload de instrução para ponteamento ou mensagens.
• Interoperabilidade cross-chain: À medida que o uso cross-chain cresce, combinar transferência de valor com execução é útil. O design do CCIP da Chainlink ilustra a crescente demanda por fluxos de tokens programáveis ​​entre redes. O que é CCIP

Como o ERC-677 se compara a alternativas

• ERC-1363 (tokens "pagáveis" semelhantes a transferAndCall): Objetivo semelhante — permitir que os contratos reajam ao receber tokens — com callbacks padronizados para fluxos de gastos e aprovação. Bom para experiências semelhantes a pagamentos. Especificação ERC-1363

• ERC-777 (tokens baseados em hooks): Fornece semânticas de token mais ricas e hooks de receptor. Poderoso, mas historicamente veio com mais complexidade e risco de reentrância se os receptores não forem cuidadosamente projetados. Especificação ERC-777

• EIP-2612 (permit) e Permit2: Focam em aprovações sem gás por meio de mensagens assinadas, reduzindo a necessidade de transações de aprovação. Ótimo para DEXes e carteiras, mas geralmente ainda deixa você com uma chamada de contrato subsequente. O ERC-677 reduz as etapas do usuário, agrupando transferência e execução. EIP-2612 permit, Uniswap Permit2

• Abstração de Conta (EIP-4337): Permite que carteiras e patrocinadores (paymasters) agrupem várias operações e patrocinem gás, melhorando a UX. O ERC-677 complementa a Abstração de Conta (AA) ao reduzir ainda mais as etapas do lado do protocolo. Abstração de Conta EIP-4337

Em resumo: permit e AA reduzem o atrito do lado da carteira; o ERC-677 reduz o atrito permitindo que a própria transferência de token acione a lógica do contrato inteligente.

Considerações para desenvolvedores e segurança

Com callbacks ao receber tokens, a cautela é essencial:

• Reentrância: O contrato do token chama a lógica do receptor. Se os receptores chamarem de volta para o token ou outros contratos externos, você pode introduzir vulnerabilidades de reentrância. Use padrões de verificação-efeitos-interações (checks-effects-interactions) ou guardiões (guard patterns) onde apropriado. SWC-107 Reentrância, OpenZeppelin ReentrancyGuard

• Valide o remetente e o token: Certifique-se de que os contratos receptores verifiquem se msg.sender é igual ao contrato de token confiável e valide o endereço do token se vários tokens forem suportados.

• Lista de permissões (Whitelisting): Considere adicionar à lista de permissões os contratos receptores permitidos (ou validar interfaces) para tokens onde o callback pode executar operações sensíveis.

• Design de eventos: A emissão de eventos ricos ajuda na indexação e análise. Mantenha eventos de Transfer compatíveis com ERC-20 juntamente com dados específicos do ERC-677, sempre que viável, para compatibilidade com ferramentas.

• Segurança de fallback: Se o receptor não implementar o callback esperado, a transferência deve reverter ou seguir um caminho de falha seguro e explícito para evitar a perda "silenciosa" de funcionalidade.

• Gás e modos de falha: O callback pode reverter; lide com falhas com mensagens de erro claras e garanta que os usuários entendam se a transferência foi bem-sucedida ou se a transação inteira reverteu.

Para segurança geral de contratos inteligentes, a documentação do Solidity sobre considerações de segurança continua sendo uma leitura essencial. Considerações de segurança do Solidity

UX da carteira: por que isso importa para os usuários

Ao remover a sequência "aprovar e depois chamar", o ERC-677 pode fazer com que interações complexas pareçam uma única ação proposital. Isso reduz a fadiga de assinatura, diminui a sobrecarga cognitiva e geralmente economiza gás. No entanto, a transação única é mais rica: você está transferindo tokens e executando a lógica do contrato. Isso exige visualizações claras, simulação e dados de chamada legíveis das carteiras.

Se você é um usuário preocupado com a segurança interagindo com protocolos que usam ERC-677, usar uma carteira de hardware que exibe nomes de função, parâmetros e mudanças de valor estimadas legíveis pode ajudá-lo a assinar com confiança.

Contexto de 2025: adoção e composabilidade

Em 2025, a tendência continua em direção ao agrupamento de transferência de valor e execução de intenção:

• Mais protocolos preferem depósitos, trocas ou pagamentos de serviços "com um clique" que parecem nativos e reduzem a desordem de aprovação.
• Frameworks cross-chain enfatizam movimentos de tokens programáveis ​​e payloads de mensagens — semânticas semelhantes ao ERC-677 se mapeiam bem para essas arquiteturas. Veja como o CCIP formaliza mensagens programáveis ​​ao lado da transferência de tokens para casos de uso cross-chain. O que é CCIP

Espere maior suporte de carteiras e middleware para simular fluxos de callback, expor riscos e fornecer prompts inteligíveis que tornam as operações combinadas de transferência e execução mais seguras.

Esboço da interface mínima

Conceitualmente, o ERC-677 se parece com isto (as implementações podem variar ligeiramente):

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

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

O contrato do token chama onTokenTransfer no receptor imediatamente após transferir o valor, permitindo que o receptor reaja em uma única transação.

Dicas práticas

• Para desenvolvedores de protocolos: Documente claramente as interfaces de callback esperadas e os motivos de reversão. Quando aplicável, publique listas de permissões ou verificações de interface para que os integradores possam verificar o comportamento.
• Para integradores: Simule transferAndCall para visualizar as mudanças de estado pós-callback. Sinalize receptores arriscados ou callbacks desconhecidos para os usuários.
• Para usuários: Prefira protocolos confiáveis ​​e inspecione as visualizações de transação. Se sua carteira suportar decodificação legível, reserve um momento para revisar os parâmetros passados ​​para o callback.

Você deve usar ERC-677?

Use ERC-677 quando:

• Você deseja eliminar o padrão de aprovar + chamar para fluxos de usuário principais.
• O protocolo se beneficia da reação imediata e atômica ao recebimento de tokens.
• Você pode reforçar os callbacks do receptor contra reentrância e validar minuciosamente as fontes de token.

Se o seu caso de uso for puramente centrado em aprovação (por exemplo, permitir que uma DEX gaste tokens posteriormente), EIP-2612 ou Permit2 podem ser suficientes. Se você precisar de semânticas de hook mais ricas em muitos receptores, avalie o ERC-777, mas esteja ciente de sua complexidade.

Uma nota para usuários OneKey

Transações ERC-677 combinam uma transferência de token com uma chamada de contrato. Ao assinar, é útil ver exatamente qual função será executada e com quais parâmetros. A abordagem de código aberto da OneKey e o suporte a EVM visam fornecer visualizações de chamadas transparentes e assinatura confiável para interações avançadas como transferAndCall, para que usuários avançados possam manter forte segurança enquanto desfrutam de uma UX simplificada.

Ao entender o ERC-677 e usar uma carteira que apresente os detalhes da transação de forma clara, você pode se beneficiar com segurança de interações de contratos inteligentes mais simples e em uma única transação.