---
title: "Assinatura de carteira"
description: "Uma assinatura de carteira prova que uma chave ou conta de contrato aprovou dados exatos sob regras específicas. Entenda mensagens, transações, permits, replay e phishing."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Assinatura de carteira
> Somente para fins educacionais; não é aconselhamento de investimento nem de segurança. Uma solicitação de assinatura maliciosa pode causar perda irreversível.
## Resposta direta
Uma assinatura de carteira é uma evidência criptográfica de que uma chave privada, ou a política de uma conta inteligente, aprovou uma mensagem codificada específica. A verificação identifica a conta signatária para aqueles bytes e regras; não prova a identidade legal, a compreensão do signatário nem que o site descreveu a ação honestamente.
Assinar não é uma ação uniforme. A assinatura de uma transação autoriza diretamente uma operação da rede. Uma mensagem off-chain pode ser um desafio de login sem autoridade sobre ativos, ou uma ordem, permit de token, instrução de governança ou outra autorização que um relayer envie depois. A ausência de aviso de gas não significa ausência de risco.
Antes de assinar, identifique o tipo da solicitação, ação legível, domínio ou verificador pretendido, rede, contrato verificador, endereços, valores, nonce e prazo. Rejeite hashes sem explicação, bytes ilegíveis, campos inesperados ou solicitações que a carteira não exiba o bastante para verificação independente.
## Como funciona
1. O aplicativo codifica uma transação, mensagem simples ou objeto de dados tipados. Uma pequena alteração nos dados gera outro resumo.
2. A carteira exibe o que consegue decodificar e pede aprovação. A chave privada permanece na carteira ou dispositivo; o resumo é assinado e a assinatura é devolvida.
3. O verificador reconstrói o mesmo resumo. Em uma conta externa, normalmente recupera ou confere o endereço; uma conta de contrato pode aplicar sua política atual via ERC-1271.
4. O verificador interpreta o resultado pelas regras do aplicativo. Um servidor pode criar uma sessão; um contrato pode consumir um permit, executar uma ordem, alterar a governança ou fazer outra chamada autorizada.
5. A proteção contra replay depende do aplicativo. O EIP-712 fornece codificação tipada e separação de domínio, mas não impede replay; o aplicativo deve impor nonce, deadline, verificador pretendido, rede ou outro limite de uso único.
O ERC-191 separa dados assinados da codificação de transações Ethereum e define formatos como `personal_sign`. O EIP-712 vincula campos estruturados a um domínio que pode incluir `name`, `version`, `chainId` e `verifyingContract`. Mensagens ERC-4361 incluem domínio, URI, ID da rede, nonce e emissão, mas o serviço também precisa validá-los.
## Exemplo
Leah visita o serviço oficial e recebe um login ERC-4361 com domínio e URI esperados, nonce novo e validade curta. A mensagem pede apenas autenticação. Após conferir domínio e conta, ela assina; o servidor valida e cria uma sessão. Essa mensagem não cria por si só allowance de token nem transação on-chain.
Num site imitador, o botão ainda diz “Entrar”, mas a carteira mostra dados EIP-712 `Permit` com token, spender, valor, nonce e deadline. A assinatura pode permitir que um relayer crie autoridade de gasto conforme o contrato do token. Leah deve recusar: o texto do botão não muda os bytes assinados.
## Riscos e controles
- **Significado enganoso:** uma página pode chamar um permit ou ordem de login. Confie no payload decodificado e no contrato verificado, não no botão.
- **Assinatura cega:** hashes e bytes opacos impedem análise consciente. Cancele se não puder reproduzir a mensagem exata e a rota de execução com ferramenta confiável.
- **Domínio errado:** uma marca conhecida não autentica `chainId`, `verifyingContract`, domínio web ou URI. Confira cada campo e o endereço completo separadamente.
- **Replay ou execução tardia:** quem obtiver uma assinatura válida pode usá-la até o nonce ser consumido ou o deadline expirar. Use nonces novos, prazos curtos e não publique assinaturas.
- **Autoridade ampla:** permits, ordens, chaves de sessão e operações de contas inteligentes podem permitir ações futuras sem novo alerta. Confira ativo, spender, destinatário, valor, escopo e cancelamento.
- **Signatário comprometido:** carteira física protege contra extração da chave, não contra mensagens maliciosas. Se frase-semente ou chave privada vazou, trate a conta inteira como comprometida.
Se assinou algo suspeito, guarde o payload decodificado e a assinatura sem publicá-los, desconecte o site e identifique o esquema. Para aprovação ou transação on-chain, confira o estado na rede correta e use revogação, invalidação de nonce ou migração documentada. Não há revogação universal de assinaturas off-chain, e desconectar o site não as invalida.
## Equívocos comuns
- **“Toda assinatura move fundos.”** Muitas apenas autenticam ou expressam intenção; algumas autorizam uma ação que pode mover fundos depois.
- **“Sem gas é inofensivo.”** Um relayer pode pagar o gas e enviar um permit, ordem ou outra autorização assinada.
- **“O EIP-712 garante segurança.”** Ele melhora exibição estruturada e separação de domínio; não impede replay nem valida alegações do aplicativo.
- **“O endereço recuperado prova consentimento informado.”** Ele liga dados exatos a uma chave sob uma regra, não prova identidade legal, compreensão ou liberdade.
- **“Assinaturas de carteiras de contrato são iguais às comuns.”** A validade ERC-1271 pode depender do estado e política atuais; o verificador deve consultar o contrato.
## Tópicos relacionados
- [Assinatura tipada EIP-712](/pt-br/crypto/eip712-typed-signature/)
- [Aprovação de carteira](/pt-br/crypto/wallet-approval/)
- [Risco de assinatura Permit2](/pt-br/crypto/permit2-signature-risk/)
- [Simulação de transação](/pt-br/crypto/transaction-simulation/)
- [Golpe de phishing](/pt-br/crypto/phishing-scam/)
## Fontes
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (acessado em: 2026-08-22)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (acessado em: 2026-08-22)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (acessado em: 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (acessado em: 2026-08-22)
- [ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) - Ethereum Improvement Proposals (acessado em: 2026-08-22)
Source: https://wiki.fcontext.com/pt-br/crypto/wallet-signature/index.mdx