Função Permit (EIP-2612)

O que é a função Permit (EIP-2612)?

A função Permit, definida pela EIP-2612, é uma extensão do token ERC-20 que permite que o proprietário de um token autorize um spender assinando uma mensagem off-chain, em vez de enviar uma transação de aprovação separada on-chain.

No universo cripto, isso é importante porque torna as aprovações de tokens mais simples, baratas e fáceis de combinar com outras ações de contratos inteligentes.

A especificação oficial da EIP-2612 explica que o padrão estende o ERC-20 com uma nova função chamada

, que altera o mapeamento de allowance por meio de uma mensagem assinada, em vez de usar .

Em termos simples, a EIP-2612 permite que o usuário diga: "Autorizo este contrato inteligente a gastar esta quantidade do meu token" assinando uma mensagem em uma carteira.

Outra conta ou contrato pode então enviar essa autorização assinada on-chain.

Isso significa que o proprietário do token não precisa enviar diretamente a transação de aprovação.

Também significa que talvez ele não precise manter o token nativo de gas da rede apenas para aprovar o gasto de um token ERC-20.

A função Permit não transfere tokens por conta própria.

Ela apenas define uma allowance, que pode ser usada posteriormente por

ou por outro fluxo de contrato que consuma a allowance aprovada.

Essa distinção é fundamental, pois aprovar um spender não é o mesmo que enviar tokens a ele.

É melhor entender um permit como uma autorização assinada que atualiza o estado da allowance ERC-20 on-chain depois que a assinatura é enviada.

Principais pontos sobre a função Permit

• • A EIP-2612 adiciona
    permit
    ,
    nonces
    e
    DOMAIN_SEPARATOR
    aos tokens ERC-20.
  • A função Permit permite que usuários aprovem gastos de ERC-20 com uma assinatura off-chain.
  • A mensagem assinada segue as regras de dados estruturados tipados da EIP-712.
  • Um permit altera a allowance, mas não transfere tokens por conta própria.
  • Nonces impedem que a mesma assinatura de permit seja reutilizada.
  • Prazos limitam por quanto tempo um permit assinado pode permanecer válido.
  • O Permit melhora a experiência do usuário, mas não elimina o risco de aprovação nem o phishing de assinaturas.

Por que a EIP-2612 foi criada

Os tokens ERC-20 usam um modelo de aprovação que permite que um endereço autorize outro a gastar tokens em seu nome.

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

, e .

Esse modelo de aprovação permitiu que os tokens fossem usados em carteiras, contratos inteligentes, sistemas de pagamento, interfaces de negociação, protocolos de empréstimo, contratos de staking e outros aplicativos descentralizados.

No entanto, o fluxo normal de aprovação ERC-20 geralmente exige duas transações on-chain.

A primeira é uma transação

.

A segunda é a ação do contrato inteligente que usa os tokens aprovados.

Isso cria atrito para os usuários, que precisam pagar taxa de gas duas vezes, aguardar duas confirmações e entender duas solicitações diferentes da carteira.

Também cria um problema para usuários que têm tokens ERC-20, mas não possuem o token nativo de gas necessário para enviar a transação de aprovação.

A EIP-2612 resolve esse problema específico ao permitir aprovações por meio de uma mensagem assinada.

O proprietário do token assina o permit off-chain, e outra parte pode enviá-lo on-chain.

Isso permite que um fluxo de contrato inteligente combine a aprovação e a ação de forma mais eficiente.

Por exemplo, um usuário pode assinar um permit e, em seguida, fazer com que um contrato o utilize e mova tokens em um único fluxo de transação.

Isso não torna as transações gratuitas na rede.

Alguém ainda paga a taxa de gas para enviar o permit on-chain.

A vantagem é que quem paga a taxa de gas não precisa ser o proprietário do token.

Como funciona a função Permit

A função principal da EIP-2612 tem o seguinte formato:

.

O

é o titular do token que assina a aprovação.

O

é o endereço que receberá a allowance.

O

é a quantidade de tokens aprovada para gasto.

O

é o prazo máximo para usar o permit.

Os valores

, e são partes da assinatura criptográfica.

Quando o permit é enviado, o contrato do token verifica se a assinatura é válida.

Ele também verifica se o prazo expirou.

Além disso, verifica se o nonce usado na mensagem assinada corresponde ao nonce atual do proprietário.

Se todas as verificações necessárias forem aprovadas, o contrato define

