一個應用的轉賬按鈕看起來可能毫無變化,但背後調用的跨鏈合約卻即將收緊額度。Circle 公布的時間表顯示,CCTP V1 的舊版本計劃從10月31日起降低销毁限額,到12月1日暫停該合約。對於仍將USDC 路由到舊版本的應用,遷移已經進入具體的時間窗口。
這份時間表來自 Circle 在8月27日發布的官方說明,目前的遷移文件仍保留相同的安排。今天的新聞價值在於計劃進入實施階段,而非 Circle 刚剛推出一項新協議。截至本次查證,官方資料提供了限額逐漸收緊的路径,沒有披露各鏈今日已經下调到多少,也沒有提供執行後的轉賬量結果。
Circle 將新版稱為 CCTP,舊版則標記為 CCTP V1 Legacy。名字變短容易讓使用者以為只是文檔升級,但工程上卻有實質變化:V2 使用獨立合約,與 V1 整合後不再向下兼容。舊接口能夠正常發起請求,但無法保證在它被廢除之後仍具有轉賬功能。
額度收緊,先影響新轉賬的入口
官方遷移文檔區分了新增活動與已經在進行中的請求。逐步收緊的消息限額會讓新建立的轉賬最終無法發起,從而讓舊版本的轉賬量在完全暫停前降至零。這是一條逐步退出的途徑,應用需要在按鈕背後的路由層識別版本,不能等到最後一次調用失敗才處理。
對於已經在進行中的贖回請求,Circle 表示在退役過程中會繼續提供處理能力,維持高於待處理證明總額的鑄幣額度,以便在舊合約完全停止之前完成處理。這個安排改變了對退役的認識:緊縮新的入口與處理舊請求,是同時進行的兩件事。
開發者因此需要分別管理兩種狀態。一種是尚未進入舊版本的新增請求,應該導向新版本;另一種是已經進入流程的轉賬,需要按照其原有的版本來追蹤結果。如果將這兩種狀態混在一個成功提示中,用戶就難以判斷資金處於哪一階段。這裡的產品責任落在了狀態顯示和路由銜接上,而不仅仅是簡單地替換一個宣傳名稱。
新合約之外,還有報價和等待方式
遷移指南列出了合約地址、調用接口和 API 端點的變化。新版의銷毀入口增加了參數,允許設定目標調用者、最高費用和最低最終性閾值。應用必須使用新的合約定義來組織調用。舊參數會原樣轉發到新地址,無法完成這層遷移。
速度選擇也融入了產品交互中。新版提供了標準和快速轉賬模式,快速轉賬費用會根據來源鏈條的不同而變化,集成方需要將這些費用納入到流程中。用戶所看到的等待時間和報價,應該與其選擇的轉賬方式相對應。界面上的一個“更快”選項,其背後實際上連接着不同的最終性要求和費用約束。
獲取證明的工作流程因此被縮短。舊版本需要從鏈上交易回執中提取消息、計算消息哈希,再進行證明查詢;新版本則允許使用交易哈希來查詢消息端點,一次即可獲得消息、證明和解碼數據。對於運營和客服來說,這有機會減少人工拼接信息的環節;對於開發者而言,則需要更新輪詢和結果解析邏輯。
當資料欄位和狀態接口一起變化時,遷移就不再只是發起交易之前的動作了。應用程式還需要能夠識別新版本返回的訊息,正確關聯來源、目標和接收者。按下按鈕之後,如何告知使用者請求已經提交、證明其是否可用、以及目標端是否已完成,同樣屬於交付過程的一部分。
工具可以代管接口,集成方仍需選擇費用
Circle 也提供通過 App Kits 遷移的途徑。根據官方文檔,這套工具可以管理合約地址、接口和函數調用,自動獲取證明,並通過配置使用快速轉賬等功能。團隊可以選擇直接維護底層調用,也可以將常規連接工作交給工具包處理。
工具包還支持可選的轉賬費用收取。由此,遷移同時涉及商業設計:誰來承擔底層轉賬費用、應用是否會另外收費,以及用戶在確認前會看到怎樣的總成本。技術接入變得更加簡單,但並不會替團隊決定這些價格與體驗問題。
這次退役將一個平時隱藏在錢包和應用程序後面的依賴項推到了前台。USDC 仍然是用戶想要轉移的資產,具體哪一套合約可以處理、哪一種接口可以追蹤、如何選擇速度和費用,都需要應用程序明確安排。Circle 負責控制舊版本的退出節奏,集成方承擔改變路徑和交付狀態的工作,而用戶的選擇則越來越取決於應用程序是否能夠将这些後臺變化清晰地呈現在確認界面上。












