擬約、議約、定稿，
然後留下 站得住腳的證據

定稿當下對該版本內容原文（UTF-8）計算 SHA-256，指紋印在證據報告與 A4 文件末頁的「數位認證指紋」區塊。同一個指紋送交第三方時戳機構，取回 RFC 3161 時戳權杖；.tsr 檔可從系統下載，用 openssl ts -verify 獨立驗算——不需要我們的系統，也不需要相信我們。證據報告會把時戳涵蓋的雜湊與目前定稿指紋比對，標示為「時戳一致：涵蓋目前定稿指紋」或「時戳不符：非目前定稿指紋」。

這不證明什麼： 時戳證明的是那個雜湊值在簽發時點之前就已存在，不證明內容為真、不證明簽署人是誰，也不等同公證。

稽核軌跡是 append-only 雜湊鏈，每筆事件的雜湊都含前一筆的雜湊，因此「只改一筆而不重算後續」會立即被偵測。但能重算整條鏈的一方——也就是我們——重算後的鏈驗證起來完全正常。所以鏈頭會送第三方時戳機構簽發 RFC 3161 時戳，那一刻之前的事件我們就改不動了。證據報告逐段標示「已錨定」或「未錨定」，並且白紙黑字寫著：未錨定僅代表本平台自身紀錄一致，尚無第三方佐證。資料庫層還有兩道：已寫入的簽名列由 append-only 觸發器擋下 UPDATE，簽署證據相關的外鍵一律 ON DELETE RESTRICT——合約或邀請一旦帶有簽署證據，資料庫就拒絕刪除它。

這不證明什麼： 雜湊鏈本身不構成對抗本平台的效力，未錨定的區段只通過我們自己的一致性檢查。這句話不是行銷話術，它就印在證據報告上。

每天結束後，當日所有簽署彙總成一棵 Merkle 樹。葉節點為 SHA-256(0x00 ‖ 正規化原文)，內部節點為 SHA-256(0x01 ‖ 左 ‖ 右)，前綴用來區分兩者，避免以葉節點偽造內部節點；奇數節點直接升位而非複製自己。葉節點原文採長度前綴格式（名稱=位元組長度:值），欄位順序固定為 v, signature_id, request_id, contract_id, chain_head_hash, chain_head_seq, signed_at——公開於證據報告，可自行重算。樹根連同一段自我描述的敘述（含日期、格式版本、樹根、當日筆數）送往三處：RFC 3161 時戳（多家機構備援，並記錄實際簽發的那一家）、Sigstore Rekor 公開透明日誌、OpenTimestamps（最終寫入 Bitcoin 交易）。Rekor 的查詢是以該敘述的 SHA-256 反查索引，因此第三方不需要接受我們對「哪一筆是你的」的說法；OpenTimestamps 收據一經 Bitcoin 確認，驗證只需要 Bitcoin——不需要我們、不需要 Sigstore，也不需要 OpenTimestamps 自己還在。證據報告將三者分開列出各自狀態，包含 OTS 尚未確認的等待狀態與確認後的 Bitcoin 區塊高度。報告上印出的是你那一天的實際數值——樹根、Rekor 的 logIndex、Bitcoin 區塊高度——不是說明文字裡的範例；每一個都能拿去對應的公開系統查，而那些系統與本平台沒有關係。

這不證明什麼： 送出去的是一個 64 字元的雜湊值與日期，合約內容、姓名、金額都不在裡面——這既是隱私上的必要，也表示它不證明內容為何。彙總以「天」為單位且當日結束後才建樹，所以今天簽的要等今天過完；稽核雜湊鏈之前的舊簽署永遠不會被涵蓋，報告會據實寫出。OpenTimestamps 顯示「已送出，尚未確認」時，該收據還不構成可獨立驗證的時間證明，通常需數小時——期間即使該摘要其實已被寫進某筆 Bitcoin 交易，報告仍不會顯示區塊高度，因為在收據補完之前，「你的摘要在那筆交易底下」是 calendar 的說法而不是可驗證的路徑。我們選擇讓報告晚一點說，而不是早一點借別人的話說。最後：沒有任何法條因為一份資料的雜湊出現在 Bitcoin 上而提高它的地位，提高的是你的舉證能力。