com o valor aprovado.

Em seguida, o contrato incrementa o nonce do proprietário para impedir que a mesma assinatura seja reutilizada.

O contrato também emite um evento

, mantendo o comportamento alinhado às expectativas de aprovação do ERC-20.

Esse processo transforma uma assinatura de carteira em uma atualização on-chain da allowance.

As três principais funções da EIP-2612

A EIP-2612 exige que os tokens compatíveis adicionem três funções ao ERC-20.

A primeira função é

.

A função

verifica uma aprovação assinada e atualiza a allowance.

A segunda função é

.

A função

retorna o nonce atual de um endereço proprietário.

A terceira função é

.

A função

retorna o separador de domínio da EIP-712, usado para vincular a assinatura a um contrato de token e a um domínio de assinatura específicos.

Essas três funções trabalham em conjunto.

A assinatura do permit define a aprovação.

O nonce impede a repetição.

O separador de domínio ajuda a vincular a assinatura ao contrato e ao contexto de rede corretos.

Sem esses elementos de suporte, seria muito mais fácil usar indevidamente ou repetir assinaturas de permit no contexto errado.

O que é uma allowance?

Allowance é a quantidade de tokens ERC-20 que o proprietário autorizou um spender a usar.

Por exemplo, se Alice autorizar um contrato inteligente a gastar 100 tokens, a allowance de Alice para esse contrato será de 100 tokens.

O spender poderá então chamar

para mover tokens até o limite aprovado, dependendo do contrato do token e do fluxo do aplicativo.

A função Permit não elimina o sistema de allowance.

Ela altera a forma como a allowance pode ser criada.

Em vez de exigir que o proprietário do token chame diretamente

, a EIP-2612 permite que ele assine uma mensagem autorizando a atualização da allowance.

Isso melhora a usabilidade e mantém a compatibilidade com o conhecido modelo de allowance do ERC-20.

Os usuários ainda devem ter cuidado com as allowances, pois um spender aprovado pode conseguir mover tokens até o limite autorizado.

Uma aprovação ilimitada por permit pode ser conveniente, mas também pode causar grandes perdas se o contrato do spender for malicioso, comprometido ou mal compreendido.

Função Permit vs. função Approve

A função tradicional

é chamada diretamente pelo proprietário do token em uma transação on-chain.

A função Permit é autorizada pelo proprietário do token por meio de uma assinatura off-chain e, depois, enviada on-chain por outra parte.

Com

, o proprietário do token precisa pagar a taxa de gas da transação de aprovação.

Com

, o proprietário assina uma mensagem, e um relayer, aplicativo ou spender pode pagar a taxa de gas para enviá-la.

Com

, a ação de aprovação fica imediatamente vinculada a .

Com

, a ação de aprovação é vinculada a uma assinatura verificada do proprietário.

O resultado pode ser a mesma atualização de allowance, mas a experiência do usuário é diferente.

Por isso, a EIP-2612 é frequentemente descrita como um recurso que permite aprovações sem gas.

De forma mais precisa, ela permite aprovações em que o proprietário do token não precisa enviar a transação de aprovação.

A blockchain ainda exige uma transação e uma taxa de gas para atualizar o estado.

Por que a EIP-712 é importante para o Permit

A EIP-2612 usa dados estruturados tipados com base na EIP-712.

A EIP-712 é um padrão para hash e assinatura de dados estruturados, em vez de sequências de bytes opacas.

Isso é importante porque os usuários de carteiras precisam entender o que estão assinando.

Uma solicitação de assinatura hexadecimal bruta pode ser confusa e perigosa.

Uma assinatura tipada pode exibir campos como proprietário, spender, valor, nonce e prazo com mais clareza.

A EIP-712 também usa um separador de domínio.

O separador de domínio ajuda a distinguir um contexto de assinatura de outro.

No caso da EIP-2612, ele geralmente inclui informações como nome do token, versão, ID da rede e endereço do contrato verificador.

Esse projeto ajuda a impedir que uma assinatura destinada a um token ou rede seja válida em outro contexto.

A própria EIP-712 afirma que não inclui proteção contra repetição por si só.

A EIP-2612 adiciona essa proteção por meio de nonces individuais por proprietário.

Nonces e proteção contra repetição

Um nonce é um número usado uma única vez.

Na EIP-2612, cada endereço proprietário tem um nonce acompanhado pelo contrato do token.

Quando um usuário assina um permit, os dados assinados incluem o nonce atual do proprietário.

