> For the complete documentation index, see [llms.txt](https://docs.crystal.exchange/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.crystal.exchange/information/known-limitations.md).

# Known Limitations

Below is a non-exhaustive list of the current limitations and design assumptions of the Crystal protocol.

1. Non-standard tokens are not supported. Crystal assumes tokens are standard ERC20s that revert on failure and transfer exactly the requested amount.
2. Quotes are estimates, not guarantees; getQuote, getAmountsOut, and getAmountsIn are computed by simulating against price levels rather than individual orders. In addition, orderbook and AMM state at call time may differ between quote and trade execution. As a result, actual fills may differ from displayed preview amounts. Always pair any trade with a well-placed slippage bound using either a specified worst price or minimum output.
3. Execution is gas-bounded, which caps order size. The entire order must execute within Monad's 30M per-transaction gas limit. Orders that would exceed this must be split across transactions or placed as market-to-limit orders so the remainder rests instead of reverting.
4. Gas-aware orders may be underfilled. Gas-aware partial order types stop filling once fewer than \~200,000 gas remain in the transaction, even when more liquidity is available at an acceptable price. This bounds worst-case gas but means such orders may fill less than a quote suggests, and the exact stopping point depends on the transaction's gas budget, which displayed quotes may not perfectly model.
5. All prices must be valid tick sizes below the market's maximum price; prices between ticks cannot be expressed, so conversions between base and quote round can leave small amounts of dust.
6. Some aggregate view functions cap their output; for example, getAllOrdersByCloid returns at most 1024 orders, so interfaces indexing large accounts must paginate calls. Upgradeability Crystal's contracts are immutable by design. As a result, upgrades are handled through new deployments and opt-in migration ("social migration"). Future features, optimizations, or disclosed vulnerabilities that require deployment will ship as a new set of contracts, while the existing deployment continues to operate unchanged. Since all state, such as resting limit orders and LP positions, exist in the current contracts, migration is voluntary. Users and market makers may withdraw or cancel orders on the old deployment and re-place orders or re-quote on the new deployment. Frontends and integrators may point their applications to the new deployment addresses, so end users are automatically routed to the latest version automatically. Assumptions Crystal's design assumes the following about the tokens it lists and the network it runs on. Listed tokens are assumed to be standard, well-behaved ERC20s that revert on failure and transfer exactly the requested amount. Tokens that deviate from these expectations are not supported. Crystal is tuned for Monad, which differs from standard EVM chains in ways that directly affect order execution: • The block gas limit is 200M gas, the per-transaction gas limit is 30M gas, and block time is \~400ms; since the entire orderbook is on-chain, these limits bound what a single transaction can do. • A market order's gas cost scales with the number of resting orders and price levels it crosses, measured at roughly 65,000 gas of fixed overhead plus \~14,500 gas per price level (tick) filled. The whole order must execute within the 30M per-transaction limit. For example, a market order crossing 100 ticks costs \~1.5M gas on Monad (about 0.76% of a 200M-gas block) and a single order can cross on the order of \~2,000 ticks before reaching the per-transaction limit. Orders that would sweep more than that must be split across transactions or placed as market-to-limit orders so the unfilled remainder rests instead of reverting. • Crystal assumes Monad's raised contract-size limit (128 KB), well above the standard 24 KB EIP-170 cap. The core contracts exceed 24 KB (the per-market contract alone is \~55 KB), and Crystal is split into a central exchange contract, per-market contracts, and libraries partly to stay within the limit. It will not deploy on EVM chains that enforce the 24 KB cap. These figures reflect Monad's current mainnet configuration and may change as the network adjusts its limits; order-sizing assumptions should be revisited if the per-transaction gas limit changes.