收益與成本
礦池費率如何影響實際收益
選礦池只看 headline fee 會失真。費率基礎、區塊補貼與交易費分配、PPS/PPLNS/FPPS、最低付款、network fee、拒絕 share 和付款時間，共同決定實際收益。 資料核對日期：2026-08-09（UTC+8）。礦池條款會變，決策日應在帳戶和官方文件重新核對 metho
選礦池只看 headline fee 會失真。費率基礎、區塊補貼與交易費分配、PPS/PPLNS/FPPS、最低付款、network fee、拒絕 share 和付款時間，共同決定實際收益。
資料核對日期：2026-08-09（UTC+8）。礦池條款會變，決策日應在帳戶和官方文件重新核對 method、fee 與 payout。
目錄
- 先確認費率基礎
- 結算方法帶來的風險
- 做可比較的 A/B test
- 別漏掉 cash timing
- 把差異換成經營影響
- Due diligence 與切換
- 決策規則
- 把費率拆成合約層級的清單
- 常見問題
先確認費率基礎
淨 payout BTC＝gross 理論 BTC－服務費－付款/network fee－拒絕 share 損失。但各 pool 對 gross 的定義可能不同，有些把 subsidy 與 transaction fee 合併，有些分項。
比較 1% 和 2% 前，要證明兩者作用於相同 reward。限時 bonus 或折扣不能當長期假設。
結算方法帶來的風險
PPS 類方法通常較平滑，但費率結構也可能不同；PPLNS 受 pool luck 與 round 影響，短期波動較大；SOLO 則是完全不同的低頻事件風險。
ViaBTC 與 Braiins 的第一手說明可協助理解名詞，實際條款仍以所選 pool 當前文件為準。單月最好成績不能證明方法長期較優。
做可比較的 A/B test
使用同型號、相近功率模式、同一期間與足夠長的觀察窗，並記 accepted TH/s、reject、downtime 和 payout BTC。不要拿不同品質機器分組後把差異歸因於 pool。
有效 pool yield＝net payout BTC ÷ accepted TH/s-hour。對 PPLNS 要標明短期統計噪音。
別漏掉 cash timing
高 payout threshold 會讓 working capital 留在 pool；network fee、付款日程和改地址鎖定都影響現金。latency 可能增加 stale/reject。
Failover 未測試時，主 endpoint 中斷後 ASIC 可能看似在線卻沒有有效產出。每季測 primary/secondary、DNS、firewall 和實際切換。
把差異換成經營影響
月費率差 KZT＝gross BTC×費率差×保守 BTC/KZT。若為省 0.5% 卻多 1% reject 或延遲提款，名義優勢就消失。
至少測正常、網路惡化、payout 延遲 48 小時三情境，顯示 net BTC、付款時間和電費 coverage。
Due diligence 與切換
核對營運主體、method/fee、payout policy、安全、sub-account、read-only 權限、匯出和事故通知。API token 不放文章或共享表，採最小權限與 rotation。
切換前安排 worker naming、wallet、稅務/對帳匯出和舊 pool 未付餘額；先 pilot，不一次搬整場。
決策規則
用 net yield、reject、付款可靠度、匯出/對帳和支援共同評分。若連續多個足夠窗口低於 benchmark，先排除網路與機器差異，再決定是否換 pool。
常見問題
0% fee 一定最好嗎？
不一定，還要看 reward 基礎、活動期限、reject 與付款費用。
一週能比較 PPLNS 嗎？
通常太短，luck 會放大結果。
最重要 KPI 是什麼？
accepted TH/s-hour 的 net payout BTC，加上付款時點與可靠度。
把費率拆成合約層級的清單
不要只抄行銷頁的一個百分比。清單要分列結算方法、service fee、交易費分配、payout/network fee、最低付款、付款週期、休眠餘額及其他服務費。每欄保留官方 URL、核對日期、帳戶顯示值與核對人。
限期 0% fee、新客 bonus 或特定算力 tier 不能直接當長期基準。現金流應採活動結束後的標準條件，折扣只列為暫時 upside。比較前也要確認 1% 與 2% 是否作用於相同 reward base；一個顯示 gross、另一個顯示 fee 後數字時，表面費率沒有可比性。
測試窗口與設備分組
單日 payout 會放大 luck 與營運噪音。觀察窗應涵蓋多個完整付款週期、一般維護時段及足夠 accepted work；資料不足就標示尚不能下結論。
測試組使用同型號、相近韌體、功率模式、進風溫度及網路路徑，並按預先規則分配設備。開始前固定 KPI：每 accepted TH/s-hour 的淨 BTC、reject/stale、付款延遲、斷線與人工介入。測試中途不得為配合結果改定義。
以 accepted work 為比較基礎
淨 yield＝實際 credited BTC÷accepted TH/s-hour。同時保存本機算力與牆上功率，因為 latency、vardiff、worker 設定及 pool smoothing 也會影響 accepted 數字。若收益差異可由 reject 上升解釋，問題可能在網路或設定，不是 headline fee。
兩個 pool 的日界線與時區也要統一。UTC 日報不能直接和本地日報逐行相減；export 必須保存 period start/end、timezone 與單位。
計算完整 leakage
至少拆成公開 service fee、payout/network fee、超出正常基準的 reject/stale，以及付款延遲造成的流動性成本。完整 leakage＝理論 gross BTC－錢包實收 BTC 只能作橋接，不能把所有差額都歸咎於 pool；停機、設備衰退、difficulty 與本地網路要另外 attribution。
以下只示範方法，不是任何礦池現行費率。若 Pool A 對 0.020 BTC 收 2%，另扣 0.00005 BTC payout fee，實收為 0.020×0.98－0.00005＝0.01955 BTC。Pool B headline fee 1%，但基準外 reject 損失 1.2%，另扣 0.00008 BTC，估算為 0.020×0.988×0.99－0.00008≈0.0194824 BTC。較低 headline fee 在此假設中反而沒有較高淨入帳；實際數字必須來自當期官方條款和自己的測試。
Payout 時點與營運資金
最低付款高時，小型 cohort 的 BTC 會較久留在 pool。模型要分開 estimated payout、actual payout、鏈上確認、wallet credit 與出售入帳。尚未到錢包或尚未出售的 BTC 不是支付電費的現金。
變更 payout address 可能觸發 lock 或 review，遷移前應先以小額測試，由兩人核對 network、address 與 txid。現金儲備應能承受至少一個合理的延遲情境，不可假設每次都按最快速度付款。
把可靠度納入成本
保存 status page、事故通知、維護窗口、support 回覆及 balance exception。一次事故不必然否決礦池，但要評估持續時間、付款影響、溝通與修復。
Failover 要實測：主 endpoint 中斷後多久切到 secondary、accepted hashrate 何時恢復、主站回來後是否反覆切換。帳戶採 read-only 日常權限、提款地址變更加強核准、API key 最小權限與 rotation；token 不得放在文章、共享表或工單正文。
分階段遷移與回滾
先移小型 pilot cohort，記錄 worker、endpoint、method、fee、wallet 與 timezone。Pilot 通過多個事先規定窗口後才搬全場，且保留回到舊 pool 的設定。遷移日同時記錄兩邊 unpaid balance，查明未達最低額的舊餘額如何處理。
新 pool 顯示 online 不代表驗收完成。應記第一筆 accepted share、第一筆 credit、第一筆 payout 及錢包入帳，並同步調整 DNS、firewall、monitoring 與 alert。
月底 reconciliation
使用橋接表核對 theoretical reward、pool credit、unpaid balance 變化、payout、鏈上 tx 與 wallet credit：期初 unpaid＋本期 credit－adjustment－payout＝期末 unpaid。BTC 與 KZT 分開，KZT 依帶日期的實際出售或管理匯率換算。
差異不能統稱 fee。Adjustment、付款費、threshold、pending tx、timezone cutoff 與人工修正要有不同 exception code、證據和負責人。最終 scorecard 同看 net yield、reject、付款可靠度、匯出品質、帳戶控制與 support；權重在測試前固定。
何時才應切換
單一差日先排除電力、網路、韌體及 worker 設定。經多個足夠窗口仍低於 benchmark、付款例外重複或條款有不可接受變更時，才按 pilot、unpaid balance、rollback 與 cash reserve 計畫遷移。如此比較的是錢包真正收到的 BTC 與付款時間，而不是廣告上的一個百分比。
證據保存與資料不足規則
每次比較要保存條款版本、官方網址、核對時間、帳戶 fee 畫面、匯出檔雜湊、觀察窗起訖及使用的 worker 清單。截圖只能證明當時畫面，不能代替可加總的 CSV 或鏈上 tx；API token、帳號、電郵與內部 URL 必須遮蓋，且不放入文章或共享決策包。
若缺少 accepted hashrate、opening unpaid balance、付款 txid、時區或 fee 定義，結果應標示「資料不足」，不能把空值當零。責任人要記下缺哪一項、向哪個第一手來源取得，以及帶時區的 RFC3339 截止時間。截止時間到了仍未補齊，不會自動變成通過。
版本控制也很重要。新條款或補到的 export 不應覆蓋原測試檔；保留舊版、變更理由與重新計算結果，才能在數月後解釋為何當時選擇或拒絕某礦池。若同一模型只有在更換輸入後才「勝出」，核准者必須看見前後差異，而不是只收到最新的漂亮結果。
這套證據包也讓財務與技術使用同一事件編號。Pool credit、鏈上 payout、wallet 入帳和 KZT 結算可追到相同期間，避免技術團隊說已付款、財務卻因日界線不同仍找不到款項。