Quando o permit é usado com sucesso, o contrato do token incrementa esse nonce.

Se alguém tentar enviar o mesmo permit novamente, o nonce já não corresponderá.

Isso fará a assinatura reutilizada falhar.

A proteção por nonce é essencial porque as assinaturas podem ser copiadas.

Sem essa proteção, um spender ou invasor poderia reutilizar o mesmo permit assinado várias vezes.

Uma boa implementação de permit deve tratar os nonces como parte da mensagem assinada e atualizá-los somente quando um permit for bem-sucedido.

Para os usuários, o significado prático é simples.

Uma assinatura válida de permit deve poder ser usada uma vez, não para sempre.

Prazos e expiração da assinatura

O parâmetro

limita por quanto tempo uma assinatura de permit pode ser usada.

Se o timestamp do bloco atual for posterior ao prazo, o permit deverá falhar.

Isso protege os usuários contra o envio de assinaturas antigas muito depois do momento em que deveriam ser usadas.

Um prazo curto pode reduzir o risco, pois limita o período disponível para o envio.

Um prazo longo pode ser mais conveniente, pois mantém a assinatura utilizável por mais tempo.

Um prazo ilimitado ou muito distante pode ser arriscado, pois a aprovação assinada pode permanecer válida por muito tempo, a menos que seja usada, invalidada ou substituída pelo comportamento do nonce.

Os usuários devem prestar atenção aos prazos quando as carteiras exibirem dados tipados de permit.

Os desenvolvedores devem evitar prazos excessivamente longos, a menos que haja uma justificativa clara.

Os aplicativos devem explicar o significado do prazo de forma compreensível para os usuários.

Separador de domínio e contexto da rede

O separador de domínio é uma parte essencial das assinaturas da EIP-712.

Na EIP-2612, ele ajuda a vincular o permit a um contrato de token e a um domínio específicos.

Um domínio comum inclui o nome do token, a versão do token, o ID da rede e o endereço do contrato verificador.

Isso reduz o risco de um permit assinado para um contrato ser reutilizado em outro contrato.

Também reduz o risco de um permit assinado em uma rede ser reutilizado em outra.

No entanto, a segurança do separador de domínio depende de uma implementação correta.

Se o contrato do token usar um separador de domínio incompleto, o risco de repetição poderá aumentar.

Se o ID da rede mudar ou um contrato for implantado em várias redes, os desenvolvedores precisarão considerar cuidadosamente como separar as assinaturas.

Para os usuários, o separador de domínio geralmente fica oculto na interface da carteira.

Para os desenvolvedores, esse é um dos detalhes mais importantes para uma implementação segura de permit.

Como funcionam as aprovações sem gas

A expressão "aprovação sem gas" pode causar confusão.

A EIP-2612 não torna gratuitas as transações na Ethereum ou em redes EVM.

Ela permite que o proprietário do token aprove gastos assinando uma mensagem em vez de enviar uma transação.

Um relayer, aplicativo, contrato inteligente ou spender pode então enviar o permit assinado on-chain e pagar a taxa de gas.

Isso pode ajudar usuários que têm tokens ERC-20, mas não possuem tokens nativos de gas suficientes para aprová-los.

Também pode ajudar aplicativos a criar experiências mais simples, em uma única etapa.

Por exemplo, um usuário pode assinar um permit e, em seguida, concluir um depósito, pagamento ou ação com tokens sem enviar manualmente uma aprovação separada antes.

A experiência parece mais simples, mas a blockchain ainda registra a alteração de estado por meio de uma transação on-chain.

Os desenvolvedores devem explicar isso claramente, pois, caso contrário, os usuários podem pensar que mensagens assinadas não têm consequências.

Uma assinatura de permit pode ter consequências reais on-chain depois que alguém a envia.

Usos comuns da EIP-2612 em cripto

A EIP-2612 é frequentemente usada em finanças descentralizadas e aplicativos baseados em tokens.

Um protocolo de empréstimo pode usar permit para permitir que o usuário aprove um ativo como garantia e o deposite em um único fluxo.

Um contrato de staking pode usar permit para permitir que o usuário aprove tokens para staking sem uma transação de aprovação separada.

Um aplicativo de pagamento pode usar permit para que o pagador autorize a movimentação de tokens em um processo de checkout mais simples.

Uma carteira pode usar permit para reduzir o número de etapas de transação em interações comuns com ERC-20.

