三件不一样的事
区块内部，延迟不决定结果。 同一价格档位上的优先级是价格优先，然后是在已提交区块序列中的位置——而不是你的数据包何时到达某个节点。同一区块内的两笔订单，其先后由每个验证者以完全相同的方式算出。区块与区块之间，到达时间仍然重要；但在一个区块之内，主机托管买不到任何东西。 同一区块内，你的撤单先于主动吃单。 撤单执行的阶段，比“能吃掉流动性的订单”更早。价格一动，你撤走已经过时的报价，和撤单同时到达的订单打不掉它。在大多数场所，这是一场靠基础设施赢下的竞赛；在这里，它是协议层面的保证。 只挂单先入簿，之后才轮到别的订单来跟它成交。 它们在非撮合阶段处理，排在所有主动流之前，因为按定义它们不可能吃掉流动性。 三者合起来意味着：在延迟上重金投入的通常理由——保卫报价不被同区块的逆向选择打掉——在这里不成立。参见交易排序。报价
用只挂单。 它保证挂单方身份：会立即成交的订单直接拒掉，不会以吃单方身份成交。这就是“稳定赚到挂单方费率”和“偶尔莫名其妙付了吃单方费率”之间的区别。参见订单类型。 档位内的优先级由位置决定。 同一价格的订单按被排序的先后成交。排在队首的成交，排在队尾的只能看着。参见订单簿。 遵守最小价格变动单位（tick size）和最小数量单位（lot size）。 不符合的价格会被拒绝，而不是四舍五入。空闲保证金资产向下取整，保证金向上取整，所以按恰好等于可用余额的规模报价，会时不时被拒。参见精度。管理报价
最大的实务差别就在这里。
为了管理风险而缩小报价，不会让你失去排队位置。多数场所不是这么运作的，而这改变了库存管理的成本——你可以在某个档位上降低敞口，不必重新排到你犹豫那会儿新来的人后面。参见修改订单。
给每一笔订单都附上客户端订单 ID。 提交超时时，你并不知道它有没有落地。有了自己生成的标识符，你可以按这个标识符撤单，无论哪种情况都停在确定的状态上。没有它，你就只能靠市场、方向、价格和数量去查询和猜测。标识符要随机生成，不要用计数器——重启一次把计数器丢了，就会和活动订单撞上。参见客户端订单 ID。
自成交防护在账户内始终开启。 如果你的新进订单会吃掉你自己的挂单，那笔挂单会被撤销，并打上一个专门的状态。请把这个状态暴露出来：报价因为这个原因消失，说明你自己的两个策略撞在了一起。
子账户之间同样受此保护。自成交防护是按钱包地址来认的，同一个钱包下的每个子账户都共用它——所以你放在不同子账户里跑的两个策略，撞上时照样会互相撤单。如果两个策略确实可以合理地站在对立面，把它们拆到不同子账户做不到这一点，它们需要的是不同的钱包。参见自成交防护。
收益如何
挂单方费率随你的滚动成交量下降，超过某个份额门槛后转为负值——你的每笔挂单成交都能拿到报酬。注意基准不同。费率档位按你自己的绝对成交量衡量；返佣则按占全场挂单方成交量的份额衡量。这是两套不同的资格条件，成为大交易者本身并不能拿到返佣——成为订单簿中有分量的那一部分才能。
规模上的约束
挂单也占用保证金，不只是仓位占用。铺开在许多档位上的宽报价，会为每一个可能开出仓位的档位占用保证金。参见保证金模式。 持仓限额随市场规模缩放。 你在单一方向上的上限，取“市场未平仓合约量的一定比例”和“一个固定下限”中的较大者，并跨子账户合并计算。参见持仓限额。 库存影响你的自动减仓排名。 分数是未实现盈利乘以有效杠杆，所以账本盈利、有偏斜、杠杆又高，就会排在队列很前面。参见自动减仓。如何开始
对接用的是所有人共用的那套接口：REST 和 WebSocket、四种语言的 SDK，以及测试网工具。从开发者开始。 商务合作方面——专属费率、正式的做市协议或上币支持——请联系contact@intention.xyz。参见API 与集成问题。
后续阅读
交易排序
让报价无需靠延迟就能守得住的那套优先级顺序。
修改订单
为什么缩小报价能保住排队位置。
手续费
档位、返佣，以及成交量如何计算。
开发者
API、SDK 和测试网工具。