Check the destination and calldata before signing

Check the network, recipient and decoded action before signing a crypto transaction. The wallet signs a specific instruction, not the label or button shown by the site that requested it. On an EVM chain, a transaction typically identifies a sender, a recipient (`to`), a value, calldata and fee parameters; the signature authorizes that transaction for broadcast. A direct transfer and a contract call can have very different effects even when they appear in the same app.

For a swap, the visible route is only a summary of what the contracts will execute. The transaction may call a router or aggregator, with calldata encoding the function and its arguments. A fuller walkthrough of the wallet flow in thor swap can help put that interaction in context. The check that matters at signing time is whether the wallet’s decoded details match the action you intended, including the token and amount being spent and the minimum output accepted.

What does the destination address tell you?

The destination field tells you which account or contract receives the transaction call, but it does not by itself establish what the call will do. A normal transfer to an externally owned account can move the native asset by setting `to` to that address and `value` to an amount. A contract call sets `to` to a contract address; the EVM executes code there, and the meaning of the call depends on its calldata and the contract’s state.

For token transfers, the token contract is often the transaction recipient, while the token holder’s intended recipient is an address encoded inside calldata. A swap can likewise target a router contract even though the interface emphasizes the token pair or route. So comparing the visible recipient with a saved address is useful for a direct transfer, but insufficient for a contract interaction. You must also inspect the decoded function and its parameters.

Check the chain as well as the address. The same hexadecimal address can exist on multiple EVM networks, while the contracts deployed at that address may differ or may not exist on another network. A wallet’s network selector identifies where it will submit the transaction; the site’s branding does not. Confirm that the selected network is the one intended for the asset and contract interaction.

Which transaction details should you verify?

Verify the fields that determine the asset movement and contract behavior. Wallets differ in how much they decode, and a human-readable label is a convenience rather than proof that the underlying call is correct. For an EVM transaction, check:

• Network: Confirm the chain selected in the wallet matches the chain where the intended token and contract are deployed.
• Recipient: For a direct transfer, compare the full destination address with the independently obtained address. For a contract call, identify the called contract and the recipient encoded in the action.
• Action and parameters: Read the decoded function, token addresses, input amount, recipient, deadline or other limits if shown, and minimum output for a swap. These determine what the contract is being asked to do.
• Value and fees: Check the native asset value attached to the call and the estimated network fee. A contract call can carry native currency as well as calldata.

Token symbols and logos are not unique identifiers. Verify the token contract address when the wallet or interface exposes it, especially if similarly named assets appear. For amounts, check the units and decimal conversion shown in the signing view. An amount expressed in base units inside calldata may look unlike the rounded number in the interface, so rely on a decoded view only when it identifies the asset and the amount clearly.

What if the wallet cannot decode the request?

If the wallet presents opaque calldata or an unexplained signing request, you cannot reliably infer the contract action from the destination address alone. EVM calldata begins with a function selector followed by encoded arguments, and the same bytes only become meaningful when matched against the correct contract interface and code. A selector can suggest a function, but does not prove that the target contract implements the expected behavior.

Some wallet prompts request a message signature or typed-data signature rather than a transaction. These signatures may authorize later actions, such as a token allowance, without immediately submitting an onchain transaction. Inspect the domain, verifying contract, spender, token and amount in the typed data when those fields are available. “Sign” does not always mean “send a transaction,” but a signature can still grant authority that another party can use.

Simulation and clear-signing tools can improve the review by showing likely state changes or decoding calldata into named fields. They are aids, not guarantees: a simulation reflects a particular state and can miss changes before execution, while decoding depends on accurate contract metadata. If a prompt hides the recipient, the amount, the spender or the action, reject it and rebuild the request from the intended operation. The practical rule is simple: sign only when the wallet’s network and decoded effects agree with the transaction you meant to make.