Um serviço de relayer pode pagar a taxa de gas em nome do usuário e recuperar as taxas de outra forma.

Um contrato inteligente pode combinar permit com

para que a aprovação e a movimentação de tokens ocorram no mesmo fluxo de transação.

Esse padrão pode reduzir falhas na experiência do usuário, pois não é necessário minerar a aprovação separadamente antes da ação principal.

Também pode reduzir a confusão, pois o aplicativo pode orientar o usuário por um único processo combinado.

O principal benefício não é apenas economizar gas.

O principal benefício é reduzir o atrito na autorização de tokens.

Função Permit e abstração de contas

A função Permit às vezes é discutida em conjunto com a abstração de contas, pois ambas as ideias melhoram a experiência de uso das carteiras.

O Permit permite que o proprietário de um token ERC-20 autorize alterações na allowance por meio de assinaturas.

A abstração de contas busca tornar as contas cripto mais programáveis e flexíveis.

São ferramentas diferentes, mas compartilham um objetivo semelhante.

Ambas tentam reduzir o atrito nas interações com blockchain.

O Permit se concentra nas aprovações de tokens.

A abstração de contas se concentra de forma mais ampla em como as contas autorizam e pagam por ações.

Um aplicativo cripto pode usar as duas ideias no mesmo projeto de produto.

Por exemplo, uma carteira ou sistema de smart accounts pode permitir transações patrocinadas e, ao mesmo tempo, usar aprovações de tokens compatíveis com permit.

Os usuários não precisam entender todas as camadas técnicas, mas os desenvolvedores devem implementar cada uma corretamente.

Riscos de segurança da função Permit

O principal risco para os usuários é o phishing de assinaturas.

Um site malicioso pode solicitar que o usuário assine um permit que aprova um spender perigoso.

Como uma assinatura de permit não é uma transferência normal de tokens, alguns usuários podem pensar que ela é inofensiva.

Essa suposição é perigosa.

Um permit pode autorizar um spender a mover tokens posteriormente.

Antes de assinar, os usuários devem verificar o endereço do spender, a quantidade de tokens, o nome do token e o prazo.

Os usuários devem rejeitar assinaturas pouco claras, inesperadas ou solicitadas por sites desconhecidos.

Outro risco é a aprovação ilimitada.

Se um usuário assinar um permit com um valor muito alto, o spender poderá obter amplo poder de gasto sobre a allowance daquele token.

Um terceiro risco é uma implementação inadequada.

Se o contrato do token tratar incorretamente os nonces, a separação de domínio, a recuperação de assinatura ou os prazos, as assinaturas poderão ser repetidas ou aceitas quando deveriam falhar.

Um quarto risco é a confusão na interface do usuário.

Se uma carteira não exibir os dados tipados com clareza, os usuários poderão assinar aprovações sem entendê-las.

O Permit melhora a usabilidade, mas também torna mais importante educar os usuários sobre assinaturas.

O Permit não elimina o risco de aprovação

A EIP-2612 altera a forma como uma aprovação é autorizada, mas não muda o risco básico de aprovar um spender.

Se o spender for malicioso, comprometido ou receber uma allowance excessiva, o usuário ainda poderá perder tokens.

Uma aprovação por permit pode ser tão poderosa quanto uma transação normal de

.

A diferença é que a aprovação começa como uma assinatura, em vez de uma transação enviada pelo proprietário do token.

Isso significa que os usuários devem ter com assinaturas de permit o mesmo cuidado que têm com transações de aprovação.

Os usuários devem evitar assinar permits ilimitados, a menos que confiem plenamente no spender e entendam o risco.

Os usuários devem revogar allowances não utilizadas quando não forem mais necessárias.

Os usuários devem usar carteiras separadas para interações com dApps de maior risco e para ativos mantidos no longo prazo.

Antes de aprovar o acesso a tokens valiosos, os usuários devem verificar os endereços dos contratos em fontes confiáveis.

Permit e front-running

Qualquer pessoa que tenha a mensagem assinada pode enviar assinaturas de permit.

Isso exige atenção especial ao front-running.

Se um usuário assinar um permit e enviá-lo a um aplicativo, outra parte que veja a assinatura poderá enviá-la primeiro.

Em muitos casos, isso apenas consome o permit e define a mesma allowance que o usuário pretendia.

