---
title: "Firma del wallet"
description: "Una firma del wallet prova che una chiave o un account a contratto ha approvato dati esatti secondo regole precise. Distingue messaggi, transazioni, permit, 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.
# Firma del wallet
> Solo a scopo didattico; non è consulenza finanziaria o di sicurezza. Una richiesta di firma malevola può causare perdite irreversibili.
## Risposta diretta
Una firma del wallet è la prova crittografica che una chiave privata, o la politica di uno smart account, ha approvato uno specifico messaggio codificato. La verifica identifica l'account per quei byte e quelle regole; non prova identità legale, comprensione del firmatario o sincerità della descrizione del sito.
Firmare non è un'azione uniforme. La firma di transazione autorizza direttamente un'operazione di rete. Un messaggio off-chain può essere una richiesta di login senza poteri sugli asset, oppure un ordine, permit di token, istruzione di governance o altra autorizzazione che un relayer invierà dopo. Nessun avviso di gas non significa nessun rischio.
Prima di firmare identifica tipo di richiesta, azione leggibile, dominio o verificatore previsto, chain, contratto verificatore, indirizzi, importi, nonce e scadenza. Rifiuta hash inspiegati, byte illeggibili, campi inattesi o richieste mostrate in modo insufficiente.
## Come funziona
1. L'applicazione codifica una transazione, un messaggio semplice o dati tipizzati. Una minima variazione produce un digest diverso.
2. Il wallet mostra ciò che riesce a decodificare e chiede conferma. La chiave privata resta nel wallet o dispositivo; viene restituita solo la firma del digest.
3. Il verificatore ricostruisce lo stesso digest. Per un account esterno recupera o controlla l'indirizzo; un account a contratto può applicare la politica corrente tramite ERC-1271.
4. Il verificatore interpreta il risultato secondo le regole applicative. Un server può creare una sessione; un contratto può consumare un permit, eseguire un ordine, cambiare governance o effettuare un'altra chiamata autorizzata.
5. La protezione dal replay dipende dall'applicazione. EIP-712 offre codifica tipizzata e separazione del dominio ma non impedisce replay; l'applicazione deve imporre nonce, deadline, verificatore previsto, chain o altro limite monouso.
ERC-191 separa i dati firmati dalla codifica delle normali transazioni Ethereum e definisce formati come `personal_sign`. EIP-712 lega campi strutturati a un dominio che può includere `name`, `version`, `chainId` e `verifyingContract`. I messaggi ERC-4361 includono dominio, URI, ID della chain, nonce e orario di emissione, ma il servizio deve comunque validarli.
## Esempio
Leah riceve dal servizio ufficiale un login ERC-4361 con dominio e URI attesi, nonce nuovo e validità breve. Chiede solo autenticazione. Dopo i controlli firma; il server verifica e crea una sessione. Il messaggio non crea da solo allowance di token né transazioni on-chain.
Su un sito clone il pulsante dice ancora “Accedi”, ma il wallet mostra dati EIP-712 `Permit` con token, spender, importo, nonce e deadline. La firma può permettere a un relayer di creare potere di spesa secondo il contratto. Leah deve rifiutare: il testo del pulsante non cambia i byte firmati.
## Rischi e controlli
- **Significato ingannevole:** una pagina può chiamare login un permit o ordine. Fidati del payload decodificato e del contratto verificato, non del pulsante.
- **Firma cieca:** hash grezzi e byte opachi impediscono una verifica consapevole. Annulla se non puoi riprodurre messaggio e percorso di esecuzione con uno strumento affidabile.
- **Dominio errato:** un marchio noto non autentica `chainId`, `verifyingContract`, dominio web o URI. Controlla ogni campo e l'indirizzo completo separatamente.
- **Replay o esecuzione tardiva:** chi ottiene una firma valida può usarla finché il nonce non è consumato o il deadline scade. Usa nonce nuovi, scadenze brevi e non pubblicare firme.
- **Autorità ampia:** permit, ordini, chiavi di sessione e operazioni smart account possono abilitare azioni successive senza altro avviso. Controlla asset, spender, destinatario, importo, ambito e revoca.
- **Firmatario compromesso:** un hardware wallet ostacola l'estrazione della chiave, non rende sicuro un messaggio malevolo. Se seed phrase o chiave privata sono esposte, considera compromesso l'intero account.
Se hai firmato una richiesta sospetta, conserva payload e firma senza pubblicarli, disconnetti il sito e identifica lo schema. Per approvazioni o transazioni on-chain, verifica lo stato sulla chain corretta e usa revoca, invalidazione del nonce o migrazione documentata. Non esiste una revoca universale delle firme off-chain; disconnettere il sito non le invalida.
## Idee sbagliate comuni
- **“Ogni firma muove fondi.”** Molte servono solo ad autenticare o esprimere intento; alcune autorizzano movimenti successivi.
- **“Senza gas è innocua.”** Un relayer può pagare il gas e inviare permit, ordine o altra autorizzazione firmata.
- **“EIP-712 garantisce sicurezza.”** Migliora visualizzazione e separazione del dominio, ma non impedisce replay né verifica le affermazioni dell'app.
- **“L'indirizzo recuperato prova consenso informato.”** Collega dati esatti e chiave secondo una regola, non prova identità, comprensione o libertà.
- **“Le firme dei wallet a contratto sono come quelle normali.”** La validità ERC-1271 può dipendere da stato e politica correnti; il verificatore deve interrogare il contratto.
## Argomenti correlati
- [Firma tipizzata EIP-712](/it/crypto/eip712-typed-signature/)
- [Approvazione del wallet](/it/crypto/wallet-approval/)
- [Rischio della firma Permit2](/it/crypto/permit2-signature-risk/)
- [Simulazione della transazione](/it/crypto/transaction-simulation/)
- [Truffa di phishing](/it/crypto/phishing-scam/)
## Fonti
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (consultato: 2026-08-22)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultato: 2026-08-22)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (consultato: 2026-08-22)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultato: 2026-08-22)
- [ERC-4361: Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) - Ethereum Improvement Proposals (consultato: 2026-08-22)
Source: https://wiki.fcontext.com/it/crypto/wallet-signature/index.mdx