ERC-8214：EVM 區塊鏈上的先買後付（BNPL）標準接口

摘要

此 ERC 提議為 EVM 相容區塊鏈上的「先買後付」（Buy Now Pay Later, BNPL）分期付款訂單建立標準介面。它定義了分期付款電商的狀態機、透過 EIP-712 實現的加密客戶同意機制、用於代幣轉移的可插拔授權策略，以及由營運者管理的收款流程。ERC 依賴於 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；原子轉移，無需額度批准，透過 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 金庫為客戶，貢獻者為商家；透過鏈下強制執行里程碑解鎖。
• 代幣歸屬份額：項目金庫為客戶，接收者為商家；MerkleScheduleAuth 處理非均勻的懸崖（cliff）+ 線性釋放排程。
• 協議費用支付計劃：企業客戶分期支付接入費或上架費。

刻意排除在範疇之外的內容

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

參考實現

參考實現在此處獲取：GitHub - asghaier76/BNPL: BNPL ERC Reference Implementation

期待社群的意見回饋，特別是關於上述設計決策。我將關注此討論串並根據社群輸入更新草案。

        1 則貼文 - 1 位參與者

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