> ## Documentation Index
> Fetch the complete documentation index at: https://shield.fi/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Native token amounts

> How the current AMM uses base units and applies display decimals off chain.

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:

```text theme={"languages":{"custom":["/languages/leo.tmLanguage.json"]}}
human amount = base units / 10^decimals
base units = exact decimal input * 10^decimals
```

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`.