BTC 出售與保管
挖礦產出 BTC 的分批出售計畫
礦工的 BTC 出售計畫不是猜最高價，而是確保電費、hosting、工資、維修及稅務準備能在到期日以 KZT 支付；剩餘 BTC 是否持有，則是另一個決策。 資料核對日期：2026-08-09（UTC+8）。交易前以 AFSA public register 重新核對平台授權，以及當日費率、限額、K
礦工的 BTC 出售計畫不是猜最高價，而是確保電費、hosting、工資、維修及稅務準備能在到期日以 KZT 支付；剩餘 BTC 是否持有，則是另一個決策。
資料核對日期：2026-08-09（UTC+8）。交易前以 AFSA public register 重新核對平台授權，以及當日費率、限額、KYC 和提領條件。本文不是投資或稅務意見。
目錄
- 從付款日曆倒推
- 三個資金桶
- 分批規則由期限決定
- 先查平台授權與出金路徑
- 留下完整執行鏈
- 壓力測試
- 管理門檻
- 把現金流拆成日、週、月三個視窗
- 把每一批出售變成可覆核的執行單
- 用現金義務決定出售節奏
- 常見問題
從付款日曆倒推
列出未來 30/60/90 日的電力、適用挖礦費、hosting/租金、薪資、維修、債務與稅務準備，標明到期日和遲付後果。
需售 BTC＝（到期 KZT＋安全儲備－現有 KZT）÷保守淨成交價。淨成交價要扣 spread、交易/兌換費、提領或銀行費及 slippage，不能用畫面最高報價。
三個資金桶
營運桶服務近期帳單，不承擔不必要價格風險；準備桶用於維修和意外停機；長期桶只在前兩者充足後存在。帳務上每份 BTC 只能有一個用途，否則同一餘額同時被當成電費和長期資產，流動性會虛高。
分批規則由期限決定
可在帳單前 14、7、2 日設多個 tranche，實際比例由現金緩衝決定。每批寫明數量、最早/最遲時間、核准平台和責任人。
價格下跌時，必付帳單仍按 liquidity rule 處理；價格上升時，也不應把未來兩期帳款準備全部換回 BTC。
先查平台授權與出金路徑
AFSA 的授權查核頁和 DASP public register 可核對公司、牌照狀態及 permitted activities。舊新聞和品牌頁不能取代即時登記。
預先完成 KYC，確認個人/法人帳戶、deposit network、memo/tag、日限額和銀行提領。首次轉入先小額測試，地址與 network 採雙人覆核。
留下完整執行鏈
每筆保存 pool payout ID、wallet txid、平台 deposit ID、BTC 數量、gross KZT、費用與 spread、net KZT、銀行入帳時間及所支付帳款。CSV/PDF statement、鏈上交易和銀行紀錄比單一截圖更可靠；敏感帳號、email、token 不公開。
壓力測試
同時假設價格 −20%、payout 延遲 48 小時、銀行提領暫停，計算最低 KZT reserve 和最後安全出售日。備援平台/銀行必須事前完成 KYC 與小額測試。
若付款完全依賴單一平台、銀行或某日價格，就是 concentration risk，不能靠「幣價會漲」處理。
管理門檻
未來 30 日 KZT coverage 低於 1.0 時啟動出售評估；高於自訂上限時再決定多餘資金用途。每次大幅 difficulty、電力帳單、提領限制或牌照狀態改變都要更新。
常見問題
是否應把所有 BTC 立即賣掉？
沒有通用答案；先覆蓋義務和準備金，再對餘額另定政策。
掛限價單就夠嗎？
不夠，未成交時仍要有期限與 fallback。
在哪裡查牌照？
交易前在 AFSA public register 核對法律實體和 permitted activities。
把現金流拆成日、週、月三個視窗
日視窗看銀行 cut-off、電費預繳與已到期帳款；週視窗看 pool payout、薪資和 hosting；月視窗看稅務準備、維修與債務。每項義務只給一個 ID，避免同一張電費在不同表重複計算。
每列保留合約/發票金額、最可能金額與 stress 金額。發票尚未收到時，不把未知數當成零；以耗電、費率和運行日建立有依據的區間。KZT 餘額也區分可立即動用、受限制存款、稅務專款和自由準備，只有在到期日前真正可用的資金才能放進 coverage。
把每筆產出標記為可追溯 cohort
Pool payout 連結生產期間、pool、wallet address、txid、BTC 數量與該期間成本。FIFO、加權平均或其他會計方法應由當地稅務專業人士確認，並在期間內一致使用。本文不指定通用稅務方法。
預估 earned、pool confirmed、on-chain received、platform credited、trade executed 與 bank settled 是六個不同狀態。Pending pool balance 不是 wallet BTC，wallet BTC 也不是已到銀行的 KZT。每個階段給 confidence，避免用尚未結算的產出支付今天的帳單。
用實際入帳計算 net execution price
一批的真正結果是：
每 BTC 淨 KZT＝銀行實收 KZT ÷ 售出 BTC。
把 trading/convert fee、spread、slippage、鏈上費、提領或銀行費拆開。部分成本藏在 bid/ask，不會顯示為 fee，所以要保存下單時參考報價和實際 fills。比較平台時用相同時間、近似規模和相同銀行目的地做小額 controlled test；最高畫面價格不能凌駕牌照、提領可靠性和限額。
三個資金桶使用不同 trigger
營運桶依到期日與 coverage 出售；準備桶低於政策最低線時補足；長期桶只在核准的 rebalance 或風險限額下調整。不要因價格上漲就把電費桶臨時改成長期持有，也不要在下跌後把準備桶重新命名來掩蓋不足。
必付帳款不能只掛一張可能不成交的 limit order。事先寫明距 deadline 多久仍未成交時，改用可成交訂單、OTC 或另一個已核准渠道。這不是推薦某種產品，而是避免把現金流交給未成交訂單。
為每個 venue 建 readiness 檔案
記錄法律實體、AFSA register 結果及日期、permitted activity、account owner、KYC、限額、BTC network、銀行提領渠道、官方支援 escalation 和最後測試日。牌照、限額或提領狀態改變時自動標為 hold。
生產屬於公司、帳戶卻屬於個人時，ownership 與 source-of-funds 可能不匹配。不要借用他人帳戶或銀行卡「快速出金」。Deposit address 每批從帳戶內重新取得，核對 network 與 address-change alert；大額前先做小額 credit test，memo/tag 亦雙人確認。
P2P 或銀行轉帳要看真實入帳
若使用 P2P，依當日平台官方規則操作。「已付款」按鈕或對方傳來的收據不等於銀行可用餘額。只有完整、正確幣別的款項進入核准帳戶並經銀行獨立確認後，才按平台流程放行 BTC。
第三方姓名、拆單付款、要求把多付金額退到另一帳戶，或要求離開 platform chat，都要停止並進行 compliance review。Bank transfer 若可能被 hold 或退回，政策要寫明 settlement finality；所有支援溝通使用官方渠道並保存 case ID。
每批建立 execution ticket
Ticket 包含 forecast 版本、資金桶、BTC 數量、deadline、venue、order type、限額、預期 net KZT、銀行目的地、申請人與核准人。核准後更改地址、金額或 venue 必須重新批准，聊天裏一句「可以」不構成完整證據。
執行者附上 fills、平台費、txid 和 withdrawal reference；覆核者檢查銀行入帳與 net KZT。同一人不應同時選 quote、改地址、執行交易和關閉 reconciliation。若把大批拆小，要同時量化 slippage 改善與多次費用、操作錯誤的增加。
做 wallet、platform、bank 三方對帳
從 pool payout 到 platform deposit 用 txid 連結；deposit 到 trade 用 account entry；trade 到 bank credit 用 withdrawal reference。一個系統的截圖不能證明另一個系統已結算。
每日 close 核對 expected BTC、credited BTC、sold BTC、剩餘餘額、gross KZT、費用和 bank-settled KZT。差異超過內部 tolerance 時 ticket 不關閉，並標記 timing、pending confirmation、fee、partial fill 或錯誤期間。稅務與會計處理交由當地專業人士按一致政策確認。
把多個壞情境疊在一起測試
同時假設 network fee 上升、pool payout 延遲 48 小時、BTC 下跌、主要平台 account review、銀行 cut-off 已過，計算最後安全轉帳日、最低出售量、KZT buffer 和責任人。Fallback venue 必須已查牌照、完成 KYC、通過 test deposit/withdrawal 且銀行目的地可用，否則只是紙上備援。
若 stress 情境下仍會遲付電費或薪資，應增加 KZT 準備、減少長期 BTC 桶或重談付款期限。「價格會反彈」不是控制措施。
明確寫出停止線
以下任一情況停止或 escalation：AFSA 狀態未核對；account owner 與生產主體不一致；network/address 未雙人確認；KYC 或 limit 不足；銀行目的地未知；費用與報價來源不清；approver 不在；懷疑 malware；出現第三方付款；source-of-funds 文件未準備。
停止不代表忘記帳單。Incident lead 更新 forecast 和最後安全日，再啟動事前核准的備援渠道。月底檢查按計畫完成率、net execution 偏差、settlement 時間、exception 數及最低 coverage，下一期 tranche 依這些實際資料調整，而不是事後用幣價高低評價流程。
把每一批出售變成可覆核的執行單
分批出售不能只留下交易所成交畫面。每一批應先寫明用途、BTC 數量、最晚到款日、可接受的最低淨價、預估交易費與批准人。成交後補上實際撮合明細、平台費用、銀行入帳與 txid，並把報價、成交價和最終淨收款之間的差額拆開。這樣才能判斷偏差來自市場波動、流動性、手續費，還是操作錯誤。
若使用 P2P，收款人姓名、付款帳戶與訂單資訊必須一致；第三方付款、催促提前放幣或要求轉到站外溝通，都應觸發停止條件。款項只在銀行端確認不可撤回地入帳後才放幣，不以簡訊、截圖或對方口頭承諾替代。異常訂單保留平台工單與處理記錄，不用另一筆交易掩蓋差額。
每月將「已產出、已入錢包、已轉平台、已出售、已收法幣、期末持有」做成一條數量橋接。任何不平項都指定負責人與期限，未解釋前不把該月出售流程標為完成。這份執行單也能讓礦工在不同出售節奏間比較真正的淨結果，而不是只看某一次成交價格。
用現金義務決定出售節奏
先把未來八到十二週的電費、數位挖礦繳費、薪資、hosting、維修與稅務支出按到期日排列，再將可動用法幣、已確認但未到帳的款項及可出售 BTC 分開。出售量應由已核准的現金缺口推導，不因短期漲跌臨時改成全賣或完全不賣。對每一類義務設定安全緩衝，避免平台審查、銀行延遲或鏈上擁堵使付款逾期。
情境表至少包含 BTC 下跌、交易深度減少、提款暫停與礦場產出下降的組合，而不是逐一孤立測試。若最差情境下仍不足以覆蓋必要支出，應提前降低非必要 CAPEX 或增加法幣儲備，不能把解決方案全部押在未來更高的 BTC 價格。管理層批准的出售區間、單筆上限與偏離權限寫入 treasury policy。
比較不同執行時段的淨結果
同一平台在不同時段的 order book、spread 與銀行處理速度可能不同。先用小額交易記錄委託深度、實際滑價、費用和到款時間，建立自己的執行基準。不要用平台首頁報價替代可成交價格，也不要把返佣折扣當成固定收入；BN8812 所示最高 20% 仍以當期頁面和帳戶實際適用條件為準。
當單筆規模明顯超過可見深度時，可在不違反資金時限的前提下拆單，並為每一筆保留相同的執行單。拆單後比較成交量加權淨價，不挑選最好的一筆作為整批成果。若實際滑價連續超過政策上限，暫停後續交易，重新評估時段、委託方式或合規可用的其他受監管渠道。
建立出售後的例外與復盤制度
例外清單至少包括地址比對失敗、confirmation 超時、實收款與訂單不符、第三方付款、平台額外審查、銀行退匯和會計期間錯置。每項例外要有 materiality、owner、期限與結案證據；不能以客服工單已開立就視為結束。涉及安全或身份異常時，後續轉帳與放幣立即停止。
每季復盤預估與實際現金需求、平均淨出售價、總費用、滑價、到款時間及未解決例外。若預估長期偏低，可能造成被迫急售；若長期偏高，則會犧牲持有策略。把偏差原因回寫下一季參數，讓出售計畫隨真實營運資料更新，而不是沿用固定百分比。