Wrapped SOL explained: wrap, sync and unwrap

Why a trading program uses a token form of SOL

SOL is Solana's native asset, recorded in lamports. Many markets use a common token-program interface for their input and output assets. A native-mint token account lets SOL participate through that interface.

Wrapped SOL, usually written wSOL or WSOL, is the representation associated with SOL held in that account. For the original Token Program, the native mint is So11111111111111111111111111111111111111112. Use the mint appropriate to the chosen token program; the Token Extension Program has its own documented native mint.

This mechanism does not require an issuer to hold unrelated reserves at a bank. The backing lamports are in the token account itself, and the token program defines how the account tracks them.

A wallet may hide wrapping inside a swap flow. You approve a request described as exchanging SOL, while its instructions create or use a wrapped-SOL account for the trading program. Understanding that account explains extra setup and cleanup in the transaction.

Read the account at two accounting levels

Every Solana account has a lamport balance. A native token account also has token-program data, including its tracked amount and a native reserve associated with its storage requirement.

Let R be the account's native reserve. If its lamport balance is R plus 1 SOL and the data is synchronised, the tracked wrapped amount is 1 SOL. The reserve and the usable wrapped amount perform different jobs.

Do not add the 1 SOL token amount to the same 1 SOL of backing lamports when calculating a portfolio. They describe the same economic funds through two views of one account. Counting both would inflate the holding.

Similarly, the mint address describes the native token identity. It is not a normal recipient address to which you send SOL to obtain a personal wSOL balance. The actual holding account and its authority matter.

SyncNative updates the tracked amount

Consider a teaching account already holding R plus 1 SOL, with a tracked amount of 1 wSOL. A System Program transfer sends another 0.5 SOL into that account. Its lamport balance now reflects R plus 1.5 SOL.

The token data can still report 1 wSOL until the token program's SyncNative instruction runs. SyncNative reads the native account's lamports and reserve and updates the tracked amount above that reserve. After synchronisation, the teaching account tracks 1.5 wSOL.

The instruction did not mint an additional external asset or create investment income. It brought the token-program view into line with the lamports already received. This distinction is essential when debugging a token balance that looks smaller than the account's native balance.

When constructing a wrapping flow, put the relevant funding transfer and synchronisation in the correct order. Then read back the account data to verify the intended usable amount.

A deposit and SyncNative update different fields

Follow a wrap-and-swap transaction

A supported application can combine setup, exchange and cleanup in one transaction. A common pattern is to create or locate the native token account, provide the SOL needed for the intended trade, synchronise it, call the trading program and close an eligible temporary account.

The complete request should explain every movement. Account creation requires storage funding. The transfer supplies the wrapped principal. The swap consumes input and credits its output. Cleanup returns any remaining lamports under the close instruction.

The account may be temporary or reused. A wallet's implementation and the route determine the exact construction. Inspect the actual instructions rather than assuming every SOL swap creates a new ATA or closes every wSOL account.

Transaction atomicity keeps the application changes together when an instruction fails, while the network fee can still be charged. A failed swap does not normally leave only a successful prefix of the same transaction's application changes.

Unwrapping releases lamports through eligible closure

For a native token account you are authorised to close, the close instruction transfers its lamports to the selected destination. This releases the wrapped principal and the account's remaining storage balance according to the token program.

Native account closure is a special case: it can unwrap while holding a nonzero native token amount. Do not generalise that behaviour to ordinary token accounts, whose closure conditions differ.

In the teaching R plus 1.5 SOL account, closing to your intended ordinary account moves the available lamports there. Network fees or other transaction actions still need their own accounting. The close destination is explicit; it is not necessarily the account that originally funded setup.

If a protocol controls the native account, you must use its supported withdrawal or exit action. Seeing a wSOL balance under a program's authority does not give your wallet permission to close that account directly.

Explain an unexpected balance before changing it

First identify the token program, native mint, account and authority. Read both lamports and token data. A difference can arise from the reserve or a transfer that has not yet been synchronised.

Next read the transaction's complete lifecycle. A temporary account can be created and closed within the same successful operation, so the current account lookup may find nothing even though the historical instructions explain the swap.

Finally reconcile native funds and output tokens without double counting backing. The explorer guide shows how setup and closure affect balance changes, while the fee guide separates processing costs from account funding.

Common questions