Why routes use a wrapped native token

A wrapped native token represents a blockchain's native asset through a token contract interface. This lets contracts handle it using token-transfer conventions alongside other assets. A route may therefore show a wrapped version even when the user starts or ends with native currency.

Why the interface difference matters

Native currency and ERC-20 tokens do not use identical transfer mechanisms. The ERC-20 standard defines methods such as token transfers and allowances. Native value instead appears as part of a transaction or contract call, as described in Ethereum's transaction guide.

A wrapper provides a bridge between those interface conventions within the same chain. This is different from bridging an asset to another network. It is also different from asking a pool to discover an exchange rate between two independently priced assets.

Read a hypothetical route

A user requests native coin to Token B. The execution plan may wrap the native input, exchange the wrapped token through a pool, and deliver B. In the reverse direction, a route can obtain the wrapped token and unwrap it before delivering native currency.

Uniswap's multi-hop documentation uses WETH as a token in its example paths. The pool-facing asset and the user-facing receipt do not always need the same representation.

Do not infer final delivery from an intermediate label

If the route lists a wrapped token, check whether the final action includes unwrapping. A quote that ends in the wrapped asset is not identical to one that delivers native currency. The distinction can matter when the recipient needs the native asset for another operation.

Also verify the actual wrapper contract rather than trusting a familiar ticker. The explanation here concerns the role of a native-asset wrapper; it does not establish that any token using a wrapped-asset name has the expected backing or redemption behavior. For a concrete trade, the exact contract and supported delivery flow define what is received.