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

# 精度与舍入

> 价格与数量如何以整数表示，以及每个字段为什么按现在这个方向舍入。

结算路径上的每一个数都是整数。任何能影响余额的地方都没有浮点数——因为两台机器计算同一个浮点表达式，可能在最后一位上不一致，而在共识执行路径上，最后一位的不一致就是一次分叉。

所以价格和数量都按固定的整数单位保存；你输入的值和协议存下来的值之间，每一次转换都有规定好的舍入方向。

<h2 id="tick-size-and-lot-size">
  最小价格变动单位与最小数量单位
</h2>

| 约束                      | 作用对象 | 效果         |
| ----------------------- | ---- | ---------- |
| **最小价格变动单位（tick size）** | 价格   | 价格必须是它的整数倍 |
| **最小数量单位（lot size）**    | 数量   | 数量必须是它的整数倍 |

两者都按市场设定，公布在[合约规格](/zh/trading/markets)里。不符合的订单会被拒，不会被悄悄调整——一个偷偷替你把价格取整的场所，等于没打招呼就改了你的订单。

<h2 id="rounding-is-a-risk-decision">
  舍入是一个风险决策
</h2>

舍入方向不是排版偏好。**每一个舍入选择都把一小部分误差分配给了某个人**，而规则是一致的：误差会制造风险的地方，保守地舍入；误差会构成系统性转移的地方，公平地舍入。

<h3 id="rounded-conservatively-against-the-account">
  朝对账户不利的方向保守舍入
</h3>

| 字段        | 方向     | 原因             |
| --------- | ------ | -------------- |
| 起始保证金     | **向上** | 低估保证金就是低估风险    |
| 维持保证金     | **向上** | 它决定强平阈值        |
| 可用保证金资产   | **向下** | 防止开出略超出覆盖能力的仓位 |
| 可提现余额     | **向下** | 防止提走超出可用范围的部分  |
| 最大可买或可卖数量 | **向下** | 防止超出真实承载能力     |

规律是：凡是回答*这个账户还能承担多少*的量，都朝对账户不利的方向舍。保证金要求向下舍掉一个零头，在整个场所的每一个仓位上重复一遍，就成了对风险的系统性低估——单次很小，而且恰好是那种只在要紧关头才冒出来的误差。

<h3 id="rounded-fairly">
  公平地舍入
</h3>

| 字段      | 方向       | 原因          |
| ------- | -------- | ----------- |
| 手续费与资金费 | **四舍五入** | 系统性偏向平台站不住脚 |
| 返佣与奖励   | **四舍五入** | 同样的道理，方向相反  |
| 已实现盈亏   | **四舍五入** | 结算不该偏向任何一边  |
| 显示的盈亏   | **四舍五入** | 与结算保持一致     |

在这些字段上，固定一个方向就成了转移，而不是安全边际。总是向上舍的手续费是隐性加价，总是向下舍的手续费是补贴。四舍五入让哪一边都占不到系统性的便宜。

**有一个例外**：会舍成零的手续费改为**向上**舍。一笔一分手续费都不付的交易，比一笔付了最小可表示金额的交易更糟。

<Note>
  这就是为什么你看到的仓位价值、保证金占用和盈亏，可能和你自己算的差一个最小单位。这个差不是错——那是那个字段的舍入规则被有意执行的结果。
</Note>

<h2 id="what-this-means-in-practice">
  实践中意味着什么
</h2>

* **提交前先对齐 tick size 和 lot size**：价格不合最小变动单位，是最常见、也最容易避免的拒单原因。
* **别下满到最后一个单位**：可用保证金资产向下舍，保证金要求向上舍，所以一笔正好按可用余额算出来的订单可能被拒。留一点余量。
* **显示上有细微差异是正常的**：想精确复现一个数，就得拿同样的整数输入套同样的舍入规则，而不是用浮点重算一遍。
* **从整数重建**：程序化对账就在协议的单位下算。转成十进制类型再转回来，等于把整数本来要消除的那种歧义又请了回来。

<h2 id="where-to-go-next">
  后续阅读
</h2>

<CardGroup cols={2}>
  <Card title="市场" href="/zh/trading/markets">
    各市场的最小价格变动单位、最小数量单位与合约规格。
  </Card>

  <Card title="IntentionKernel" href="/zh/protocol/architecture/kernel">
    为什么定点算术是共识层面的硬性要求。
  </Card>

  <Card title="保证金模式" href="/zh/trading/margin-modes">
    保守舍入在你的可用余额上体现在哪里。
  </Card>

  <Card title="手续费" href="/zh/programs/fees">
    费用如何计算与舍入。
  </Card>
</CardGroup>