Why wrapped tokens exist
Why they exist
Bitcoin has no smart contracts worth speaking of, so Bitcoin cannot participate in applications built on Ethereum. Wrapping solves that: lock the Bitcoin, issue WBTC, use WBTC where Bitcoin cannot go.
The same logic explains a stranger case. WETH is wrapped ETH, on Ethereum, where ETH already lives. The reason is technical: ETH is the native coin and predates the ERC-20 token standard, so it does not behave like a token. Applications expecting a token cannot handle it, and WETH is ETH made to behave like an ordinary token. Nothing crosses chains at all.
Who backs them
This is the question that decides whether a wrapped token is worth holding.
Custodial wrapping
A company holds the original and issues the wrapped version. WBTC works this way, with reserves published for verification. You are trusting the custodian, exactly as with a custodial wallet.
Contract wrapping
A smart contract holds the original and issues automatically. WETH works this way, and the trust moves from a company to the code.
Bridge wrapping
A bridge locks the asset on one chain and issues on another. This is where most of the risk in the category sits, for the reasons the bridge entry describes.
Wrapped against native
Wrapped is not the same as native
The distinction gets blurred constantly and matters for anyone accepting payments.
USDT on TRON is native. Tether deployed a contract there and issues directly against its reserves. USDT on Ethereum is also native, from a separate contract. Neither wraps the other, and no bridge sits between them.
Bridged USDT exists too, on smaller chains where Tether has not issued directly. It looks the same in a wallet, carries the same name, and depends on a bridge in addition to the issuer. Two layers of risk instead of one.
The way to tell them apart is the contract address, visible in any block explorer and published by the issuer.
What a merchant should do about it
One rule: accept native, avoid wrapped where a native version exists.
A payment gateway supporting multiple networks handles native issuance on each, so this rarely comes up in practice. Where it does come up is a customer offering to pay in a wrapped asset on an unusual chain, and the sensible answer is to ask for the native version on a supported network instead. The setup guide covers which networks to enable.
The reasoning is simple. Accepting native USDT means trusting Tether. Accepting bridged USDT means trusting Tether and a bridge, for no additional benefit.