收件地址由發起人填寫，簽署頁只做遮蔽顯示，對方改不了。6 位數驗證碼 10 分鐘有效、連錯 5 次即作廢、60 秒才能重寄、整份邀請最多寄 5 次。簽署歷程逐筆記下寄出邀請、驗證通過、首次開啟合約、勾選同意聲明、完成簽署的時間、來源 IP 與 User-Agent。證據報告記的是實際達到的級別，並把 L1 到 L4 的對照整份印出來——L3 多因子（Email ＋ Passkey 裝置驗證、Email ＋ 與指定信箱一致的 Google／Microsoft 帳號登入，或 Email ＋ 發送至發起人指定門號的簡訊驗證碼；屬進階選配，發起組織需個別授權）達成時如實記載，L4 憑證式數位簽章（經 TWID 行動身分識別後由 TWCA 簽發憑證、對合約 PDF 完成數位簽章；同屬進階選配）達成時亦如實記載——整張表印出來，就是為了不讓任何一級被讀成天花板。

這不證明什麼： L2 證明的是簽署當下對方能收取那個指定信箱的郵件，不是自然人身分：信箱可能多人共用、設有轉寄或由他人代收。我們不寫「已驗證身分」，系統也沒有任何證件、自然人憑證或工商憑證的查核。

同意聲明含「本人確認上開簽署人姓名、職稱及公司資料正確，並確認本人有權代表上開簽約方簽署本合約」，送出當下的全文原樣快照進簽署紀錄。證據報告另外把「發起人預期」與「簽署人聲明」逐欄並列，共五欄：公司名稱、統一編號、簽署人姓名、職稱、Email 網域，每欄標成相符／不相符／僅聲明，無預期可比／僅預期，未經聲明／雙方均未提供。不相符不會擋下簽署，兩份都按原樣保存、不做調和——差異本身就是一項事實。

這不證明什麼： 比對只做全形半形、大小寫、空白與公司法律形式（「股份有限公司」與「(股)」）的正規化，沒有模糊比對。第三欄「政府公開資料」是簽署當時向經濟部商業司公司登記資料查得的快照，只能證明登記內容當時如此——報告寫的是「公司登記比對：相符」，不是「代表人已驗證」，因為登記資料不能證明螢幕前的人就是那個自然人，也不認定他是否真的有權代表；勾選同意聲明不會憑空創造代理權，留下的是他當時對自身權限的明確陳述。

簽署交易完成後，系統在背景自動寄出完成通知，合約 PDF 與證據報告 PDF 是真正的 MIME 附件，不是下載連結——副本落在雙方各自的信箱裡，不依賴本平台繼續存在。發起人與簽署人各收各的一封。信中直接印出 contract.pdf 與 evidence-report.pdf 的 SHA-256，以及定稿內容指紋，並註明這三個值涵蓋的不是同一件事：前兩個是附件的位元組雜湊，最後一個才是時戳簽發的對象。

這不證明什麼： 附件受寄送服務單封 10MB 上限，超過時會降級，並在寄送狀態上如實標示「未附上」哪一份；若 PDF 渲染失敗則整封信不寄——我們不寄一封宣稱附了文件卻沒附的信。

合約 PDF 一律由伺服器端 headless Chromium 渲染，版本釘死在 Chrome for Testing 152.0.7977.54：色彩描述檔釘在 sRGB、關閉字型 hinting 與 LCD 次像素平滑、時區釘在 Asia/Taipei、viewport 與 device scale factor 固定。輸出後再把 PDF 裡唯一會逐次變動的 /CreationDate 與 /ModDate 正規化成固定值；萬一 trailer 出現 /ID，渲染直接失敗，而不是默默產生一份日後對不起來的檔案。合約定稿後內容不再變動，因此同一份合約每次渲染都得到同一組位元組。

