> ## 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. # 交易排序 > 區塊內各類操作的固定執行順序：撤單、只掛單訂單和強制平倉為什麼都排在任何可能吃掉流動性的操作之前。區塊內的一切都按固定的優先順序執行。不按手續費，不按到達某個節點的時間，也不按與驗證者的距離，而是按類別，由協議決定，在每個節點上完全一致。

系統操作上市 · 風險參數 · 費率表 · 帳戶建立 · 本區塊的標記價格

下游的一切都以同一個價格推理

非撮合操作資金優先 · 帳戶設定 · 只掛單訂單 · 強制平倉

改善帳戶健康度的錢，在任何評估健康度的動作之前先落地

撤單本區塊內的全部撤單

過期報價可以撤回，不會被跟撤單同時到達的訂單吃掉

可能吃掉流動性的訂單一切主動吃單，放在最後

區塊內的次毫秒級競賽不存在

在每個節點上都按這個順序執行

這個位置換來了什麼

這個順序本身就是機制：掛著的報價因此守得住，強制平倉因此無法被搶先交易，次毫秒級的延遲競賽也因此從區塊內部消失。

1 · 系統操作

管理性和協議層級的變更：上線與下線市場、風險參數更新、費率表變更、帳戶與子帳戶建立，以及本區塊的標記價格更新。標記價格先更新，下游的一切才能以同一個價格推理。同一區塊內的強平檢查和新提交的訂單，看到的是同一個數字。

2 · 非撮合操作

不觸及訂單簿、但會改變狀態的操作，內部順序如下： **資金優先**——存入、向逐倉部位手動追加保證金，以及資金費結算。凡是能改善帳戶健康度的錢，都在任何評估健康度的動作之前先落地。 **帳戶設定**——保證金模式、部位模式、槓桿，以及代理人授權的變更。 **Post-only（只掛單）訂單**——唯一在這裡處理、不放到第 4 階段的訂單類型，因為只掛單按定義吃不到流動性。這類訂單保證是掛單方，會按到達順序放上訂單簿，早於任何能與之成交的東西。 **強制平倉**——先撤銷受影響帳戶的訂單，再重新檢查，若仍有必要則接管部位。接管直接以破產價格執行，不進入訂單簿。強制平倉在這裡執行，早於任何自主訂單，這正是區塊內強平無法被搶先交易的原因。等第 4 階段開始，被迫產生的交易流已經處理完畢。

3 · 撤單

使用者發起的撤單，排在任何可能吃掉流動性的訂單之前。這是對報價者最重要的一個階段。**撤單與主動吃單在同一區塊內提交，撤單勝出。** 價格一動，你撤掉過期報價，那麼和你的撤單同時到達的訂單就吃不到這個報價。在多數交易場所，這是一場「誰先到撮合引擎」的競賽，靠延遲取勝。在這裡則由協議決定，不管基礎設施如何，所有人的結果都一樣。

4 · 可能吃掉流動性的訂單

一切可能與訂單簿交叉的操作：任何訂單有效期下的限價單、市價單、TWAP 分片、非只掛單的階梯訂單，以及訂單修改。在這個階段內部，按先進先出處理。

什麼會進到這個階段

這個階段內部按先到先服務處理。關於「什麼會到這裡」，有兩點值得點名。 **Post-only（只掛單）訂單永遠不會到。** 它們在第 2 階段處理，本來也吃不到流動性。 **在鏈上觸發的條件單，會在同一個區塊裡到。** 由本區塊標記價格觸發的停損或停利，會在這裡轉換並進入撮合，而不是等到下一個區塊。觸發是協議依據已提交狀態作的決定，不是某個能挑時點的人提交的。

這改變了什麼

**區塊內延遲不再重要。** 同一區塊內的兩筆訂單有確定的先後次序，每個節點算出來都一樣。區塊之間的到達時間仍然重要，但競爭的單位是區塊。 **報價守得住。** 你可以撤掉過期報價，勝過同一時刻到達的訂單。這是結構性的性質，不是靠主機共置買來的營運優勢。 **被迫產生的交易流先於自主交易流結算。** 強制平倉和資金費在任何人能圍繞它們交易之前就已完成。

後續閱讀

哪些類型能吃掉流動性，哪些不能。為什麼就地減少數量會立即生效。在撮合之前完成的第 2 階段流程。這份時序表在區塊執行中的位置。