WETH
ERC-20-compatible representation of ether used by smart contracts.
WETH stands for Wrapped Ether, an ERC-20-compatible token representation of native ETH. Users deposit ETH into a wrapping contract and receive the same quantity of WETH. They can later return WETH to the contract and receive ETH under its redemption rules, excluding network fees.
Wrapping exists because native ETH is part of Ethereum's protocol-level account system, while ERC-20 tokens follow a smart contract interface. Many decentralized exchanges and applications were designed to process ERC-20 assets consistently. WETH lets those contracts handle ether through functions such as transfer, balance checks, and token allowances.
For example, an exchange contract matching two ERC-20 tokens can use WETH on one side instead of implementing a separate path for native ETH. Wallets and interfaces may wrap or unwrap automatically during a trade. The user should still inspect the transaction because WETH approvals can grant another contract authority to move tokens later.
Canonical WETH is intended to maintain one-to-one redemption through ETH locked in its contract. This is different from a price-stabilization mechanism based on market incentives alone. However, “WETH” is a ticker rather than a globally unique identity. Other networks may issue bridged WETH or unrelated contracts that add bridge, custodian, administrator, and liquidity risk.
WETH and ETH usually trade close to parity when redemption is accessible, but their technical behavior differs. ETH pays Ethereum gas, while WETH is an ERC-20 token and cannot normally replace native ETH for transaction fees. Sending all ETH into WETH can leave a wallet unable to submit the unwrap transaction unless it receives more ETH for gas.
Accounting systems should record wrapping as a change in asset form rather than a market purchase when that matches the relevant treatment and facts. Applications need to avoid double counting ETH locked in the wrapper and WETH issued against it. Protocol integrations should handle failed native-value transfers and token approvals explicitly because ETH and WETH use different call paths despite targeting equal value.
Before wrapping, verify the network, canonical contract, amount, and interface. Keep fee currency and use limited approvals for applications. Developers should not identify WETH by symbol alone and must handle native value and token transfers separately. WETH improves contract interoperability, but its safety depends on using the intended contract and understanding whether the displayed asset is canonical, bridged, or merely using a familiar name.
Frequently asked questions
- Native ETH does not itself implement the ERC-20 contract interface expected by many token-based applications. Wrapping deposits ETH into a WETH contract and mints an equal amount of ERC-20 WETH, allowing exchanges and protocols to handle it through standard token functions. Users should wrap only when an application requires it because WETH also introduces approvals and contract interactions.
- Canonical WETH contracts are designed so one deposited ETH mints one WETH and one burned WETH releases one ETH, excluding transaction fees. The name WETH is not globally unique, however. Bridged or unrelated tokens on other chains can use the same symbol and depend on different backing. Verify network, contract address, code, reserves, and redemption route before relying on parity.
- Use a reputable wallet, established application, or the verified canonical contract for the correct network. Confirm the contract address through independent official sources and review the transaction before signing. Wrapping requires an ETH deposit, while unwrapping burns WETH. Keep enough native ETH for gas, and avoid search advertisements or unsolicited links offering special conversion rates or rewards.