No entanto, se um aplicativo esperar que a execução do permit e outra ação ocorram em conjunto, um permit enviado antecipadamente por outra parte poderá fazer a transação combinada posterior falhar, pois o nonce já terá mudado.

Os desenvolvedores devem projetar fluxos que lidem com esse caso de forma adequada.

Muitas vezes, um contrato inteligente pode verificar se a allowance esperada já está disponível e prosseguir, em vez de falhar sem necessidade.

As interfaces também devem explicar claramente quando um fluxo de permit falhar.

Para os usuários, o ponto principal é que os permits assinados podem ser usados por qualquer pessoa até serem utilizados ou expirarem.

Não compartilhe dados de permit assinados a menos que confie no fluxo.

Considerações de implementação para desenvolvedores

Os desenvolvedores devem seguir atentamente a especificação da EIP-2612.

O hash do tipo permit deve corresponder à estrutura de assinatura esperada.

O digest deve usar a codificação da EIP-712 com o separador de domínio e o hash da estrutura do permit.

O contrato deve rejeitar permits expirados.

O contrato deve rejeitar assinaturas inválidas.

O contrato deve rejeitar permits em que o signatário recuperado não seja o proprietário.

O contrato deve rejeitar casos inadequados em que o proprietário seja o endereço zero.

O contrato deve incrementar o nonce do proprietário após a execução bem-sucedida do permit.

O contrato deve emitir o evento padrão

após alterações na allowance.

Sempre que possível, os desenvolvedores devem usar bibliotecas amplamente revisadas.

A documentação ERC20Permit da OpenZeppelin apresenta um padrão de implementação amplamente usado em projetos Solidity.

A OpenZeppelin também documenta o uso de Permit ERC-20 em outros ambientes, como o ERC-20 Permit para Stylus.

Mesmo usando uma biblioteca, os desenvolvedores devem testar cuidadosamente o comportamento específico do token.

Função Permit vs. meta-transações

Uma meta-transação é um padrão mais amplo em que um usuário assina uma mensagem e outra parte envia uma transação em seu nome.

A EIP-2612 pode ser entendida como um padrão específico de assinatura voltado a aprovações.

Ela não transforma todas as ações com tokens em ações assinadas.

Ela padroniza somente aprovações assinadas para allowances de ERC-20.

Esse escopo limitado é intencional.

Um padrão mínimo é mais fácil de adotar e integrar em carteiras, contratos e aplicativos.

Os desenvolvedores que quiserem transferências assinadas, ações em lote ou patrocínio personalizado de gas talvez precisem de contratos ou padrões adicionais.

O Permit é poderoso porque resolve um problema comum sem alterar todo o modelo ERC-20.

Ele complementa os sistemas de meta-transações, em vez de substituí-los por completo.

Função Permit vs. transferência de tokens

Um permit não é uma transferência.

Uma transferência move tokens de um endereço para outro.

Um permit atualiza a allowance que um endereço concede a outro.

Isso significa que um usuário pode assinar um permit e ainda manter os tokens na mesma carteira até que o spender use a allowance.

A movimentação efetiva dos tokens geralmente ocorre por meio de

.

Essa diferença é importante para a segurança da carteira.

Após assinar um permit, o usuário pode não ver uma alteração imediata no saldo de tokens.

Isso não significa que a assinatura seja inofensiva.

O spender ainda poderá ter permissão para mover tokens posteriormente.

Após usar dApps, os usuários devem verificar as allowances ativas e revogar as aprovações que não forem mais necessárias.

Função Permit vs. Permit2

A EIP-2612 é um padrão no nível do token.

O próprio contrato do token precisa implementar a função permit para que o token seja compatível com a EIP-2612.

Outros sistemas de aprovação podem oferecer um comportamento semelhante ao permit por meio de contratos externos.

Esses sistemas não são iguais ao suporte nativo à EIP-2612.

Essa diferença importa porque as solicitações da carteira, os endereços dos spenders, os sistemas de nonce, os escopos de aprovação e os métodos de revogação podem variar.

Ao assinar uma aprovação semelhante a permit, o usuário deve verificar qual contrato está recebendo a autorização.

Ao integrar permits, os desenvolvedores devem verificar se o token oferece suporte direto à EIP-2612 ou se exige outro mecanismo de aprovação.

Chamar toda aprovação assinada de "EIP-2612" pode causar confusão.

A EIP-2612 tem uma interface e uma estrutura de assinatura específicas.

Como os usuários devem interpretar uma solicitação de assinatura de permit

