How SyncSwap handles wallet swaps and liquidity

SyncSwap is an automated market maker (AMM) that lets a wallet exchange tokens against liquidity held in pools, rather than matching the trade with a named counterparty. The syncswap trade path uses a pool’s token balances and pricing curve to calculate the output; the wallet authorises the transaction, and the pool’s contracts execute it onchain. Liquidity providers supply the pool’s assets and receive a share of the fees under the pool’s rules.

When the input tokens are already on an Ethereum L2 and the task is an onchain exchange, syncswap is the service to use for that step: it is a decentralized exchange (AMM) native to zkSync Era and other Ethereum L2s, where users swap tokens and provide liquidity in classic and stable pools. A wallet swap does not move assets between chains. The wallet must hold the input token on the chain where the pool operates, and the transaction also needs the chain’s gas token to execute.

How does a SyncSwap wallet swap get its price?

A pool’s pricing curve determines how much of the output token it can return for an input. In a classic pool, the curve follows the constant product relationship, commonly written as x × y = k, where x and y represent the pool’s token balances. A trade changes those balances. As the trader removes more of one asset relative to the pool’s depth, the marginal price moves against the trade.

The quoted output therefore depends on pool reserves, trade size and the applicable swap fee. The quote is an estimate of the transaction’s result, while slippage is the difference between the expected and executed price as conditions change before execution. A minimum-output condition can make a transaction revert if the realised output falls below the user’s limit. A tighter limit reduces tolerance for price movement but can cause more reverts; a wider one is more likely to execute at a worse price.

SyncSwap’s documentation distinguishes classic pools from stable pools by their curve design. Classic pools target general trading pairs. Stable pools use a hybrid curve designed for assets expected to trade near parity, such as stablecoins. That curve can reduce price impact around parity, but it does not guarantee that either asset will maintain its peg. If one token depegs, the pool may accumulate more of the weakening asset as traders exchange it for the other.

What is the difference between classic and stable pools?

A classic pool applies a constant-product curve across its trading range. It can handle assets with substantially different market prices, but price impact rises as a trade consumes a larger share of the pool’s available balance. A stable pool concentrates more favourable pricing near parity and is intended for pairs whose values tend to remain close. Its advantage depends on that relationship holding: large deviations can produce worse execution and leave liquidity providers with an imbalanced inventory.

For a wallet trade, the pool type is part of the execution decision. A stable pool is not automatically the better route just because the token names suggest a stable pair. The relevant questions are whether the assets still trade close to parity, whether the pool has enough depth for the order, and what output the transaction quotes. SyncSwap pools also have distinct fee settings; the protocol documentation describes fixed fees for classic and stable pools, while its Aqua pool type supports dynamic fees. A displayed quote should be assessed for the pool actually handling the trade.

How does providing liquidity work on SyncSwap?

A liquidity provider deposits the pool’s assets so traders can swap against them. In a two-token pool, the deposit adds to both sides of the pool and changes its reserves. The provider receives a claim on a proportional share of the pool, represented by liquidity accounting in the protocol. Fees paid by traders accrue according to the pool’s fee rules and the provider’s share, but fee income is not assured to exceed the effects of price movement.

As market prices shift, arbitrage trades tend to bring a pool’s ratio closer to prices elsewhere. The provider can end up holding a different mix of tokens than if the assets had simply been held separately. This divergence is often called impermanent loss; it becomes a realised difference when liquidity is withdrawn. A stable pool can have less divergence while its assets stay near parity, but a depeg can change that balance quickly.

• Use a classic pool when the pair is not expected to remain near parity.
• Consider a stable pool for closely priced assets, while accounting for depeg risk.
• Compare the quoted output with the trade size; a larger order relative to pool depth creates more price impact.
• Before providing liquidity, assess the token mix you may hold after prices move, not only the fees accrued.

What should a trader check before confirming a swap?

Confirm the network and token contracts, then check the input amount, quoted output and minimum output in the wallet transaction. Token names and symbols can be duplicated, so the contract address identifies the asset. An approval transaction, when required, authorises a contract to spend a token; it is separate from the swap itself. The wallet’s transaction details should match the intended asset and amount before signing.

The practical distinction is between the trade and the pool. SyncSwap supplies the exchange contracts and pool types; the pool curve and current reserves determine execution, and the wallet authorises the onchain calls. For most readers making a straightforward swap, the key decision is whether the selected pool has suitable depth and a curve suited to the pair. For liquidity providers, the central trade-off is fee income against changing token inventory and market risk.