這不證明什麼： 這個保證只涵蓋合約 PDF。證據報告會隨後續事件繼續增長——每成功寄出一次就多一筆寄送紀錄——所以兩份證據報告 PDF 未必逐位元組相同。我們不宣稱系統裡封存了一份 PDF 檔案：持久保存的是合約內容與它的指紋，PDF 是按需重新渲染的。

騎縫章把公司大小章等寬切成 N 片，每頁右緣各印一片、垂直位置固定；頁面依序排好時印章才完整，抽掉一頁、換掉一頁或頁序被動過，切片就對不起來。需先在「設定 → 組織設定」上傳公司大小章才能啟用，2 頁以上才會蓋，可逐份開關或設成新合約的預設，定稿後鎖定。

這不證明什麼： 這是紙本上的視覺辨識，不是密碼學保護：印章圖可以被複製，整份重印也能重新對齊。而且騎縫章設定不在定稿指紋的涵蓋範圍內——防竄改靠的是內容雜湊、RFC 3161 時戳與稽核雜湊鏈，不是這顆章。

每日彙總把當天完成的所有簽署收攏成一棵 Merkle 樹，對外送出的只有樹根（送往哪些地方見上方「時戳公司也是你們自己挑的」一則）。證據報告印出你那一筆的葉節點原文（逐字）、葉節點雜湊、在當日的位置（第 N 片，當日共 M 片），以及 inclusion proof 的每一步：兄弟節點雜湊完整印出，方向標成「左（在前）」或「右（在後）」。葉節點算 SHA-256(0x00 || 原文)、內部節點算 SHA-256(0x01 || 兄弟 || 目前值)，以 domain separation 區隔兩者，你可以照著自己重算回樹根。證明是每次即時重算而不是存起來的，避免存下來的證明日後與實際資料對不上。

這不證明什麼： 彙總本身不證明我們沒有重建整棵樹，產生效力的仍然是樹根被送到的那些第三方。當日的樹要等該業務日結束後才建立，因此當天完成的簽署會先顯示為尚未納入。

定稿當下對該版本內容原文（UTF-8）計算 SHA-256，指紋印在證據報告與 A4 文件末頁的「數位認證指紋」區塊。同一個指紋送交第三方時戳機構，取回 RFC 3161 時戳權杖；.tsr 檔可從系統下載，用 openssl ts -verify 獨立驗算——不需要我們的系統，也不需要相信我們。證據報告會把時戳涵蓋的雜湊與目前定稿指紋比對，標示為「時戳一致：涵蓋目前定稿指紋」或「時戳不符：非目前定稿指紋」。

這不證明什麼： 時戳證明的是那個雜湊值在簽發時點之前就已存在，不證明內容為真、不證明簽署人是誰，也不等同公證。

稽核軌跡是 append-only 雜湊鏈，每筆事件的雜湊都含前一筆的雜湊，因此「只改一筆而不重算後續」會立即被偵測。但能重算整條鏈的一方——也就是我們——重算後的鏈驗證起來完全正常。所以鏈頭會送第三方時戳機構簽發 RFC 3161 時戳，那一刻之前的事件我們就改不動了。證據報告逐段標示「已錨定」或「未錨定」，並且白紙黑字寫著：未錨定僅代表本平台自身紀錄一致，尚無第三方佐證。資料庫層還有兩道：已寫入的簽名列由 append-only 觸發器擋下 UPDATE，簽署證據相關的外鍵一律 ON DELETE RESTRICT——合約或邀請一旦帶有簽署證據，資料庫就拒絕刪除它。

這不證明什麼： 雜湊鏈本身不構成對抗本平台的效力，未錨定的區段只通過我們自己的一致性檢查。這句話不是行銷話術，它就印在證據報告上。

