Ethereum Blog

To set slippage on a Syncswap swap, choose the smallest tolerance that leaves room for the quoted price to move before your transaction executes. Syncswap is a decentralized exchange and liquidity hub on zkSync Era, where a Smart Router can move a trade through one or more pools. The setting matters because the price shown when you prepare a swap is not necessarily the price used when the transaction is confirmed. The main trade-off is straightforward: a tight limit protects your price but increases the chance that the transaction reverts; a wide limit makes execution more likely but gives the market more room to deliver less than expected. Choose between protection and execution A low tolerance suits a liquid pair, a normal market, and a trade that is not urgent. If the quote is for 1.0000 units of the output token and the tolerance is 0.10%, the transaction should require at least 0.9990 units. A move beyond that threshold causes the swap to fail instead of accepting the worse price...

Atomic swaps exchange assets directly by locking each side of a trade to the same cryptographic secret and releasing both sides only when the redemption condition is met. The working model is 2 ledgers, 2 contracts, 1 secret, 1 hash, and 2 refund deadlines . That small set of parts explains both the appeal and the limits: neither asset needs to leave its native network, but both networks must support compatible settlement rules. How the swap settles In the classic design, the two parties use hash time-locked contracts, or HTLCs. One contract says, “Release the asset to whoever can present the secret whose hash equals this value before the deadline.” The time lock adds a second condition: if nobody presents the secret in time, the original owner can reclaim the funds. Alice generates a random secret and publishes only its hash. Alice locks bitcoin on Bitcoin using that hash and a later refund deadline. Bob sees the hash and locks litecoin on Litecoin with the same redemption condition ...

Token burns reduce supply only when the burned balance is actually removed from the token’s accounting; in a bridge, a burn may simply retire one representation before an equivalent amount is minted elsewhere. This is the point that causes confusion on a first cross-chain transfer. The source transaction succeeds, an explorer shows a Burn event, and tokens appear in the destination wallet. It looks as though supply fell. Sometimes it did. Often, the protocol merely moved the unit of account from one chain to another. Start with the ledger, not the event name A genuine protocol burn decreases the token contract’s totalSupply by destroying existing units. Ethereum’s EIP-1559 burn is a clear example: the base fee paid in ETH is destroyed, while validator rewards and priority fees are separate supply flows. ETH supply therefore depends on the balance between issuance and burned base fees. A transfer to an inaccessible “dead” address is different. It may remove tokens from practical circu...