Primeiro, o usuário deve verificar o nome do token.

Em seguida, deve verificar o endereço do spender ou o aplicativo que está solicitando a permissão.

O usuário deve conferir a quantidade aprovada.

Também deve verificar se o valor é limitado ou, na prática, ilimitado.

O usuário deve verificar o prazo.

Também deve confirmar se a solicitação apareceu após uma ação intencional.

Se a solicitação aparecer inesperadamente, o usuário deve rejeitá-la.

O usuário deve ter ainda mais cautela se o site solicitar várias assinaturas seguidas.

O usuário deve evitar assinar mensagens de permit recebidas por links em mensagens diretas, chats falsos de suporte, anúncios suspeitos ou páginas desconhecidas de tokens.

O usuário deve lembrar que assinar um permit pode conceder a outro endereço poder para gastar seus tokens.

Uma solicitação segura na carteira deve exibir esses campos de forma legível, mas os usuários não devem confiar apenas no design da interface.

Por que o Permit melhora a experiência do usuário

O Permit melhora a experiência do usuário ao reduzir o número de transações on-chain necessárias.

Ele pode eliminar a etapa de aprovação separada em muitos fluxos de dApps.

Ele pode permitir que os usuários interajam com tokens ERC-20 mesmo sem tokens nativos de gas suficientes para uma aprovação independente.

Também pode ajudar os aplicativos a patrocinar o gas ou agrupar a aprovação com outra ação.

Ele pode reduzir falhas na experiência do usuário causadas por aprovar um token e depois esquecer de concluir a segunda transação.

Também pode simplificar a integração de usuários que estão começando a usar aplicativos on-chain.

Esses benefícios são especialmente importantes porque as aprovações ERC-20 estão entre os pontos de maior atrito em cripto.

No entanto, uma aprovação mais simples não é automaticamente mais segura.

Uma boa experiência do usuário deve ser acompanhada por solicitações de assinatura claras, projeto cuidadoso dos spenders e gerenciamento fácil das allowances.

Erros comuns relacionados à EIP-2612

Um erro comum é pensar que o permit transfere tokens imediatamente.

O Permit apenas atualiza a allowance.

Outro erro comum é achar que uma aprovação sem gas significa que ninguém paga gas.

Um permit ainda precisa de uma transação on-chain para atualizar o estado do contrato.

Um terceiro erro comum é assinar aprovações ilimitadas sem entender o risco associado ao spender.

Um quarto erro comum é ignorar o campo de prazo.

Um quinto erro comum é confiar em uma solicitação de assinatura apenas porque ela não se parece com uma transação normal.

Um sexto erro comum é presumir que todo token ERC-20 oferece suporte à EIP-2612.

Um sétimo erro comum é integrar o permit sem testar o ID da rede, o separador de domínio e o comportamento dos nonces em diferentes implantações.

Um oitavo erro comum é tratar todos os sistemas semelhantes a permit como se fossem idênticos à EIP-2612.

Um nono erro comum é não tratar o envio antecipado de permits em fluxos combinados de contratos.

Um décimo erro comum é exibir solicitações de permit de uma forma que os usuários não consigam entender.

Boas práticas para usuários

Assine mensagens de permit somente em sites e aplicativos em que confia.

Antes de assinar, confira o token, o spender, a quantidade e o prazo.

Evite aprovações ilimitadas, a menos que haja uma justificativa sólida.

Sempre que possível, use valores de aprovação pequenos.

Revogue allowances antigas que não sejam mais necessárias.

Não assine mensagens de permit recebidas por links aleatórios, mensagens falsas de suporte ou páginas desconhecidas de airdrop.

Use uma carteira separada para dApps experimentais e outra para ativos mantidos no longo prazo.

Leia atentamente os avisos da carteira.

Não presuma que uma assinatura é segura só porque não exibe diretamente uma taxa de gas.

Lembre-se de que outra pessoa pode enviar um permit assinado antes que ele expire.

Boas práticas para desenvolvedores

Sempre que possível, use implementações de permit auditadas e bem mantidas.

Ao declarar suporte à EIP-2612, siga exatamente a interface oficial da EIP-2612.

Use dados tipados da EIP-712 para que as carteiras exibam informações claras sobre a assinatura.

Implemente corretamente a separação de domínio.

Registre nonces por endereço proprietário.

Rejeite assinaturas expiradas.

Rejeite signatários inválidos e casos em que o proprietário seja o endereço zero.