每天結束後，當日所有簽署彙總成一棵 Merkle 樹。葉節點為 SHA-256(0x00 ‖ 正規化原文)，內部節點為 SHA-256(0x01 ‖ 左 ‖ 右)，前綴用來區分兩者，避免以葉節點偽造內部節點；奇數節點直接升位而非複製自己。葉節點原文採長度前綴格式（名稱=位元組長度:值），欄位順序固定為 v, signature_id, request_id, contract_id, chain_head_hash, chain_head_seq, signed_at——公開於證據報告，可自行重算。樹根連同一段自我描述的敘述（含日期、格式版本、樹根、當日筆數）送往三處：RFC 3161 時戳（多家機構備援，並記錄實際簽發的那一家）、Sigstore Rekor 公開透明日誌、OpenTimestamps（最終寫入 Bitcoin 交易）。Rekor 的查詢是以該敘述的 SHA-256 反查索引，因此第三方不需要接受我們對「哪一筆是你的」的說法；OpenTimestamps 收據一經 Bitcoin 確認，驗證只需要 Bitcoin——不需要我們、不需要 Sigstore，也不需要 OpenTimestamps 自己還在。證據報告將三者分開列出各自狀態，包含 OTS 尚未確認的等待狀態與確認後的 Bitcoin 區塊高度。報告上印出的是你那一天的實際數值——樹根、Rekor 的 logIndex、Bitcoin 區塊高度——不是說明文字裡的範例；每一個都能拿去對應的公開系統查，而那些系統與本平台沒有關係。

這不證明什麼： 送出去的是一個 64 字元的雜湊值與日期，合約內容、姓名、金額都不在裡面——這既是隱私上的必要，也表示它不證明內容為何。彙總以「天」為單位且當日結束後才建樹，所以今天簽的要等今天過完；稽核雜湊鏈之前的舊簽署永遠不會被涵蓋，報告會據實寫出。OpenTimestamps 顯示「已送出，尚未確認」時，該收據還不構成可獨立驗證的時間證明，通常需數小時——期間即使該摘要其實已被寫進某筆 Bitcoin 交易，報告仍不會顯示區塊高度，因為在收據補完之前，「你的摘要在那筆交易底下」是 calendar 的說法而不是可驗證的路徑。我們選擇讓報告晚一點說，而不是早一點借別人的話說。最後：沒有任何法條因為一份資料的雜湊出現在 Bitcoin 上而提高它的地位，提高的是你的舉證能力。

收件地址由發起人填寫，簽署頁只做遮蔽顯示，對方改不了。6 位數驗證碼 10 分鐘有效、連錯 5 次即作廢、60 秒才能重寄、整份邀請最多寄 5 次。簽署歷程逐筆記下寄出邀請、驗證通過、首次開啟合約、勾選同意聲明、完成簽署的時間、來源 IP 與 User-Agent。證據報告記的是實際達到的級別，並把 L1 到 L4 的對照整份印出來——L3 多因子（Email ＋ Passkey 裝置驗證、Email ＋ 與指定信箱一致的 Google／Microsoft 帳號登入，或 Email ＋ 發送至發起人指定門號的簡訊驗證碼；屬進階選配，發起組織需個別授權）達成時如實記載，L4 憑證式數位簽章（經 TWID 行動身分識別後由 TWCA 簽發憑證、對合約 PDF 完成數位簽章；同屬進階選配）達成時亦如實記載——整張表印出來，就是為了不讓任何一級被讀成天花板。

這不證明什麼： L2 證明的是簽署當下對方能收取那個指定信箱的郵件，不是自然人身分：信箱可能多人共用、設有轉寄或由他人代收。我們不寫「已驗證身分」，系統也沒有任何證件、自然人憑證或工商憑證的查核。

同意聲明含「本人確認上開簽署人姓名、職稱及公司資料正確，並確認本人有權代表上開簽約方簽署本合約」，送出當下的全文原樣快照進簽署紀錄。證據報告另外把「發起人預期」與「簽署人聲明」逐欄並列，共五欄：公司名稱、統一編號、簽署人姓名、職稱、Email 網域，每欄標成相符／不相符／僅聲明，無預期可比／僅預期，未經聲明／雙方均未提供。不相符不會擋下簽署，兩份都按原樣保存、不做調和——差異本身就是一項事實。

