> For the complete documentation index, see [llms.txt](https://fraxswap-page.gitbook.io/fraxswap-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fraxswap-page.gitbook.io/fraxswap-docs/fraxswap-use-twamm-for-size-standard-swaps-for-speed.md).
# FraxSwap: Use TWAMM for Size, Standard Swaps for Speed
FraxSwap is not a magic escape from thin liquidity: it makes a direct swap immediately, or spreads a large order across time with TWAMM. The trade-off is speed versus execution control. The [FraxSwap](https://fraxswap.app/) interface is useful when the trader chooses the mode that fits the order, then treats failed quotes, gas, approvals, and token risk as separate problems.
### One problem disappears when FraxSwap adds a time cost
The central choice is simple. A direct swap gives the asset now, but a large order can move the pool against the trader. A TWAMM order reduces the shock by splitting execution over time, but the trader gives up immediate settlement and accepts exposure to market movement while the order runs.
Fraxswap is an automated market maker, or AMM: a smart-contract market that prices trades from token reserves instead of matching two buyers and sellers directly. The protocol documentation describes its core AMM as a full-range Uniswap V2-style constant-product market using the `x*y=k` design. Its [protocol overview](https://docs.frax.com/protocol/subprotocols/fraxswap/overview) also identifies the embedded TWAMM as the feature built for large, sustained orders.
**Price impact** is the movement caused by the trader’s own order. It grows when the order is large compared with the pool’s available liquidity; this is the distinction explained in Uniswap Labs’ [price-impact definition](https://support.uniswap.org/hc/en-us/articles/8671539602317-What-is-price-impact). **Slippage** is different: it is the gap between the expected output and the amount actually received after the market moves. A trader can have low price impact but still fail because the slippage limit is too tight.
| Execution mode | What it fixes | What it costs |
| -------------- | ------------------------------------ | -------------------------------------------------------------- |
| Direct swap | Waiting and execution uncertainty | Immediate price impact, gas, and slippage exposure |
| TWAMM order | Single-block impact on a large trade | Time, changing market conditions, and a publicly visible order |
That is the real FraxSwap decision. TWAMM is not a better version of a normal swap. It is an execution schedule for a different problem.
### Urgent trades fit direct swaps; FraxSwap suits patient size
#### Direct swaps are for certainty about timing
Use a standard swap when the amount is small relative to the displayed pool, the asset is needed immediately, or the market is moving too quickly for a multi-block order to make sense. The trader sees a quote, checks the minimum received, confirms the wallet transaction, and receives the result in one on-chain execution.
The downside is mathematical, not mysterious. In a constant-product pool, removing one asset and adding the other changes the reserve ratio. The larger the order, the further the final price moves from the starting price. Splitting the trade into several direct transactions can reduce the impact of each transaction, but it adds extra approvals, gas costs, and execution decisions.
#### TWAMM orders are for size without urgency
TWAMM suits a treasury rebalance, a planned accumulation, or a large trade where the trader can wait. The current [technical documentation](https://docs.frax.com/protocol/subprotocols/fraxswap/technical) describes long-term orders as virtual sub-orders executed across blocks, with the embedded AMM updated when the system interacts with it.
The underlying TWAMM design was created to split long-term orders into tiny pieces and execute them smoothly against a constant-product AMM. The [TWAMM paper](https://www.paradigm.xyz/writing/twamm) explains why this can reduce the impact of one large transaction and amortize execution costs. It also states the trade-off plainly: the order is visible, and other traders can react to it.
Before signing, the trader can compare the direct quote with the long-term order in the [FraxSwap swap interface](https://fraxswap.app/). That comparison should answer one question: is saving immediate execution worth waiting through changing prices?
### Most FraxSwap failures have a mechanical fix
1. **The quote changes or the swap reverts.** The slippage limit is probably below the movement between quoting and execution, or the pool is too shallow for the order. Re-quote, reduce the size, split the trade, or choose TWAMM if the order is genuinely non-urgent. Do not solve every failure by setting an enormous slippage limit. A [slippage guide](https://support.uniswap.org/hc/en-us/articles/8643879653261-How-to-change-slippage-on-the-Uniswap-Web-app) notes that a limit set too low can revert the transaction, while one set too high can allow a materially worse output.
2. **The wallet asks for approval first.** ERC-20 tokens normally require an allowance before a router can spend them. Approve only the token and contract you intended, wait for that transaction to confirm, then submit the swap. If approval remains pending, check the wallet’s transaction history before signing another approval.
3. **The token appears, but no sensible route exists.** A symbol is not an identity. Verify the token contract address and selected network. A bridged or impersonator token can share the same ticker while having different liquidity, different code, or no usable pool. If the route is thin or the output looks abnormal, stop and verify the asset rather than forcing the transaction.
4. **The transaction stays pending.** Check the transaction hash on the relevant block explorer. If it has not been mined, do not submit a second swap from the same wallet and nonce. The practical fixes are waiting, replacing the transaction with an appropriate network fee where the wallet supports it, or cancelling according to the wallet’s own controls.
5. **A TWAMM order does not fill immediately.** That is not necessarily an error. A long-term order is designed to execute over time. If the timing no longer works, cancel it if the interface and contract expose cancellation, then reassess the market before placing another order.
### Three conditions rule an option out before signing
* **Immediate delivery rules out TWAMM.** If the asset must arrive in the next transaction, use a direct swap or do not trade.
* **Extreme price impact rules out blindly increasing slippage.** A wider limit protects execution, not value. Reduce the order or wait for deeper liquidity.
* **An unknown token rules out both modes.** TWAMM cannot repair a malicious contract, a transfer fee, a broken approval function, or an asset with no credible liquidity.
### Thirty seconds is enough to choose the route
1. Check the token contract, network, pool depth, minimum received, and gas balance.
2. Ask whether the order is urgent. If yes, use the direct route and accept only a slippage limit you understand.
3. If the order is large and patient, compare TWAMM’s expected schedule with the cost of several smaller direct swaps.
4. If neither route looks acceptable, do nothing. A bad quote is information, not an invitation to increase risk.
### Three FraxSwap questions still deserve short answers
#### Is TWAMM the same as a limit order?
No. TWAMM schedules execution over time; it does not promise a fixed exchange rate.
#### Does TWAMM remove smart-contract risk?
No. It changes execution mechanics but does not remove contract, token, liquidity, or network risk.
#### Can a reverted swap still cost money?
Yes. A reverted transaction normally does not complete the trade, but the network can still charge gas for processing it.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://fraxswap-page.gitbook.io/fraxswap-docs/fraxswap-use-twamm-for-size-standard-swaps-for-speed.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.