Emita o evento

após atualizações bem-sucedidas da allowance.

Projete fluxos combinados de permit para tolerar o envio do permit antes da transação principal.

Exiba para os usuários, em linguagem simples, os nomes dos spenders, as quantidades de tokens e os detalhes de expiração.

Disponibilize instruções simples sobre como revogar allowances.

Teste assinaturas com diferentes IDs de rede, forks, atualizações e provedores de carteira.

Função Permit em uma frase

A função Permit da EIP-2612 permite que o proprietário de um token ERC-20 aprove um spender por meio de uma assinatura EIP-712, atualizando a allowance on-chain sem que o proprietário envie uma transação de aprovação separada.

Perguntas frequentes

O que é a função Permit da EIP-2612?

A função Permit é uma extensão do ERC-20 que permite que o proprietário de um token aprove um spender com uma assinatura off-chain que pode ser enviada on-chain posteriormente.

O permit transfere tokens?

Não. O permit apenas define uma allowance e não transfere tokens por conta própria.

Por que a EIP-2612 é útil?

A EIP-2612 é útil porque reduz o atrito das aprovações, permite experiências de aprovação sem gas e possibilita que aplicativos combinem aprovações com outras ações de contratos inteligentes.

O proprietário do token paga gas ao usar o permit?

O proprietário do token não precisa enviar a transação de aprovação, mas alguém ainda precisa pagar a taxa de gas para enviar o permit assinado on-chain.

Qual é a diferença entre approve e permit?

Approve é uma transação on-chain enviada pelo proprietário do token, enquanto permit é uma assinatura off-chain que outra parte pode enviar on-chain.

Qual é a relação entre a EIP-712 e o permit?

A EIP-712 fornece a assinatura de dados estruturados tipados, que ajuda as carteiras a exibir os detalhes do permit com mais clareza e a vincular assinaturas a um domínio definido.

O que é um nonce na EIP-2612?

Um nonce é um valor individual por proprietário que impede a reutilização da mesma assinatura de permit.

O que é o prazo de um permit?

O prazo é o momento de expiração após o qual a assinatura do permit deixa de ser válida.

A EIP-2612 é segura?

A EIP-2612 pode ser segura quando implementada e usada corretamente, mas os usuários ainda precisam ficar atentos a phishing de assinaturas, aprovações ilimitadas, spenders maliciosos e solicitações pouco claras na carteira.

Todos os tokens ERC-20 oferecem suporte a permit?

Não. Somente tokens ERC-20 que implementam a extensão EIP-2612 oferecem suporte à função Permit padrão.

Uma assinatura de permit pode sofrer front-running?

Sim. Qualquer pessoa que tenha uma assinatura válida de permit pode enviá-la antes de outra transação. Por isso, os desenvolvedores devem projetar fluxos que considerem essa possibilidade.

Como os usuários podem reduzir os riscos do permit?

Os usuários podem reduzir os riscos do permit verificando o spender, limitando os valores de aprovação, usando prazos curtos, evitando sites suspeitos e revogando allowances não utilizadas.

Conclusão

A função Permit da EIP-2612 é uma das melhorias mais úteis para a experiência de aprovação do ERC-20.

Ela permite que os usuários autorizem allowances de tokens por meio de assinaturas, em vez de transações de aprovação separadas.

Isso pode reduzir o atrito relacionado ao gas, melhorar a integração em dApps, permitir fluxos de transações patrocinadas e facilitar a combinação de interações com ERC-20 em uma única jornada do usuário.

O padrão usa dados estruturados tipados da EIP-712, separação de domínio, nonces e prazos para tornar as aprovações assinadas mais seguras e específicas.

No entanto, o permit não elimina o risco básico das allowances de tokens.

Um permit assinado ainda pode conceder a um spender poder real sobre os tokens do usuário.

Os usuários devem tratar assinaturas de permit com a mesma seriedade que transações de aprovação.

Os desenvolvedores devem implementar o padrão com cuidado, exibir informações claras sobre as assinaturas e lidar com casos extremos, como proteção contra repetição, assinaturas expiradas e envio antecipado de permits.

Quando usada corretamente, a EIP-2612 facilita o uso de tokens ERC-20 sem alterar a ideia central de gastos de tokens baseados em allowance.

É um padrão pequeno, mas importante, que melhora a usabilidade prática dos aplicativos cripto e mantém a compatibilidade com o ecossistema ERC-20 mais amplo.