拟约、议约、定稿，
然后留下 站得住脚的证据

定稿当下对该版本内容原文（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 区隔两者，你可以照着自己重算回树根。证明是每次实时重算而不是存起来的，避免存下来的证明日后与实际数据对不上。

这不证明什么： 汇总本身不证明我们没有重建整棵树，产生效力的仍然是树根被送到的那些第三方。当日的树要等该业务日结束后才建立，因此当天完成的签署会先显示为尚未纳入。