草案 ERC：先買後付 (BNPL) 標準

摘要

本 ERC 提案為 EVM 相容區塊鏈上的「先買後付」（Buy Now Pay Later, BNPL）分期付款訂單定義了一套標準介面。它規範了分期電商的狀態機、透過 EIP-712 實現的加密客戶同意機制、用於代幣轉移的可插拔授權策略，以及由營運者管理的收款流程。此標準依賴於 ERC-20、ERC-165、EIP-712 和 EIP-1271。

問題陳述

電子商務中的 BNPL 是一種主流的消費者支付方式。全球每年有數千億美元流經中心化服務商（例如 Klarna、Afterpay、Affirm），但這些服務商運作不透明、受特定司法管轄區限制，且要求商家必須整合其私有的 API。

就我們所知，目前尚無現有的 ERC 能滿足鏈上商家融資分期電商的特定需求：

具備加密同意的原子化首付款支付。 在結帳時，客戶必須同時授權訂單條款並轉移首付款。現有的代幣授權標準（ERC-20 approve、ERC-2612 permit、Permit2）僅處理支付，但不帶有針對特定訂單的同意證明。這可能導致客戶同意了條款後被商家替換，或者商家在未經客戶真實同意的情況下創建訂單。

首付款與分期款的分離授權。 最佳的用戶體驗（UX）需要在同一筆訂單中使用兩種不同的授權模型。在結帳時，偏好使用基於簽名的授權——客戶只需簽名一次，無需預先進行授權交易。對於後續的分期款，則偏好自動扣款——客戶在結帳後不應再與合約進行互動。目前沒有現有標準能在單一訂單中模擬這種兩階段分離模式。

定義明確且具備鏈下恢復機制的狀態機。 訂單生命週期必須精確規範，以便鏈下後台系統能可靠地根據狀態轉換採取行動。違約恢復（如債務追討、服務終止）屬於平台特定功能，不包含在本標準內。

設計概覽

授權抽象化 (IPaymentAuth)

本標準的核心部分是將支付排程與代幣授權分離。可插拔的 IPaymentAuth 介面負責處理所有代幣轉移，無論代幣如何授權，都能保持訂單狀態機的穩定。本提案考慮了五種規範性的參考實現：

策略	代幣相容性	使用場景
AllowanceAuth	任何 ERC-20	最簡單；長期授權
Permit2Auth	任何 ERC-20 (透過 Permit2)	可作為推薦選項
PermitAuth	僅限 ERC-2612 代幣	無需依賴 Permit2
EIP3009Auth	USDC/EURC (EIP-3009)	適用於 USDC；原子化轉帳，無需 allowance，透過 receiveWithAuthorization 防止搶跑
MerkleScheduleAuth	任何 ERC-20	透過 Merkle 根提交的變動金額分期排程

電子商務 BNPL 的推薦組合是 Permit2Auth（首付款）+ AllowanceAuth（分期款）——實現無 Gas 的簽名結帳，並配合完全自動化的後續收款。針對 USDC，EIP3009Auth + AllowanceAuth 提供了更強的安全性：任何階段都無需 allowance，且具備防搶跑保護。

客戶同意 (OrderAuthorization)

商家在結帳時調用 createOrder。客戶在鏈下簽署一個 EIP-712 OrderAuthorization 結構體——這是一個類型化、人類可讀的訊息，涵蓋了所有訂單條款，包括兩種授權策略的地址。合約會驗證簽名並在同一筆交易中原子化地收取首付款。對 EIP-1271 的支持使其能與智能合約錢包（如 Coinbase Smart Wallet、Safe 等）相容。

OrderAuthorization 類型字串：

OrderAuthorization(address merchant, address token, uint256 totalAmount,
uint8 installments, uint256 downPaymentBps, uint256 installmentPeriod,
uint256 gracePeriod, uint256 lateFeeBps, address downPaymentAuthStrategy,
address installmentAuthStrategy, uint256 nonce, uint256 deadline)

訂單生命週期

定義了五種終端狀態，每種狀態具有不同的鏈下語義：

• Active → Completed：所有分期款已付清。
• Active → Defaulted：寬限期已過且未支付（觸發鏈下恢復）。
• Active → Cancelled：由商家或客戶主動終止。
• Active → Refunded：商家發起的退款導致訂單終止。
• 部分退款時 Active 保持 Active：processRefund 會減少 totalAmount 並重新計算剩餘分期，而不會終止訂單。

營運者管理

商家可以授權營運者（自動化 Keeper、後端基礎設施）來觸發分期款收取。營運者調用 collectInstallment 但絕不會收到資金——所有代幣直接從客戶流向商家。

---

使用場景

本標準主要為電子商務 BNPL 設計，但 IPaymentAuth 的抽象化使其適用於更廣泛的分期支付場景：

• 電子商務 BNPL：結帳時支付首付款，隨後數週/數月內自動收取分期款。
• NFT 分期購買：購買高價值 NFT 並分期支付；市場將 NFT 託管直至 OrderCompleted。
• DeFi 貸款償還：借款人為客戶，借貸協議為商家；MerkleScheduleAuth 處理變動金額的攤銷排程。
• DAO 貢獻者報酬：DAO 金庫為客戶，貢獻者為商家；透過鏈下強制執行里程碑解鎖。
• 代幣歸屬分期 (Token Vesting Tranches)：項目金庫為客戶，接收者為商家；MerkleScheduleAuth 處理非均勻的懸崖期（cliff）加線性排程。
• 協議費用支付計劃：企業客戶分期支付接入費或上架費。

刻意排除在範疇之外的部分

• 違約恢復機制（債務追討、信用報告、抵押品清算）。
• 消費者信貸合規（實質年利率 APR 披露、冷靜期）——實施平台需承擔此責任。
• 定期扣款與訂閱支付。

期待社群的意見回饋，特別是針對上述設計決策。我將關注此討論串並根據社群輸入更新草案。此外，ERC 草案和參考實現將很快連結到此討論串。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/draft-erc-buy-now-pay-later-bnpl-standard/28116)