Camelot swap lets you compare token quotes across different liquidity paths
Last updated ยทCamelot swap exchanges tokens through liquidity pools on Arbitrum One and supported Orbit chains, with AMM-specific and aggregator modes providing different ways to find an exchange quote. An automated market maker, or AMM, prices trades using tokens that liquidity providers deposit. The useful comparison holds the input amount constant and considers expected output, minimum received, price impact, and network costs before you authorize the exchange.
A mode name identifies how the application looks for liquidity. It doesn't establish which quote suits your trade. Pool design, token behavior, and the contracts that receive spending permission also affect that choice.
A usable quote starts with matching tokens and balances
The normal quote path begins with a selected mode, an input token and amount, and the token that you want to receive. When a balance unexpectedly appears empty, checking the connected account and network comes before changing the trade. Those checks don't move funds. A token balance on another network isn't available to the selected pool simply because its ticker matches.
Quote review also precedes wallet authorization. Camelot's swap flow includes application confirmation and wallet confirmation, with token approval where necessary. The quoted output describes the proposed exchange; approval grants spending permission. Neither an approval confirmation nor a displayed quote establishes that the output token has arrived.
AMM modes narrow the pool choice; aggregation broadens it
Camelot's V2 and V3 modes restrict swaps to their respective AMMs, while its aggregation options consider a broader liquidity selection. Compare available modes with unchanged tokens, amounts, and output tolerances. Otherwise, differences in the request can masquerade as better routing.
V2 and V3 selection
V2-only and V3-only modes help isolate the liquidity that each AMM supplies. V2 supports separate pricing curves for volatile and correlated assets. V3 uses concentrated liquidity, where providers allocate funds within price ranges. These designs affect available depth at the trade's execution price; a version number alone doesn't establish a better quote.
Native and aggregator routing
The documented Native mode combines Camelot V2 and V3 liquidity. Aggregator mode also uses external routing APIs. Broader routing provides another quote to compare, rather than a promise that every trade will receive more tokens. Token compatibility can make the narrower AMM choice preferable.
V4 pool configuration
Camelot's V4 documentation describes pools using Algebra Integral's modular architecture and identifies a beta stage for testing plugin configurations. Pools can have distinct plugins and fee structures, including custom configurations. Treat the pool version and the application's swap-mode label as separate information: V4's existence doesn't establish that every mode includes every V4 pool. Compare the route that the actual quote identifies.
What changes the amount that a swap delivers?
Pool fees, liquidity depth, and price movement affect the exchange output, while network fees add a separate transaction cost. Compare fresh quotes because conditions can change between requests.
Trading fees and price impact
Camelot V2 pools can charge different swap fees for opposite trading directions. V3 also supports volatility-sensitive fees. Reversing a pair therefore needn't produce a symmetric cost. Price impact describes the effect of the trade itself on pool pricing, which grows or shrinks with the amount and available liquidity. A low displayed fee can't compensate automatically for shallow liquidity.
Minimum received and network costs
Slippage tolerance allows a bounded difference between the quote and execution. Minimum received expresses the output floor that the transaction is intended to enforce. Increasing tolerance permits a worse exchange outcome; it doesn't improve pool depth. Read that floor before signing, alongside the expected output.
Network costs remain separate from the pool's exchange economics. An approval transaction can add another charge, and an executed transaction that reverts can still consume gas. Comparing outputs without accounting for those costs can favor a route that leaves less value after execution.
Permission and settlement answer different questions
Token permission answers whether a contract may spend an asset; settlement answers whether the exchange actually changed the intended balances. ERC-20 allowances specify a spender and an authorized amount. Review both, especially when switching routing options changes the contract requesting permission. Limiting permission to the intended amount reduces how much that spender can transfer under the allowance.
A transaction hash identifies a submission. Its receipt supplies execution status and logs. For output reconciliation, the relevant details include the token contract, recipient, and credited amount. A successful receipt deserves inspection because it might belong to an approval rather than the swap itself. The wallet's estimated fiat value is different from the number of tokens credited.
A confirmed approval with no output tokens
In this hypothetical example, a wallet shows a confirmed approval, the input tokens remain, and the output balance hasn't changed. The selected tokens, balances, quote, and transaction states are hypothetical. Before submitting the swap, you need a funded account on the selected network, enough funds for gas, and a minimum output you're willing to accept. The swap should credit the intended output token to that account.
First, open the existing transaction details without submitting anything. They show an approval for the intended spender, which explains the unchanged token balances. Refresh the Camelot quote and review its output floor and costs. Only authorize the swap if you accept the refreshed quote and its spender has sufficient allowance for the input amount.
Assume the resulting receipt shows a successful swap and the intended output credit satisfies the reviewed minimum. That establishes completion independently of the earlier confirmation banner. If the initial transaction details instead show a pending swap, the next action is to inspect that submission's status, not authorize another exchange.
Transfer taxes need a different routing decision
For tokens that charge a transfer tax, Camelot advises avoiding aggregator mode because intermediate transfers may trigger multiple tax charges. Camelot's tax-token guidance directs users toward the AMM that holds the relevant liquidity, commonly V2 and sometimes V3. This isn't a blanket compatibility promise for every taxed token.
An invalid estimated amount or slippage error doesn't prove that a transfer tax exists. Volatility can produce similar symptoms. Establishing the token's transfer behavior and locating its liquidity should precede any tolerance adjustment. Widening tolerance without understanding the cause authorizes a poorer outcome while leaving the original problem unresolved.
The better alternative depends on usable output and access
A direct AMM quote is useful when the relevant pool has adequate liquidity and compatible token behavior. Aggregation provides another comparison when broader routing produces acceptable output after costs. Neither mode has a permanent advantage across amounts and market conditions.
Moving assets to another network introduces a separate bridge operation before a swap can use that network's liquidity. That adds requirements beyond quote comparison. A centralized exchange introduces custody and deposit or withdrawal requirements instead. When funds already sit on the network that holds suitable Camelot liquidity, compare available swap routes first; an alternative venue must justify the additional transfer and access requirements.
What to know about Camelot swap
-
Can I swap tokens without becoming a liquidity provider?
- Yes, swapping uses liquidity that providers have already deposited, so you don't need to create a liquidity position. Your transaction exchanges the selected input asset for an output asset through an available route. Providing liquidity is a separate activity with different exposure to pool balances and price changes. A swap doesn't automatically enroll you in farming or give you a share of future pool fees.
-
Why can two tokens have the same symbol in a wallet?
- A token symbol isn't a unique contract identifier. ERC-20 defines a symbol as optional display information, while balances belong to a particular token contract. Match the intended contract and network when selecting an asset, particularly after importing a token. Matching names or symbols alone don't establish that two entries represent interchangeable balances.
-
Does a stable pool guarantee an unchanged exchange ratio?
- A stable pool's pricing curve doesn't guarantee that its assets retain an unchanged market relationship. Camelot V2 stable pools target correlated assets and use a different curve from volatile pools. The actual quote still reflects pool balances, trading fees, and the requested amount. A stable-pool classification doesn't remove exposure to a change in either underlying asset's value.
-
Will a V4 security plugin recover funds after an exploit?
- A pool-halting capability doesn't establish a fund-recovery mechanism. Camelot's V4 security plugin provides an option to halt a specific pool or all pools during emergencies. That control concerns stopping pool activity. It doesn't by itself promise reimbursement, reverse completed transactions, or establish identical protections for custom pools with different configurations.
-
When does a reverted swap cost gas?
- A swap that executes on the network and reverts can still incur gas charges for the work performed. A rejected wallet prompt is different because it doesn't submit that transaction. An application error before submission also differs from an on-chain failure. The transaction record establishes whether execution occurred, so the error message alone doesn't determine the charge.
-
Are swap transactions private after wallet disconnection?
- Disconnecting a wallet doesn't erase transactions that the blockchain has recorded. Transaction records can expose participating addresses, contract interactions, and token transfers. Disconnection also doesn't revoke an existing token allowance, which remains part of the token contract's state until it changes. Connection settings, transaction history, and spending permissions each control different things.