Solana 一項旨在規範交易排序的提案，原擬要求驗證者檢查同一批次內的交易是否依費用優先級排列，但不會限制出塊者決定哪些交易納入區塊，也不會規定批次的起訖位置。SIMD-0649 拉取請求已於 2026 年 9 月 25 日關閉，未獲合併，相關規則尚未生效。由於目前缺少批次規模的實測數據，這項提案能否讓交易執行更可預測，仍無法判定。
SIMD-0649 擬核對批次內的交易排序
Solana 帳本會將區塊資料分成多個批次。依提案設計，除豁免交易外，同一批次內的交易必須按優先級由高至低排列。驗證者重播區塊時會核對交易的記錄順序；若順序不符規則，便會將整個區塊判定為無效，而不是在收到區塊後代為重新排序。
優先級相同的交易可按任意順序排列，簡單投票交易則不適用這項規則。提案所稱的優先級分數，也不等同於使用者填寫的費用高低：計算方式是出塊者納入交易可取得的獎勵，除以交易執行前成本模型估算的請求成本。計算採用含乘數及分母保護項的整數運算，目的是讓不同客戶端得出一致結果。
依提案描述的費用規則，獎勵包括優先費，以及未被銷毀的部分基礎費用。若規則實施，觀察者便能判斷出塊者放入同一批次的非豁免交易，是否依統一標準排序。提案作者認為，統一的核對方式有助於不同驗證者客戶端及排程器檢查交易順序；但它不會回答某筆交易原本是否應該被納入區塊。
出塊者仍可選交易並劃定批次邊界
提案並未試圖建立一套適用於整個時隙的統一優先佇列。出塊者仍可挑選要納入區塊的交易、將交易延後至後續批次，並自行決定批次邊界。因此，兩筆互相競爭的交易未必會進入同一批次接受排序比較；即使其中一筆優先級較高，若被排入後續批次，也不會因此自動排到較早批次的交易之前。
換言之，這項規則的約束範圍限於批次內排序，不涵蓋整個時隙，也不保證交易能以最佳條件執行。提案因此設定批次大小下限，避免出塊者把批次切得過小、減少可供比較的交易，削弱排序核查的作用。
除最後一個批次外，每個批次至少須涵蓋兩個前向糾錯（FEC）集合。FEC 集合由構成區塊的資料分片（shreds）組成；依提案採用的固定大小規則，兩個集合至少相當於 64 個資料分片。最後一個批次仍須接受排序檢查，但由於時隙可能在批次填滿前結束，因此不受這項規模下限限制。
缺少批次規模數據，難以估算實際效果
9 月 23 日的一則審查意見指出，即使設有批次下限，出塊者仍可能在有利於分隔衝突交易時結束當前批次。審查者要求提供依排程器、客戶端及市場狀況分類的現行批次規模數據，並建議測試不同下限對結果的影響。這些意見質疑的是規則在實際運作中的涵蓋程度，並不表示出塊者已在主網採用過這種做法。
提案指出，Agave 和 Firedancer 的目標批次規模約為兩個 FEC 集合，但提案及審查意見都未提供出塊者目前實際批次規模的分布資料。因此，無法量化這項下限會在多大程度上影響日常出塊，也難以判斷它能否有效限制出塊者調整批次邊界的空間。
延遲與優先交易疑慮尚未排除
8 月的一場討論也提出延遲方面的疑慮：若驗證者必須等到整個批次到齊才能核查，可能影響 Firedancer 對部分到達資料進行重播的方式。修訂後的草案允許驗證者隨交易到達逐步比較並執行；若之後發現排序不符，仍可將區塊判定為無效。不過，在交易量較低時，要求出塊者等到批次達到兩個 FEC 集合的下限，可能增加廣播延遲；現有資料並未提供延遲測量結果。
提案也無法阻止出塊者透過向自己支付優先費，讓自身交易取得較有利的排序。提案指出，優先費會回到出塊者手中，而被銷毀的基礎費用部分仍是成本。因此，批次內排序核查不能視為防止偏袒、最大可提取價值（MEV）或滑點的保障。
SIMD-0649 已於 9 月 25 日關閉，後續是否推進，取決於進一步討論及客戶端開發者的支持。對交易者而言，仍待釐清的重點，是有多少實際競爭的交易會落在同一批次，以及批次下限是否會改變出塊者的行為。在相關數據補足前，這項提案提供的是核查批次內相對排序的方法，其對實際交易執行的影響仍未確定。