Syncswap wraps native ETH at the vault boundary so its pools can account for ETH as an ERC-20-shaped asset while users keep an ETH entry and exit. For people routing swaps or minting liquidity positions routinely, that distinction explains both the transaction shape and the balance shown by the pool.

Syncswap is an automated market maker whose pools use a shared Vault for custody and internal accounting. Its sensible choice is to normalize ETH once, at the custody boundary, instead of forcing every pool to implement a separate native-asset path.

The wrapping happens before pool accounting

Native ETH is not an ERC-20 token. In the Solidity Programming Language, it arrives as transaction value through msg.value; it has no approve, transferFrom, or token-contract balance that a pool can query. WETH supplies those missing interfaces, but Syncswap’s Vault goes one step further: it accepts either representation and records them as the same underlying value.

When a user selects ETH, the router marks the asset with the zero address, Syncswap’s native-ETH sentinel. The router then forwards the specified amount as call value to the Vault. The Vault credits the destination account—normally the pool’s account—while holding the ETH itself. The pool does not need to receive a payable call or inspect the wallet’s native balance.

When the input is WETH, the visible path is different but the accounting result is the same. The router pulls WETH from the user after allowance, sends it to the Vault, and the Vault immediately unwraps it into native ETH. From that point onward, the Vault’s ETH balance and WETH balance represent one reserve. The wrapping is therefore an interface conversion, not a second economic asset entering the pool.

The protocol’s router and vault interfaces are available through Syncswap.

What moves in a one-ETH deposit

That last step matters because the Vault’s balance is not merely an accounting convenience. Its reserve records the total underlying amount, while each pool has an internal Vault account. Transfers between pools can update those internal balances without moving ETH through the network for every hop.

Why not let every pool handle native ETH?

A pool that supports native ETH directly must distinguish between an ERC-20 call and a payable call at every operation. Adding liquidity would need to reconcile msg.value with the requested amount. Swaps would need special handling for native outputs. Multi-hop routes would have to pass ETH between contracts that may expect transfer and transferFrom. Refunds, failed calls, and recipient contracts would add more branches to the settlement path.

Syncswap instead gives pools one normalized accounting surface. The pool receives token-like amounts from the Vault, calls the same reserve and balance machinery for an ETH pair as for another asset, and leaves native-asset handling to the router and Vault. Zero Knowledge Proofs can prove the resulting rollup state transition, but they do not change this distinction: ETH is still native at the account layer and token-like only after the protocol normalizes it.

The alternative is to make users wrap ETH before they interact. That works, but it moves the boundary into the wallet workflow. The user must call the WETH contract, pay for that transaction, approve the router, and later unwrap again if they want ETH. Syncswap’s native path keeps those operations inside the swap or liquidity transaction and preserves the user’s preferred withdrawal form.

Native ETH and WETH are different interfaces to one reserve

Choose native ETH when the funds begin in the wallet as ETH or when the final recipient needs ETH. The router uses call value, so no WETH allowance is required. Choose WETH when another contract already holds WETH, when an approval-based workflow is more convenient, or when the asset is being composed with other ERC-20 operations before entering Syncswap.

The important operational detail is that depositing WETH does not create a permanently separate WETH reserve inside the Vault. Syncswap’s documentation treats ETH and WETH as the same balance for reserve and account queries. A withdrawal request selects the presentation: the zero address returns native ETH, while the WETH address causes the Vault to wrap the amount before sending it out.