Check a Token’s Contract Before Settlement

Before settling a trade, verify the token’s contract address on the intended chain and inspect how that contract handles transfers. A ticker and logo are labels, not identifiers; different contracts can use both. A quote shows what a route expects under current conditions, but it does not establish that the token will transfer normally or that its code cannot change.

Start with the address from the project’s own publication channels, then compare it with the address in the order or transaction. Check the chain ID as well: the same address format can appear on different networks, with unrelated contracts behind it. For a closer look at how an order reaches settlement, see cowswap. That flow explains the order mechanics; token-specific behavior still needs its own review.

How do I verify a token contract?

Verify the chain and full contract address first, then inspect the deployed code and its administrative controls. A token name, symbol and logo can be copied, while the address determines which contract receives the transaction.

Use a block explorer or other chain data source to inspect the address. A verified source listing lets you compare published source code with deployed bytecode, but verification alone is not an audit or a safety guarantee. Check whether the contract is a proxy. A proxy delegates calls to an implementation contract, which an administrator may be able to replace. If the implementation or its controlling role can change, the behavior you inspect today may not be the behavior at settlement.

Read the contract’s exposed functions and roles for controls that can affect transfers: pausing, blacklisting, allowlisting, fees, minting, or changing the implementation. The presence of a function is not automatically proof of abuse; its authority and conditions matter. Identify who can call it, whether that authority is shared or renounced, and whether the function can affect the trade’s sender, receiver or route. If those controls are not clear, treat the contract’s future behavior as unconfirmed.

What token behavior can make settlement fail?

Settlement can fail when a token’s transfer rules do not match the assumptions made by the route or settlement contract. ERC-20 defines common methods for transferring and approving tokens, but deployed contracts can add restrictions or unusual behavior.

A fee-on-transfer token deducts an amount during transfer. The recipient may receive less than the amount a route expects, causing a minimum-output check to fail or leaving the trade with a different effective price. A rebasing token can change balances through contract logic, so a quoted amount and a later balance change may not correspond to ordinary transfers. A token may also reject transfers for certain addresses, pause transfers, or return unexpected data from a call. These behaviors can make an otherwise valid transaction revert.

These details matter especially in settlement systems that execute signed orders through a settlement contract. The order can specify token amounts and constraints, while a solver constructs and submits the transaction that attempts to satisfy them. A quote or simulation tests a particular proposed execution against a particular state. It cannot guarantee that token rules, balances, liquidity or administrative settings will remain the same until the transaction is included.

What should I inspect in the order and approval?

Compare the signed order’s token addresses, amounts, receiver and expiry with the trade you intend to make. The token being sold, the token being bought and the settlement recipient should all be the expected addresses on the expected chain.

Then inspect the approval. An ERC-20 allowance lets a spender transfer tokens from your address up to the approved amount. Confirm that the spender is the contract required for the order, and check whether the allowance is limited to the amount needed or left open. An approval is a separate permission from the trade itself; approving a token does not prove that the eventual settlement will have the expected result.

• Match the chain ID and complete token address against a project source.
• Check decimals and raw token amounts; a displayed balance is scaled by the contract’s decimals value.
• Review proxy implementation, upgrade authority and transfer controls.
• Compare the order’s limits and allowance with the amount and recipient you intended.

Decimals are a frequent source of misreading. Interfaces usually render a raw integer balance using the token’s decimals value. If that value is unusual or inconsistent with the project’s documentation, check the raw amount and the interface’s conversion before signing. A familiar display does not confirm that the contract has familiar behavior.

What can a simulation confirm before settlement?

A simulation can show whether a proposed transaction succeeds against the state used for the simulation and what its calls return in that state. It is useful for catching reverts, incorrect addresses, insufficient balances, and some unexpected transfer effects.

It is a snapshot, not a guarantee. Between simulation and inclusion, balances, liquidity, token configuration or block state can change. A successful simulation also does not establish that a token’s administrator cannot alter its behavior later. Check the final transaction’s chain, destination, calldata and token amounts before signing, and compare the result against the order’s limits after settlement.

The practical rule is to identify the contract, not just the token label, and inspect the rules that govern its transfers and upgrades. If the address, authority or transfer behavior cannot be established, there is no reliable basis for assuming the settlement will behave like a standard token trade.