---
title: "Decodifica della calldata in un wallet"
description: "Una guida orientata alla verifica di calldata, parole e offset ABI, collisioni dei selettori, proxy, batch, approvazioni, permit con dati tipizzati, simulazione e riconciliazione post-transazione."
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.
# Decodifica della calldata in un wallet
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
La calldata è la sequenza immutabile di byte fornita come input a una transazione Ethereum di primo livello o a una chiamata interna. Una chiamata convenzionale a una funzione Solidity inizia con un selettore di `4-byte`, seguito dagli argomenti codificati secondo l'ABI, ma la calldata non è autodescrittiva: gli stessi byte possono assumere significati diversi per differenti codici runtime, implementazioni proxy o schemi. Le funzioni fallback, l'assembly grezzo e i protocolli non Solidity non sono tenuti a seguire l'ABI convenzionale delle funzioni.
Un wallet dovrebbe quindi mostrare più di un possibile nome di funzione. Una revisione sicura associa i byte a `chainId`, un blocco, `from`, `to`, il `value` nativo, il `codeHash` runtime, l'implementazione attiva e un'ABI affidabile; decodifica rigorosamente ogni chiamata annidata; distingue la calldata on-chain dalle firme EIP-712; simula in uno stato esplicito; e riconcilia la ricevuta e le variazioni di stato effettive dopo l'inclusione.
## Come funziona
1. Fissa l'envelope di firma e il punto di osservazione: `chainId`, numero e hash del blocco, `from`, `to`, `value` nativo, byte di input, nonce e campi delle commissioni. Conserva la fonte del wallet o RPC; un payload decodificato su un'altra rete o in un altro blocco non rappresenta la stessa affermazione.
2. Classifica l'oggetto prima della decodifica. Una transazione, una richiesta EIP-712 di dati tipizzati, un permit ERC-2612, una UserOperation ERC-4337 e un messaggio personal-sign grezzo utilizzano domini e schemi diversi; non forzarli tutti nell'ABI delle transazioni.
3. Risolvi il target al blocco fissato. Leggi il bytecode runtime e il `codeHash`; identifica proxy, beacon o implementazione quando applicabile; registra gli slot di implementazione e amministrazione; e ottieni un'ABI corrispondente a quella versione esatta del codice. Un registro di selettori fornisce candidati, non autorità.
4. Decodifica rigorosamente. Il selettore è costituito dai primi `4 bytes` del Keccak-256 della firma canonica della funzione, esclusi i tipi restituiti. I valori statici occupano parole di `32-byte`; le head dinamiche contengono offset dall'inizio del blocco degli argomenti dopo il selettore. Rifiuta dati troncati, offset fuori limite, lunghezze impossibili, padding non valido e byte finali inspiegati.
5. Espandi ricorsivamente multicall, calldata annidata ed esecuzione delegata. Per ogni chiamata figlia, elenca target, valore nativo, selettore, argomenti, tipo di chiamata ed eventuale indicatore `allowFailure`. Con `delegatecall`, il codice dell'implementazione viene eseguito nel contesto di indirizzo, saldo e storage del chiamante, preservando `msg.sender` e `msg.value`.
6. Costruisci registri separati di autorità e valore, quindi simula. Registra destinatari, spender, operatori NFT, unità grezze dei token, decimali, scadenze, limiti di slippage e valore nativo. Simula con blocco, mittente e valore esatti, ma considera il risultato un'istantanea condizionale perché stato, prezzi, tempo, codice e ordinamento delle transazioni possono cambiare.
7. Conferma ogni campo rilevante prima di firmare. Dopo l'inclusione, controlla stato della ricevuta, log, trace disponibili e variazioni di saldi, allowance e stato degli operatori; distingui i fallimenti figli intercettati dal successo al primo livello; contabilizza il gas anche in caso di revert; attendi la finalità richiesta; e interrompi il processo invece di rifirmare alla cieca un errore inspiegato.
## Esempi svolti
- **Trasferimento ERC-20 statico.** `transfer(address,uint256)` usa comunemente il selettore `0xa9059cbb`. Un selettore più due parole ABI equivale a `4 + 2 * 32 = 68 bytes`. Un importo grezzo di `1,500,000` per un token verificato indipendentemente con `6 decimals` viene mostrato come `1.5 tokens`. I decimali sono metadati esterni del contratto, non codificati in tali argomenti, e il selettore da solo non identifica univocamente contratto o funzione.
- **Offset di byte dinamici.** Per `f(address,bytes)` con un payload di `3-byte`, la head di due parole occupa `64 bytes`. L'offset dinamico è `0x40`, misurato dall'inizio del blocco degli argomenti ed escludendo il selettore. La tail contiene una parola di lunghezza di `32-byte` e una parola dati con padding di `32-byte`, quindi la calldata totale è `4 + 64 + 32 + 32 = 132 bytes`. Trattare l'offset come assoluto dal byte zero porta quattro byte oltre il punto corretto.
- **Il valore di un batch dipende dall'implementazione.** Una chiamata esterna trasferisce `1.00 ETH`; tre chiamate figlie decodificate richiedono esplicitamente `0.20 ETH`, `0.30 ETH` e `0.10 ETH`, per un totale di `0.60 ETH`. I restanti `0.40 ETH` potrebbero essere rimborsati, trattenuti, inoltrati o causare un revert, secondo il codice del batch. Se la terza chiamata fallisce con `allowFailure=true`, le precedenti possono restare confermate; un'implementazione atomica può invece annullare tutto.
- **Un permit non è la calldata del relayer al momento della firma.** Un owner con `1,000 USDC` firma un permit ERC-2612 da `300 USDC` al nonce `41`. La firma da sola non modifica saldo né allowance. Dopo l'invio riuscito da parte di un relayer, il nonce diventa `42` e l'allowance `300`; dopo che lo spender utilizza `180`, il saldo è `820` e l'allowance residua `120`. Disconnettere il sito non revoca il permesso.
## Rischi
- Decodificare usando rete, fork, block tag o envelope di transazione sbagliati.
- Firmare per un dominio, indirizzo target o destinatario contraffatti.
- Considerare un selettore di `4-byte` univoco nonostante possibili collisioni.
- Usare un'ABI ipotizzata, obsoleta o verificata in modo scorretto.
- Fidarsi di un'etichetta di sorgente verificato senza confrontarla con il `codeHash` corrente.
- Non rilevare un upgrade di implementazione, beacon o amministratore tra revisione ed esecuzione.
- Ignorare una funzione proxy il cui selettore collide con quello dell'implementazione.
- Dimenticare che `delegatecall` scrive nel contesto di storage del chiamante.
- Accettare offset dinamici, lunghezze, padding o byte finali malformati.
- Non espandere un batch annidato che nasconde target, valori o permessi.
- Presumere atomicità quando l'implementazione intercetta o consente fallimenti figli.
- Ignorare il `value` nativo di primo livello perché gli argomenti dei token sembrano innocui.
- Applicare decimali errati o presumere che token fee-on-transfer e rebasing siano ERC-20 standard.
- Concedere allowance ERC-20 illimitata o gestire male la race condition di aggiornamento dell'allowance.
- Trascurare l'ambito esteso all'intera collezione di `setApprovalForAll` per NFT.
- Scambiare dati tipizzati EIP-712 o un permit ERC-2612 per calldata di transazione.
- Non rilevare nonce, scadenza, contratto di verifica, dominio della rete o limiti di replay.
- Considerare stabile una simulazione nonostante cambiamenti di oracolo, timestamp, pending state, MEV o codice.
- Considerare stato della ricevuta, log o trace del provider una prova completa dello stato economico.
- Rifirmare alla cieca tramite una UI compromessa o ignorare rischi di inclusione, reorg e finalità.
## Idee errate comuni
- Un selettore di funzione identifica univocamente ciò che il contratto eseguirà.
- Un riepilogo verificato del frontend è identico ai byte e all'implementazione corrente che si firmano.
- Una transazione con `value=0` non può spostare token, NFT o asset delegati.
- Una simulazione o una ricevuta riuscite dimostrano sicurezza e il risultato economico desiderato.
- Disconnettere una dapp revoca approvazioni, permit e permessi degli operatori NFT.
## Argomenti correlati
- [Simulazione delle transazioni](/it/crypto/transaction-simulation/)
- [Approvazione del wallet](/it/crypto/wallet-approval/)
- [Firma del wallet](/it/crypto/wallet-signature/)
## Fonti
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (consultato il: 2026-08-12)
- [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-and-libraries) - Solidity Documentation (consultato il: 2026-08-12)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consultato il: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato il: 2026-08-12)
Source: https://wiki.fcontext.com/it/crypto/calldata-decoding-wallet/index.mdx