Skip to content
Crypto Record

Crypto news across every chain

2026-10-17 03:28 UTC787344

Why a Calldata Change Can Break a Signed Swap

A swap signature covers specific transaction bytes or typed fields; changing calldata can break that authorization or change execution when the signed fields leave it open.

Crypto Record Editorial4 min read

Why a Calldata Change Can Break a Signed Swap

Changing calldata can invalidate a signed swap because the signature may cover the transaction data, or because the contract checks that data against signed terms. Calldata is the input sent to a contract: it names the function and carries its arguments, such as the token pair, amount, route and recipient. The wallet, signature verifier and swap contract each use it in a different way, so the effect depends on what was signed.

What does a swap signature cover?

A wallet’s transaction signature covers the transaction as a whole, including its calldata. The wallet encodes the transaction fields into a message and signs its hash. On Ethereum, those fields include the destination contract, value, nonce, chain ID and data. If calldata changes after signing, the hash changes too, so the original signature no longer authorizes that transaction. It is like signing a form that includes an attachment: replacing the attachment changes what was signed.

Calldata can also be part of an off-chain order or authorization signed with typed data. In that case, the signature covers the fields listed in the signed message, which may include a token, amount, recipient, expiry or route. Some protocols also bind a hash of the call data. Others leave some execution details to a router. The signature can remain valid if an unbound field changes, but the contract may still reject the call or execute different instructions.

A route can also cross a bridge, adding a separate set of instructions and costs; the manta bridge guide explains those mechanics in more detail. The same distinction applies: check which parts of a route the signature actually commits to.

Which calldata changes can cause a problem?

Changing any byte in a signed transaction’s data changes its signed hash. In a swap call, the data commonly contains a function selector followed by encoded arguments. Those arguments can direct the contract to trade a different token, use a different path, send output to another address or accept a lower minimum amount. A changed selector can call a different function altogether.

With an off-chain order, a change matters when it alters a signed field or a condition the verifier checks. For example, changing the amount may make the order hash fail verification. Changing a route may be allowed if the order signs only the input and minimum output, but only if the contract permits that route and the resulting trade meets the signed limits. A valid signature is not a general approval for every call made with it.

Smart accounts add another layer. They may sign a user operation whose call data specifies one or more contract calls. Their validation rules determine whether the signature covers the full call, a permitted target and function, or a narrower set of conditions. A relayer or bundler can package the operation, but it cannot safely change signed instructions unless the account’s rules allow that change.

How can you check whether a change is safe?

Compare the signed message with the call that will be submitted. For a wallet transaction, any edit to calldata means the transaction needs a new signature. For an off-chain order or smart account, inspect the signed fields and the contract’s validation rules; a signature that still verifies does not prove that every execution detail is unchanged.

  • Check the destination contract and function being called.
  • Compare token addresses, amounts, recipient, route and minimum output.
  • Check any expiry, nonce, chain ID and value constraints.
  • Confirm whether the signature binds the full calldata or only selected terms.

After signing, a wallet or service may rebuild a transaction to adjust fees or routing. Rebuilding can change calldata as well as fee fields, so do not assume the old signature still applies. Review the final call before signing again. The useful rule is simple: a transaction signature authorizes exact transaction data, while an order signature authorizes the fields its verifier checks. Knowing which one you have tells you what a calldata edit can change.