如何使用 UniSat 批量鑄造 BRC-20 代幣？ （效率提示）

批量鑄造工作流程概述

1. 使用者必須準備一個有效的JSON文件，其中包含收件人地址和相應的代幣數量。該結構要求嚴格遵守 UniSat 可接受的模式—不允許使用額外的欄位或嵌套物件。

2. 錢包連線僅透過 UniSat 錢包擴充進行。由於簽章方案與 Bitcoin 的 OP_RETURN 約束不相容，MetaMask 或其他非原生錢包無法對 BRC-20 批次操作進行簽署。

3. 交易費用根據 UTXO 數量和資料負載大小動態計算。單一批量鑄幣可能會消耗 3-7 個 UTXO，具體取決於提交前的輸入合併狀態。

4. 每個鑄幣條目都會在同一交易中觸發一個單獨的銘文。 UniSat 將它們分組在一個 PSBT 下，但將它們作為鏈上的單獨銘文進行廣播，在序數瀏覽器上顯示為不同的條目。

JSON 模式驗證規則

1. 根物件必須是數組。空數組或標量值將在簽章提示前停止處理。

2. 每個陣列元素必須恰好包含兩個鍵： 'address'和'amount' 。任何偏差（包括拼字錯誤的按鍵或附加元資料）都會導致無聲拒絕。

3. 位址驗證強制執行 Bech32m 格式以實現 Taproot 相容性。傳統 P2PKH 或嵌套 SegWit 位址會立即回傳解析失敗，而不會嘗試回退。

4. 金額只接受正整數。小數值、科學記數法或字串編碼數字會在網路互動之前觸發客戶端驗證錯誤。

費用優化技術

1. 在批量鑄造之前至少 24 小時將小型 UTXO 合併為較大的 UTXO。這減少了每筆交易的輸入數量，並降低了記憶體池擁堵高峰期間的費用壓力。

2. 避免在 BTC 區塊最終視窗（每個時期的最後 3 個區塊）期間進行鑄造。 Mempool 飽和度峰值與這些間隔密切相關，使有效 sat/vB 率膨脹高達 40%。

3. 使用 UniSat 的「費用預覽」切換來模擬三個費用等級：慢速（1-3 個區塊）、標準（1-2 個區塊）和緊急（下一個區塊）。只有當競爭性高費用 RBF 交易重新組織記憶體池時，實際確認時間才會與估計時間有所偏差。

4. 如果執行自訂節點基礎設施，請停用自動費用估算。手動 sat/vB 輸入繞過了 UniSat 的第三方 API 依賴性，並防止費用市場快速變化期間出現偏差。

鏈上驗證協議

1. 每個銘文 ID 顯示為唯一的 64 個字元的十六進位字串，前綴為「 ord: 」。這些 ID 是不可變的，可以作為 mint 執行的規範證明。

2. 代幣餘額跨索引器非同步更新。 Blockstream Green 和 Hiro Explorer 通常反映 2-5 次確認內的變化；由於批次索引器同步週期，Dune Analytics 儀表板可能會落後最多 12 個區塊。

3. 失敗的鑄幣廠不會恢復gas－無論部分成功，它們都會消耗全部交易費用。 UniSat 單獨記錄失敗的條目，但不退還任何部分的廣播費用。

4. 使用相同 JSON 有效負載的重新記入嘗試會產生新的記入 ID。協議層面不存在重複資料刪除邏輯；重複提交被視為獨立的有序工件。

常見問題解答

Q：我可以在批次 Mint JSON 中包含令牌名稱或小數點等元資料嗎？答：不可以。 BRC-20 批量鑄幣僅支援地址和金額欄位。元資料必須在初始部署銘文期間設置，而不是在分發期間設置。

Q：UniSat 是否支援 CSV 導入而不是 JSON 進行批次操作？答： 不是原生的。第三方轉換器存在，但會帶來編碼損壞的風險，尤其是使用 UTF-8 BOM 或逗號分隔的位址截斷時。

Q：如果我的錢包用完了聰的中批量處理，會發生什麼事？ A：在簽名前整個交易就失敗了。 UniSat 在 PSBT 產生之前根據估計費用 + 銘文成本驗證可用餘額。

Q：一次批量請求中可以包含的位址數量是否有限制？答：是的。每個 JSON 檔案允許的最大條目數為 100。嘗試超過此閾值會從 UniSat 的 API 閘道返回 HTTP 413 Payload Too Large。