From 43d3c32e2ec20eeebc43a18db4111d4ad9a2470e Mon Sep 17 00:00:00 2001 From: aggre Date: Fri, 21 Aug 2026 07:15:04 +0000 Subject: [PATCH 1/2] content: fix reconciliation description from hash comparison to proof issuance (JA/EN) --- stablecoin-payment-reconciliation.en.md | 14 ++++++-------- stablecoin-payment-reconciliation.ja.md | 14 ++++++-------- 2 files changed, 12 insertions(+), 16 deletions(-) diff --git a/stablecoin-payment-reconciliation.en.md b/stablecoin-payment-reconciliation.en.md index af2f7fb..9cbe33d 100644 --- a/stablecoin-payment-reconciliation.en.md +++ b/stablecoin-payment-reconciliation.en.md @@ -61,31 +61,29 @@ A payment leaves a record in three places. Lemma confirms automatically that all three point at the same payment.
- On the left, the settlement record and the payer's ledger; on the right, the payee's ledger. All three compute a hash from their own record and compare in the center. The contents are never shown. A match clears automatically; a mismatch identifies the field. + On the left, the settlement record and the payer's ledger; on the right, the payee's ledger. All three issue a proof from their own record and compare in the center. The contents are never shown. A match clears automatically; a mismatch identifies the field.
Figure 1 — Reconciling your record, your counterparty's, and the on-chain settlement without disclosure
-From the payee, the amount, the invoice number and the payment date, each side computes a hash (a fingerprint). A hash is a fixed-length value computed from the original contents; change one character and the value is different. - -Compare the value you computed with the value your counterparty computed, and if they match, both records point at the same contents. You learn whether they agree without ever touching what is inside the counterparty's books. +From the payee, the amount, the invoice number and the payment date, each side issues a proof. A proof shows by computation that "these values are in my record" — without handing over the contents themselves. When both proofs point at the same values, both records point at the same payment. You learn whether they agree without ever touching what is inside the counterparty's books. ### A match clears on the spot A payment that matches needs no review by anyone. -Where there is a discrepancy, you also learn which field it is in. The hash of the amount matches and only the invoice number differs — the invoice number is the only thing to look at. One query to the counterparty is enough. +Where there is a discrepancy, you also learn which field it is in. The amount matches and only the invoice number differs — the invoice number is the only thing to look at. One query to the counterparty is enough. -Hashes and reconciliation are both terms your IT department already speaks. They are who to start the conversation with internally, and the call about where in the current accounting system to add one step is theirs to make. +Proofs and reconciliation are both terms your IT department already speaks. They are who to start the conversation with internally, and the call about where in the current accounting system to add one step is theirs to make. ## From the moment a payment is approved to the moment the item clears Rather than assembling everything afterwards, you register one item at a time, as each event happens. -**1. The payment is approved.** Payee, amount, invoice number. Compute a hash from the contents as approved and register it. One step added to the end of the existing approval flow is all it takes. +**1. The payment is approved.** Payee, amount, invoice number. Issue a proof from the contents as approved and register it. One step added to the end of the existing approval flow is all it takes. **2. The transfer goes out.** Link the on-chain transaction to step 1. Transfers between operators also trigger travel-rule notifications, and those can ride the same route. -**3. The counterparty recognizes it.** When the receiving side enters it into their own books, they compute a hash from the same fields. +**3. The counterparty recognizes it.** When the receiving side enters it into their own books, they issue a proof from the same fields. **4. Reconcile.** Compare 1 and 3, and if they match, the item clears. diff --git a/stablecoin-payment-reconciliation.ja.md b/stablecoin-payment-reconciliation.ja.md index 82d7ec2..da8dc26 100644 --- a/stablecoin-payment-reconciliation.ja.md +++ b/stablecoin-payment-reconciliation.ja.md @@ -61,31 +61,29 @@ Lemma の照合は、互いのデータを開示せずに一致だけを確か この3つが同じ支払いを指していることを、Lemma は自動で確かめます。
- 左に決済記録と支払う側の会計、右に受け取る側の会計。3者ともそれぞれの記録からハッシュ値を計算し、中央で照合する。中身は見せない。一致すれば自動で完了、不一致なら項目を特定する + 左に決済記録と支払う側の会計、右に受け取る側の会計。3者ともそれぞれの記録から証明を発行し、中央で照合する。中身は見せない。一致すれば自動で完了、不一致なら項目を特定する
図1 自社・相手・オンチェーンの記録を、開示せずに照合
-支払先・金額・請求番号・支払日から、それぞれの側でハッシュ値（指紋）を計算します。ハッシュ値は元の内容から計算される固定長の値で、内容が1文字でも違えば別の値になります。 - -自社が計算した値と取引先が計算した値を照合して、一致すれば両者の記録は同じ内容を指しています。取引先の帳簿の中身には触れないまま、合っているかどうかだけが分かります。 +支払先・金額・請求番号・支払日から、それぞれの側で証明を発行します。証明は「自分の記録にこれらの値が入っている」ことを計算で示すもので、中身そのものは渡しません。両者の証明が同じ値を指していれば、両者の記録は同じ支払いを指しています。取引先の帳簿の中身には触れないまま、合っているかどうかだけが分かります。 ### 一致すればその場で完了 一致した支払いは、担当者が確認する必要はありません。 -ずれがあれば、どの項目がずれているかまで分かります。金額のハッシュは一致していて請求番号だけが違う——見るべきは請求番号だけです。取引先への問い合わせは1回で済みます。 +ずれがあれば、どの項目がずれているかまで分かります。金額は一致していて請求番号だけが違う——見るべきは請求番号だけです。取引先への問い合わせは1回で済みます。 -ハッシュ値も照合も、情報システム部門には通じる言葉です。社内で話を始めるなら相手は彼らになりますし、いまの会計システムのどこに1段足すかという判断も、彼らが持っています。 +証明も照合も、情報システム部門には通じる言葉です。社内で話を始めるなら相手は彼らになりますし、いまの会計システムのどこに1段足すかという判断も、彼らが持っています。 ## 支払いが確定してから、消込が落ちるまで まとめて後から作るのではなく、出来事が起きるたびに1件ずつ登録していきます。 -**1. 支払いが確定する。** 支払先、金額、請求番号。承認が下りた時点の内容からハッシュ値を計算して登録します。既存の承認フローの最後に1段足すだけで済みます。 +**1. 支払いが確定する。** 支払先、金額、請求番号。承認が下りた時点の内容から証明を発行して登録します。既存の承認フローの最後に1段足すだけで済みます。 **2. 送金する。** オンチェーンのトランザクションを 1 と紐づけます。事業者間の移転にはトラベルルールにもとづく通知も発生しますが、これも同じ経路に載せられます。 -**3. 相手が計上する。** 受け取った側が自社の会計に入れた時点で、同じ項目からハッシュ値を計算します。 +**3. 相手が計上する。** 受け取った側が自社の会計に入れた時点で、同じ項目から証明を発行します。 **4. 照合する。** 1 と 3 を突き合わせて、一致すれば消込は完了です。 From 16c6a2d8541731ec373091c275a0f250a9e1c6e1 Mon Sep 17 00:00:00 2001 From: aggre Date: Fri, 21 Aug 2026 07:24:19 +0000 Subject: [PATCH 2/2] =?UTF-8?q?content:=20revert=20'proof'=20wording=20bac?= =?UTF-8?q?k=20to=20'hash'=20=E2=80=94=20Lemma=20is=20the=20verifier,=20no?= =?UTF-8?q?t=20the=20two=20parties?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Aggre指摘: 「証明」はIS部門に通じない。ハッシュは残しつつ、 「両者がハッシュを計算して比較する」→「Lemmaが中身を見せずに照合する」 に修正。技術的に正確で、読み手にも伝わる記述に。 --- stablecoin-payment-reconciliation.en.md | 12 ++++++------ stablecoin-payment-reconciliation.ja.md | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/stablecoin-payment-reconciliation.en.md b/stablecoin-payment-reconciliation.en.md index 9cbe33d..fee7ffc 100644 --- a/stablecoin-payment-reconciliation.en.md +++ b/stablecoin-payment-reconciliation.en.md @@ -61,29 +61,29 @@ A payment leaves a record in three places. Lemma confirms automatically that all three point at the same payment.
- On the left, the settlement record and the payer's ledger; on the right, the payee's ledger. All three issue a proof from their own record and compare in the center. The contents are never shown. A match clears automatically; a mismatch identifies the field. + On the left, the settlement record and the payer's ledger; on the right, the payee's ledger. All three create a hash from their own record; Lemma checks them against each other without showing the contents. A match clears automatically; a mismatch identifies the field.
Figure 1 — Reconciling your record, your counterparty's, and the on-chain settlement without disclosure
-From the payee, the amount, the invoice number and the payment date, each side issues a proof. A proof shows by computation that "these values are in my record" — without handing over the contents themselves. When both proofs point at the same values, both records point at the same payment. You learn whether they agree without ever touching what is inside the counterparty's books. +From the payee, the amount, the invoice number and the payment date, each side computes a hash (a fingerprint). Lemma automatically checks whether both records point at the same payment — without either side showing the contents. You learn whether they agree without ever touching what is inside the counterparty's books. ### A match clears on the spot A payment that matches needs no review by anyone. -Where there is a discrepancy, you also learn which field it is in. The amount matches and only the invoice number differs — the invoice number is the only thing to look at. One query to the counterparty is enough. +Where there is a discrepancy, you also learn which field it is in. The hash of the amount matches and only the invoice number differs — the invoice number is the only thing to look at. One query to the counterparty is enough. -Proofs and reconciliation are both terms your IT department already speaks. They are who to start the conversation with internally, and the call about where in the current accounting system to add one step is theirs to make. +Hashes and reconciliation are both terms your IT department already speaks. They are who to start the conversation with internally, and the call about where in the current accounting system to add one step is theirs to make. ## From the moment a payment is approved to the moment the item clears Rather than assembling everything afterwards, you register one item at a time, as each event happens. -**1. The payment is approved.** Payee, amount, invoice number. Issue a proof from the contents as approved and register it. One step added to the end of the existing approval flow is all it takes. +**1. The payment is approved.** Payee, amount, invoice number. Compute a hash from the contents as approved and register it. One step added to the end of the existing approval flow is all it takes. **2. The transfer goes out.** Link the on-chain transaction to step 1. Transfers between operators also trigger travel-rule notifications, and those can ride the same route. -**3. The counterparty recognizes it.** When the receiving side enters it into their own books, they issue a proof from the same fields. +**3. The counterparty recognizes it.** When the receiving side enters it into their own books, they compute a hash from the same fields. **4. Reconcile.** Compare 1 and 3, and if they match, the item clears. diff --git a/stablecoin-payment-reconciliation.ja.md b/stablecoin-payment-reconciliation.ja.md index da8dc26..43e269b 100644 --- a/stablecoin-payment-reconciliation.ja.md +++ b/stablecoin-payment-reconciliation.ja.md @@ -61,29 +61,29 @@ Lemma の照合は、互いのデータを開示せずに一致だけを確か この3つが同じ支払いを指していることを、Lemma は自動で確かめます。
- 左に決済記録と支払う側の会計、右に受け取る側の会計。3者ともそれぞれの記録から証明を発行し、中央で照合する。中身は見せない。一致すれば自動で完了、不一致なら項目を特定する + 左に決済記録と支払う側の会計、右に受け取る側の会計。3者ともそれぞれの記録からハッシュ値を作成し、Lemmaが中身を見せずに照合する。一致すれば自動で完了、不一致なら項目を特定する
図1 自社・相手・オンチェーンの記録を、開示せずに照合
-支払先・金額・請求番号・支払日から、それぞれの側で証明を発行します。証明は「自分の記録にこれらの値が入っている」ことを計算で示すもので、中身そのものは渡しません。両者の証明が同じ値を指していれば、両者の記録は同じ支払いを指しています。取引先の帳簿の中身には触れないまま、合っているかどうかだけが分かります。 +支払先・金額・請求番号・支払日から、それぞれの側でハッシュ値（指紋）を作成します。Lemma は中身を見せずに、両側の記録が同じ支払いを指しているかどうかを自動で確かめます。取引先の帳簿の中身には触れないまま、合っているかどうかだけが分かります。 ### 一致すればその場で完了 一致した支払いは、担当者が確認する必要はありません。 -ずれがあれば、どの項目がずれているかまで分かります。金額は一致していて請求番号だけが違う——見るべきは請求番号だけです。取引先への問い合わせは1回で済みます。 +ずれがあれば、どの項目がずれているかまで分かります。金額のハッシュは一致していて請求番号だけが違う——見るべきは請求番号だけです。取引先への問い合わせは1回で済みます。 -証明も照合も、情報システム部門には通じる言葉です。社内で話を始めるなら相手は彼らになりますし、いまの会計システムのどこに1段足すかという判断も、彼らが持っています。 +ハッシュ値も照合も、情報システム部門には通じる言葉です。社内で話を始めるなら相手は彼らになりますし、いまの会計システムのどこに1段足すかという判断も、彼らが持っています。 ## 支払いが確定してから、消込が落ちるまで まとめて後から作るのではなく、出来事が起きるたびに1件ずつ登録していきます。 -**1. 支払いが確定する。** 支払先、金額、請求番号。承認が下りた時点の内容から証明を発行して登録します。既存の承認フローの最後に1段足すだけで済みます。 +**1. 支払いが確定する。** 支払先、金額、請求番号。承認が下りた時点の内容からハッシュを作成して登録します。既存の承認フローの最後に1段足すだけで済みます。 **2. 送金する。** オンチェーンのトランザクションを 1 と紐づけます。事業者間の移転にはトラベルルールにもとづく通知も発生しますが、これも同じ経路に載せられます。 -**3. 相手が計上する。** 受け取った側が自社の会計に入れた時点で、同じ項目から証明を発行します。 +**3. 相手が計上する。** 受け取った側が自社の会計に入れた時点で、同じ項目からハッシュを作成します。 **4. 照合する。** 1 と 3 を突き合わせて、一致すれば消込は完了です。