Curveswap exchanges tokens through Curve liquidity pools

Direct pool swaps and routed swaps

When a pool contains both assets, a direct swap can exchange them within that pool; a router can connect supported pools when an intermediate asset provides another path. These options differ in the contracts involved and the output available for a particular input amount. A routed trade may obtain a better quote, although additional operations can increase transaction costs. Neither route length nor the presence of a familiar token establishes which option leaves the recipient with the better outcome.

Compare quotes for the same input asset and amount, output asset, and network, checking token contract addresses where applicable. A quote for another token representation is a different trade, even when its symbol looks familiar. Pool liquidity matters because the amount available along the route affects its price impact. A route that exists for a small input may become unattractive for a larger one.

StableSwap and CryptoSwap price different asset relationships

The relationship between the pool assets determines its pricing design: StableSwap targets assets with closely related values, while CryptoSwap accommodates assets with independently moving prices.

StableSwap pools

StableSwap concentrates liquidity around an expected price relationship. This can reduce price impact near that relationship, depending on pool balances and trade size. The design does not make the underlying assets interchangeable or guarantee their value. A stablecoin losing its peg changes the economic meaning of the quote. Receiving more units of that token can reflect its lower market value rather than a favorable exchange.

View image file

CryptoSwap pools

CryptoSwap uses an internal price scale and adjustment rules to accommodate changing relative prices. Its liquidity concentration can move as the pool meets its adjustment conditions. That mechanism broadens the assets that Curve pools can trade. It also means a trader should evaluate the actual quoted output rather than expect an equal number of input and output units.

Token identity and network compatibility come first

A usable swap requires the input balance, output token, wallet connection, and pool deployment to belong to the same supported network. A token symbol does not establish that compatibility. Different contracts can share a name, and representations on separate networks have separate balances. Switching the network displayed in a wallet changes the chain being viewed; it does not move funds between chains.

Record the input and output assets, their token contract addresses where applicable, the input amount, and the receiving address before authorizing the trade. The wallet also needs the native asset required for network fees. If the desired token is unavailable through a compatible route, a broader slippage allowance will not create support. The available choices are to use another supported route, arrange a separate transfer where appropriate, or leave the assets unchanged.

Approval and swap authorization have different effects

For an ERC-20 input, an approval must establish permission when the selected spender lacks sufficient allowance to draw the swap amount. Existing permission can remove that prerequisite.

The permission attached to the input token

An ERC-20 allowance authorizes a specified spender to transfer tokens up to the permitted amount. That permission belongs to a particular token, owner, and spender. An allowance for one pool does not automatically authorize another router. Approval changes permission; the exchange transaction performs the trade.

Allowance amount

A limited allowance restricts the amount that the spender can draw. A larger allowance may remain usable after this trade.

Spender identity

The spender should match the contract required by the selected route. The contract that receives an approval transaction is the token contract, while the approval names a separate spender. Those addresses serve different purposes. Reviewing only the transaction destination can therefore miss the permission being granted. If the quote changes to a route with another spender, the earlier approval may no longer satisfy the swap requirements.

Quoted output and minimum received set different expectations

The quoted output estimates what the selected input would receive under the quoted pool conditions; the minimum received sets the lowest acceptable output for execution. Price impact describes how the trade itself affects its execution price. Slippage tolerance allows a bounded deterioration between quoting and execution. Increasing that tolerance accepts a worse possible result; it does not improve the underlying price or repair incompatible token selection.

Curve quotes incorporate trading fees, while network gas remains a separate cost. An approval can require another gas-paying transaction. Pool settings and route selection affect the trade, so a single permanent fee percentage would misdescribe the available choices. Compare the output after trading fees and the separate network estimate. Refreshing a quote can change the proposed terms, making the minimum received worth reviewing again before authorization.

Confirmed execution and received tokens establish completion

A successful swap receipt establishes execution, and the recorded output transfer establishes which token reached which address. A transaction hash alone identifies a submitted transaction without proving success. The receipt must also belong to the swap rather than an earlier approval. For ERC-20 outputs, transfer records help reconcile the recipient and amount with the intended trade. Wallet displays can update later than the underlying chain state.

If the transaction reverted, its swap-related state changes do not persist, although consumed gas still costs money. A separately confirmed approval can remain in place. A pending transaction needs a status check before another submission, because a second independently authorized trade could also execute. Confirmation and finality have network-specific meanings; no single waiting period applies to every Curve deployment.

Liquidity deposits create a different kind of holding

Providing liquidity commits assets to a pool position, whereas swapping exchanges an input asset for an output asset. Depositing into a Curve liquidity pool returns LP tokens representing a share of that pool. The share exposes its holder to the pool's changing asset composition. Trading fees can contribute to its value, while price movements, depegs, and contract failures can cause losses.

Staking eligible LP tokens in a reward gauge is another action, with rewards depending on the pool and incentive availability. A combined deposit-and-stake operation can leave the position recorded in the gauge rather than as freely held LP tokens. Withdrawal consequently depends on where the position is held and which withdrawal method the pool supports. A quoted yield does not describe the outcome of an ordinary token swap.

Closing the trade record and choosing the next action

After receipt, retain the network, transaction hash, input and output asset identities, token contracts where applicable, actual input and output amounts, and network cost. These details distinguish the completed swap from later transfers or another trade involving the same symbols. Disconnecting the wallet does not revoke an existing allowance. Any remaining permission is a separate decision from holding or moving the received asset.

The next destination must accept the exact output token on its network. A successful swap establishes receipt, not compatibility with every later deposit.