"100.00", never a float and never an integer of smaller units. The SDK
and the drop-in components format amounts to two decimal places. There is no
published minimum transfer amount today, so don’t assume one in your integration.
Representation
Amounts appear as decimal strings wherever money is exchanged: the crypto figure to send is the order’squote.asset_amount, and the display figures returned by a
rate preview (youSend, youReceive) follow the same convention.
Precision
Two decimal places, applied by the SDK and components. Operational detail — the current formatting behaviour and the fact that no minimum is enforced — lives in Rate limits & operations; treat that page as the source of truth rather than hardcoding precision or bounds.amount_status — judging the deposit
A collection order’s amount_status moves pending → exact | underpaid | overpaid. The engine sets it by comparing the received on-chain amount to the
quoted asset_amount. The exact tolerance band is engine-owned and not a
published constant — don’t hardcode a threshold. Underpaid and overpaid deposits
emit collection.amount.underpaid / collection.amount.overpaid webhooks
carrying { expected, received, asset, network, tx_hash }.
When a deposit differs from the quote
A deposit doesn’t have to match the quoted amount exactly. How under- and overpayment resolve is owned by Order lifecycle.Where to go next
- Rates and quotes — how the price is locked, and why there are no separate fees
- Order lifecycle — the states an order moves through
- Rate limits & operations — precision, retries, and change policy