三件不一樣的事
區塊內部，延遲不決定結果。 同一價格檔位上的優先級是價格優先，其次是在已提交區塊序列中的位置，不是你的封包何時到達某個節點。同一區塊內的兩筆訂單，先後由每個驗證者以完全相同的方式算出。區塊與區塊之間，到達時間仍然重要；但在一個區塊之內，主機共置買不到任何東西。 同一區塊內，你的撤單先於主動吃單。 撤單執行的階段，比「能吃掉流動性的訂單」更早。價格一動，你把過時的報價撤走，這時和撤單同時到達的訂單打不掉它。在大多數場所，這是一場靠基礎設施贏下的競賽；在這裡，它是協議層面的保證。 只掛單訂單在任何人能跟它成交之前就先放上去。 它們在非撮合階段處理，排在所有主動流之前，因為按定義它們不可能吃掉流動性。 三者合起來意味著：在延遲上重金投入的通常理由——保衛報價不被同區塊的逆向選擇打掉——在這裡不成立。參見交易排序。報價
用只掛單。 它保證掛單方身分：會立即成交的訂單直接拒絕，不會讓它以吃單方身分成交。這就是「穩定賺到掛單方費率」和「偶爾莫名其妙付了吃單方費率」之間的區別。參見訂單類型。 檔位內的優先級由位置決定。 同一價格的訂單按排序的先後成交。排在隊首的成交，排在隊尾的只能看著。參見訂單簿。 遵守最小價格變動單位（tick size）和最小數量變動單位（lot size）。 不符合的價格會直接拒絕，不會四捨五入。空閒擔保品無條件捨去、保證金無條件進位，所以報價數量抓得剛好等於可用餘額，會三不五時被拒。參見精度。管理報價
最大的實務差別就在這裡。
為了管理風險而縮小報價，不會讓你失去排隊位置。多數場所不是這麼運作的，而這改變了庫存管理的成本：你可以在某個檔位上降低曝險，不必重新排到那些在你猶豫時才到的人後面。參見修改訂單。
給每一筆訂單都附上用戶端訂單 ID。 提交一逾時，你就不知道它有沒有落地。有了自己產生的識別碼，你可以按這個識別碼撤單，兩種情況都停在確定的狀態上。沒有識別碼，就只能靠市場、方向、價格和數量去查、去猜。識別碼要隨機產生，不要用計數器：重啟一次、計數器掉了，就會和還掛著的訂單撞號。參見用戶端訂單 ID。
自成交防護在帳戶內始終開啟。 如果你的新進訂單會吃掉你自己的掛單，那筆掛單會被撤銷，並標上一個專門的狀態。把這個狀態呈現出來：報價因此消失，意味著你自己的兩個策略撞在了一起。
子帳戶之間同樣受此保護。自成交防護是以錢包地址為判斷依據，同一個錢包底下的每一個子帳戶都共用這個依據——所以你放在不同子帳戶裡的兩個策略，一旦交叉，還是會互相撤單。如果兩個策略可以合理地站在對立面，把它們拆進不同子帳戶做不到這件事：它們需要的是不同的錢包。參見自成交防護。
收益如何
掛單方費率隨你的滾動交易量下降，超過某個份額門檻之後轉為負值：你的每一筆掛單成交都能拿到報酬。注意基準不同。費率級距按你自己的絕對交易量衡量；手續費回饋則按佔全場掛單方成交量的份額衡量。這是兩套不同的資格條件，光是成為大交易者拿不到回饋，要成為訂單簿裡有分量的那一部分才行。
規模上的約束
掛單也佔用保證金，不只是部位佔用。報價鋪得寬、檔位鋪得多，每一個可能開出部位的檔位都會佔掉保證金。參見保證金模式。 部位限額隨市場規模縮放。 你在單一方向上的上限，取「市場未平倉合約量的一定比例」與「一個固定下限」中的較大者，並跨子帳戶合併計算。參見部位限額。 庫存影響你的自動減倉排名。 分數是未實現獲利乘上有效槓桿，所以帳本要是槓桿高、有偏斜又在獲利，就會排在佇列很前面。參見自動減倉。如何開始
串接用的是所有人共用的那套介面：REST 和 WebSocket、四種語言的 SDK，以及測試網工具。從開發者開始。 商務合作方面——專屬費率、正式的做市協議或上架支援——請聯絡contact@intention.xyz。參見建構者與串接問題。
後續閱讀
交易排序
不必靠延遲就守得住報價的那套優先級順序。
修改訂單
為什麼縮小報價能保住排隊位置。
手續費
級距、手續費回饋，以及交易量如何計算。
開發者
API、SDK 和測試網工具。