From 14a14b1e4ef265949adb346f76eba35f92d52a4f Mon Sep 17 00:00:00 2001 From: roy328line Date: Mon, 25 May 2026 11:32:52 +0800 Subject: [PATCH] Add 2026-05-25 daily check-in: Settlement & Escrow Added detailed notes on Settlement & Escrow concepts, including core principles and business process design. --- notes/roy328line.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/notes/roy328line.md b/notes/roy328line.md index e33752bf3..6cee1f879 100644 --- a/notes/roy328line.md +++ b/notes/roy328line.md @@ -15,6 +15,37 @@ AI x Web3 School ## Notes +# 2026-05-25 + +今日學習：深讀 Settlement & Escrow 模組 + +GitHub 筆記：https://github.com/roy328line/ai-web3-school-cohort-0/blob/main/daily/2026-05-25.md + +## 核心整理 + +**Settlement & Escrow** 解決的是 Agent 經濟裡「錢什麼時候釋放、服務怎麼算完成、失敗怎麼退款、爭議怎麼處理」，把支付從一次轉帳變成完整交易流程。 + +**第一性原理**：自動化交易必須有明確完成條件，否則支付就無法安全自動化。Escrow 設計首先要定義狀態機，而不是先寫付款代碼。 + +**Escrow**：鎖定資金直到交付條件滿足後釋放，最小狀態機：Created → Funded → Delivered → Accepted → Released（或 Refunded / Disputed）。好的 escrow 先定義業務流程，再定義資金流。 + +**Receipt**：不只是「已付款」，應同時服務人和機器：記錄任務 ID、交易 hash、驗收狀態，並成為 reputation 的輸入。 + +**Delivery Proof**：服務方交付的可驗證證明（文件 hash、API 日誌、模型輸出簽名等），必須能和原始任務對應，避免「結果存在但不可驗證」。 + +**Acceptance**：驗收可自動也可人工，高價值任務建議「AI 初審 + challenge window + 人工復核」組合。 + +**Refund**：退款規則必須在任務開始前寫清楚，並考慮部分交付的按比例退款。 + +**Dispute**：爭議記錄是聲譽系統的重要輸入，設計需回答：誰能發起、成本多少、誰有裁決權、是否可申訴。 + +**ERC-8183**：Agentic Commerce 草案標準，把 Agent 交易從「轉帳」提升到「狀態轉換」維度，與 ERC-8004 互補（ERC-8004 偏身份聲譽，ERC-8183 偏任務支付交付）。 + +## 核心發想 + +Settlement & Escrow 的本質不是「鎖錢」，而是「把整個業務流程狀態機化」。Builder 機會：設計「狀態透明、proof 可驗證、dispute 有成本但可處理」的 Agentic Escrow 系統，讓 AI Agent 之間的委托和交易真正可信任。 + + # 2026-05-18 今日學習：深讀 AI x Web3 School Handbook 模組 A（LLM / Prompt / Context / Agent）+ 模組 B（Wallet / Smart Contract / Account Abstraction）