這不證明什麼： 比對只做全形半形、大小寫、空白與公司法律形式（「股份有限公司」與「(股)」）的正規化，沒有模糊比對。第三欄「政府公開資料」是簽署當時向經濟部商業司公司登記資料查得的快照，只能證明登記內容當時如此——報告寫的是「公司登記比對：相符」，不是「代表人已驗證」，因為登記資料不能證明螢幕前的人就是那個自然人，也不認定他是否真的有權代表；勾選同意聲明不會憑空創造代理權，留下的是他當時對自身權限的明確陳述。

簽署交易完成後，系統在背景自動寄出完成通知，合約 PDF 與證據報告 PDF 是真正的 MIME 附件，不是下載連結——副本落在雙方各自的信箱裡，不依賴本平台繼續存在。發起人與簽署人各收各的一封。信中直接印出 contract.pdf 與 evidence-report.pdf 的 SHA-256，以及定稿內容指紋，並註明這三個值涵蓋的不是同一件事：前兩個是附件的位元組雜湊，最後一個才是時戳簽發的對象。

這不證明什麼： 附件受寄送服務單封 10MB 上限，超過時會降級，並在寄送狀態上如實標示「未附上」哪一份；若 PDF 渲染失敗則整封信不寄——我們不寄一封宣稱附了文件卻沒附的信。

合約 PDF 一律由伺服器端 headless Chromium 渲染，版本釘死在 Chrome for Testing 152.0.7977.54：色彩描述檔釘在 sRGB、關閉字型 hinting 與 LCD 次像素平滑、時區釘在 Asia/Taipei、viewport 與 device scale factor 固定。輸出後再把 PDF 裡唯一會逐次變動的 /CreationDate 與 /ModDate 正規化成固定值；萬一 trailer 出現 /ID，渲染直接失敗，而不是默默產生一份日後對不起來的檔案。合約定稿後內容不再變動，因此同一份合約每次渲染都得到同一組位元組。

這不證明什麼： 這個保證只涵蓋合約 PDF。證據報告會隨後續事件繼續增長——每成功寄出一次就多一筆寄送紀錄——所以兩份證據報告 PDF 未必逐位元組相同。我們不宣稱系統裡封存了一份 PDF 檔案：持久保存的是合約內容與它的指紋，PDF 是按需重新渲染的。

騎縫章把公司大小章等寬切成 N 片，每頁右緣各印一片、垂直位置固定；頁面依序排好時印章才完整，抽掉一頁、換掉一頁或頁序被動過，切片就對不起來。需先在「設定 → 組織設定」上傳公司大小章才能啟用，2 頁以上才會蓋，可逐份開關或設成新合約的預設，定稿後鎖定。

這不證明什麼： 這是紙本上的視覺辨識，不是密碼學保護：印章圖可以被複製，整份重印也能重新對齊。而且騎縫章設定不在定稿指紋的涵蓋範圍內——防竄改靠的是內容雜湊、RFC 3161 時戳與稽核雜湊鏈，不是這顆章。

每日彙總把當天完成的所有簽署收攏成一棵 Merkle 樹，對外送出的只有樹根（送往哪些地方見上方「時戳公司也是你們自己挑的」一則）。證據報告印出你那一筆的葉節點原文（逐字）、葉節點雜湊、在當日的位置（第 N 片，當日共 M 片），以及 inclusion proof 的每一步：兄弟節點雜湊完整印出，方向標成「左（在前）」或「右（在後）」。葉節點算 SHA-256(0x00 || 原文)、內部節點算 SHA-256(0x01 || 兄弟 || 目前值)，以 domain separation 區隔兩者，你可以照著自己重算回樹根。證明是每次即時重算而不是存起來的，避免存下來的證明日後與實際資料對不上。

這不證明什麼： 彙總本身不證明我們沒有重建整棵樹，產生效力的仍然是樹根被送到的那些第三方。當日的樹要等該業務日結束後才建立，因此當天完成的簽署會先顯示為尚未納入。