Skip to main content
The current AMM does not normalize token amounts to a shared decimal scale. It calculates swaps, liquidity, fees, protocol balances, and owed amounts in each token program’s native base units.

​
Contract behavior

  • PoolState has no scale0 or scale1.
  • The program has no token_decimals mapping or set_token_decimals function.
  • Desired amounts, minimums, swap amounts, refunds, owed balances, and protocol fees use native base units.
  • The contract does not require high-decimal token inputs to be divisible by an AMM scale.

​
Display conversion

The deployment registry and API token metadata hold display decimals. A client converts only at its display and input boundary:
Never use floating-point arithmetic to build a signed base-unit amount.

​
Price display

The on-chain square-root price represents a ratio of native base units. A human token1-per-token0 quote must account for canonical token order and the difference in display decimals. Keep these concepts separate:
  • Contract amount: exact native base units.
  • Contract price: Q128.128 square-root ratio of base units.
  • Display amount: decimal-formatted base units.
  • Display price: base-unit ratio adjusted for token decimals and display order.

​
Wrapped assets

The registry distinguishes the AMM token program from the underlying record program. ALEO uses wrapped credits. USAD and USDCx use ARC-22 wrappers. Router input record amounts can therefore use u64 or u128, while the core AMM amount fields remain u128.