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

# Rounding & Precision

> Intention rounds risk-critical fields conservatively against the user and uses round-half-even for display and settlement, to fairly allocate precision error.

Rounding is not cosmetic. In a trading system, every intermediate value — margin, maintenance margin, available balance, fill quantities, fees — has a specific rounding direction, and picking the wrong direction quietly biases the system one way or the other. Intention's principle is simple: **error risk is allocated by rounding direction**. Fields where overestimation would endanger the system round conservatively against the user, and display or settlement fields round to nearest so neither side is systematically favored.

## The rule

> Safety-critical fields round **against the user**. Display and settlement fields round **to nearest**.

## The table

| Field                                       | Round direction | Why                                                                                                                |
| ------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------ |
| Initial margin                              | Up              | Under-estimating margin would widen systemic risk. Round up so the user always posts at least the required amount. |
| Maintenance margin                          | Up              | Tied to liquidation thresholds. Conservative rounding keeps the protocol safe.                                     |
| Available balance / free collateral         | Down            | Prevents a user from opening one extra tick of exposure that the system cannot support.                            |
| Withdrawable balance                        | Down            | Prevents a user from withdrawing one tick beyond what they actually own.                                           |
| Max buy quantity / conversion               | Down            | Caps the quantity so the user cannot exceed the true buyable amount.                                               |
| Max sell quantity / conversion              | Down            | Caps the quantity so the user cannot oversell their position.                                                      |
| Fee deductions (trading fees, funding fees) | Round-half-even | Neutral rounding; forced up only if the half-even result would be zero.                                            |
| Rebates and rewards to users                | Round-half-even | Neutral. A systematic bias toward the platform would be perceived as unfair.                                       |
| Displayed P\&L                              | Round-half-even | Display layer — readability and consistency trump infinitesimal accuracy.                                          |
| Settled P\&L                                | Round-half-even | Neutral allocation of error between the protocol and the user.                                                     |

## Why safety fields round against the user

Consider initial margin. If the true required margin is \$100.0005 and the system rounded down, the user would post slightly less than required. Multiplied across many positions, this creates measurable under-collateralization. Rounding up closes the gap. The user pays a vanishingly small extra cost in exchange for protocol-wide safety. The same logic applies to maintenance margin: liquidation decisions depend on the threshold being a lower bound on "you're safe".

Available balance rounds **down** for the opposite reason. If a user's true free balance is \$100.0005 and the system rounded up, they could open a position that eats into margin they do not really have.

## Why fees and settlements round to nearest

Fees and P\&L are bi-directional: a systematic bias either way would harm someone. Round-half-even (banker's rounding) ensures errors cancel out over time. The one carveout: if a fee would round down to zero — for instance, a tiny micro-fill — it rounds up to one lot instead, to prevent an exploitable "free" trade loophole.

## Order price and quantity

New orders have their price rounded to the contract's tick size and their quantity floored to the lot size. Opening orders round **against** the user (no accidental extra leverage); closing orders round **in favor** of the user so residual dust can always be cleared.

## Cascading operations

Multi-step operations (for example, [Scale orders](/trading/scale-orders) laying 20 limits across a range) round each level, then sum any remaining dust into a single order — typically the last level. This guarantees the sum of per-level sizes exactly equals the user's specified total, with the dust attached to a well-defined location rather than scattered across every level.

## Observability

Every significant rounding event is logged. Risk dashboards include rounding-adjustment totals so any systematic drift can be detected and corrected.

<Note>
  For most traders, precision rules are invisible — they matter at fractions of a basis point. The rules only become visible to users who are doing very large trades, automated strategies with tight budget accounting, or audit work that reconciles positions against the public chain state.
</Note>