# SyncSwap: The Check That Proves a Swap Worked By [justlend](https://paragraph.com/@justlend), 2026-07-31 syncswap, crypto, web3 --- A SyncSwap swap actually worked when the zkSync Era transaction shows a successful swap execution and the wallet’s token balances, supported by transfer logs, show that the intended input left and the intended output arrived. A green wallet notice or completed approval does not establish that result. The official [SyncSwap](https://syncswap.app/) trading interface starts the trade; the chain record settles it. SyncSwap approval can succeed while the swap never happens ---------------------------------------------------------- The common false positive is an ERC-20 approval. Before a router can spend an ERC-20, the holder may need to grant an allowance: a permission that lets a specified spender move up to a stated amount. The ERC-20 standard defines `approve` as permission for a spender to withdraw tokens and `allowance` as the amount still available to that spender in the owner’s account. That is an authorization change, not an exchange of assets. [ERC-20](https://eips.ethereum.org/EIPS/eip-20) also requires a successful approval to emit an `Approval` event. So a wallet can report “confirmed,” charge gas, and show a transaction hash while the original token balance remains intact. In that case, the approval worked; the swap either was never submitted or needs its own signature. What decided it for me is this: if the transaction has no debit of the token being sold and no credit of the token being bought, it was not the swap that the trader intended to execute. A receipt status proves execution, not the trade the user meant to make ----------------------------------------------------------------------- Open the transaction hash in the zkSync Era explorer and start with its receipt status. Ethereum’s receipt convention uses `1` for a successful top-level call and `0` for a reverted one, as specified by [EIP-658](https://eips.ethereum.org/EIPS/eip-658). A failed transaction did not apply the proposed state change, even if it consumed gas. But status `1` is necessary evidence, not sufficient evidence. It says that this call did not revert. It does not tell the reader whether the call was an approval, a swap, a wrap, a liquidity action, or another successful contract interaction. The explorer must therefore be read as a receipt with effects, not as a binary verdict from the wallet UI. * The sender must be the connected wallet. * The transaction must be on zkSync Era, not another network with the same address. * The action must be the swap transaction, not an earlier approval. * The token movements must match the pair and amount selected before signing. Opposing Transfer logs are the evidence of the asset exchange ------------------------------------------------------------- The decisive evidence sits in the event logs and resulting balances. For an exact-input trade, find a transfer of the input token out of the wallet, then find a transfer of the output token into the wallet or its stated recipient. Intermediary transfers through the router and pools are normal; the relevant endpoints are the trader and the final recipient. This test follows how an automated market maker works. A DEX pool holds token balances and applies its pricing rule as tokens are deposited and withdrawn; it is not matching an order-book fill. [Uniswap’s protocol documentation](https://developers.uniswap.org/docs/protocols/v2/concepts/swapping) describes liquidity pools as smart contracts that hold two token balances and explains that a swap withdraws one asset while depositing the other. That mechanism makes paired movement, rather than an interface toast, the useful proof. Record What a completed swap should show What it does not prove alone Receipt status The submitted top-level call completed That it was a swap Input-token Transfer The sold asset left the wallet That the desired asset arrived Output-token Transfer The bought asset reached the recipient That the price matched the quote Post-transaction balances The net wallet result Every routing detail by itself Read token addresses, not symbols alone. A symbol can be reused by unrelated contracts. Also account for wrapped-native-asset paths: a route may contain WETH or another wrapped representation before the final native-asset step, so the final balance and logs together are more reliable than one display row. The amount received should be judged against the minimum, not the headline quote -------------------------------------------------------------------------------- A quote is calculated before the transaction executes. The execution constraint is slippage tolerance: the maximum decline from the quoted output that the trader accepts before the swap may execute. [Uniswap’s trading guide](https://developers.uniswap.org/docs/sdks/v3/guides/swapping/swapping) defines slippage in exactly that operational sense. If the output is at or above the transaction’s minimum-output constraint, a smaller amount than the screen quote can still be a correctly executed trade. Fees also belong in the explanation. SyncSwap documentation describes variable and directional fees, meaning a pool can use different fee tiers by direction rather than a universal fee assumption. Its documentation states that the maximum fee tier is 10%. > “The variable fees not only apply to trading fees but are also applicable to protocol fees.” — [SyncSwap’s Dynamic Fees documentation](https://docs.syncswap.xyz/syncswap/overview/dynamic-fees) Compare the received amount with the executed minimum output and route, then separate price impact, pool fees, and any native-token gas cost. A balance change that seems short of the headline quote is not evidence of failure until that comparison is made. zkSync inclusion resolves pending status without inventing a settlement threshold --------------------------------------------------------------------------------- Wait until the explorer shows the swap transaction as included rather than pending, then inspect the logs. ZKsync’s documentation says an L2 block is generated every second, while also distinguishing those L2 blocks from L1 batches that group consecutive L2 blocks. [ZKsync’s blocks-and-batches documentation](https://docs.zksync.io/zksync-protocol/era-vm/transactions/blocks) is useful here because it prevents a vague “wait longer” rule from replacing an observable check. For the question “did this swap execute?”, inclusion, successful status, matching transfer logs, and changed balances answer it. A separate operational policy may demand more confirmation before treating funds as final, but that is a different question. The check is complete only when the explorer and wallet describe the same trade ------------------------------------------------------------------------------- 1. Copy the hash of the signed swap transaction and confirm it has status `1` on zkSync Era. 2. Verify the sold token’s transfer leaves the connected wallet for the routed execution. 3. Verify the bought token’s transfer reaches the selected recipient, then compare its amount with the transaction’s minimum output. 4. Refresh the wallet and confirm the two balances changed in the same directions as the logs. Return to the [SyncSwap trading interface](https://syncswap.app/) only after the explorer has established that record. When all four checks agree, the swap worked; when any one is missing, the record identifies precisely whether the issue was approval, pending inclusion, reversion, routing, or the expected output. --- *Originally published on [justlend](https://paragraph.com/@justlend/syncswap-the-check-that-proves-a-swap-worked)*