Solana（SOL）質押獎勵紀錄漏列費率　核對過往款項須比對歷史資料

Solana（SOL）的質押獎勵紀錄缺少適用手續費率欄位，僅憑紀錄難以還原過去款項所採用的費率。不過，單憑欄位未列出比率，無法判定支付有誤。

質押服務商 P2P.org 在 10 月 30 日發布的第三季報告中表示，首次出現欄位缺漏的是 9 月 8 日的支付紀錄。報告資料涵蓋 P2P.org 營運的 3 個公開驗證者。公司表示，手續費仍持續收取，獎勵金額也已正確結算。

Solana 驗證者客戶端 Agave 的程式碼變更也反映了紀錄方式的調整。5 月 20 日合併的程式碼變更規定，啟用獨立手續費收款帳戶功能後，獎勵資訊中的 commission_bps 值會留空。

SIMD-0232 提案允許驗證者指定獨立的手續費收款帳戶。提案內容指出，透過這類帳戶，驗證者可依照自己的方式分配區塊收益。

若多個驗證者的獎勵匯入同一個收款帳戶，便難以在合併後的紀錄中標示單一手續費率。Agave 開發團隊表示，在這種架構下，於獎勵資料中顯示單一比率可能並不恰當。

這項變更不只適用於投票獎勵，也涵蓋個別質押獎勵資訊。因此，啟用該功能後，RPC 的 getBlock 回應與 Geyser 的 blockSubscribe 訊息中，commission_bps 值也會留空。

commission_bps 是以萬分比表示適用手續費率的欄位。驗證者手續費是從質押獎勵計算，而非從委託本金收取；這與本刊先前說明的手續費機制一致。

因此，獎勵紀錄中的空白代表支付明細缺少資訊，本身不能證明獎勵遭到漏付或超額收費。

若要核對過去的支付紀錄，必須比對獎勵產生時所屬的 epoch、使用者當時委託的驗證者，以及計算獎勵時採用的驗證者手續費設定。僅憑驗證者歷史紀錄，無法證明使用者當時的委託關係。

目前畫面顯示的手續費率，也不能直接套用到過去的獎勵。SIMD-0249 規定，epoch E 產生的通膨獎勵在下一個 epoch 開始時計算時，原則上採用 epoch E-1 開始時的投票帳戶狀態。若該時點尚無帳戶，則採用 epoch E 的狀態；若該時點仍無帳戶，則採用 epoch E+1 開始時的狀態。

epoch 是區分獎勵計算與驗證者狀態變更的期間。依照這項規則，目前設定的費率可能與特定獎勵實際採用的費率不同。

Agave 儲存庫在 10 月 18 日提出的一項 RPC 改進請求舉例說明，即使目前設定顯示為 0%，獎勵計算仍可能使用儲存的 100% 費率。這是對可能情況的說明，並未證實任何特定驗證者有超額收費。

這項請求提出可選欄位，讓回應同時提供目前 epoch 獎勵採用的比率、epoch 與 bank slot。截至 11 月 1 日，請求仍處於開放狀態，尚未登記相關實作。

追蹤過去手續費設定的資料來源之一，是 Jito StakeNet 的驗證者歷史程式。該程式會保存最多 512 個 epoch 的紀錄，包括各驗證者的手續費率，但不會顯示特定使用者在該期間委託給哪個驗證者。

Marinade 的快照解析器會記錄查詢獎勵手續費率時所依據的時間點，以及替代查詢路徑。這些資料也無法自動將獎勵紀錄與使用者的委託紀錄一併證明。

P2P.org 在第三季報告中說明，可透過追蹤帳戶交易紀錄，還原過去的委託關係。核對過去支付款項時，仍須一併比對獎勵所屬 epoch、當時的委託對象，以及該筆獎勵計算所採用的手續費設定時間點。