Circleが発表した内容
Circleは9月2日、Cross-Chain Transfer Protocol（CCTP）がネイティブEURCの移転に対応したと発表しました。対象はまずEthereumとBaseです。開発者は資産ごとに別のブリッジを統合する代わりに、Circle発行のUSDCとEURCを同じ本番相互運用基盤で扱えます。
Circleによると、EURCはCCTPの既存のバーン＆ミント方式を使います。送信元チェーンでトークンをバーンし、送信先チェーンでミントするため、各対応ネットワーク上にはラップド表現ではなくネイティブEURCが存在します。既存のUSDC移転フローに変更はないと同社は説明しています。
一つの連携でも、一つのトランザクションではない
APIが統一されても、プロダクト側から見たクロスチェーン移転は分散ワークフローです。送信元のバーン確定、Circleのアテステーション、送信先でのミント、アプリケーション台帳の更新は異なる時点で起こり、それぞれ独立して失敗し得ます。したがって、利用者に見せる「送金」は単一の成功フラグではなく、永続的な状態機械として実装する必要があります。
業務指示には冪等性キーを付与し、送信元トランザクション、メッセージハッシュ、アテステーション状態、送信先トランザクション、最終的な会計結果を分けて保存すべきです。再試行は二重にバーンせず、最後に検証できた状態から再開します。APIのタイムアウトだけでは資産が移動したか判断できないため、照合ではアプリ記録、両チェーン、プロトコルメッセージを突き合わせる必要があります。
資産と経路のポリシーを明示する
USDCとEURCが基盤を共有すれば連携工数は減りますが、資産や経路の誤選択はより現実的な障害になります。ウォレットや決済システムは、利用者が承認した資産、金額、送信元チェーン、送信先チェーン、受取人、コントラクトアドレスを一つのポリシーオブジェクトに固定し、実行直前に検証すべきです。
コントラクトアドレスと対応経路は、モデル出力や自由入力ではなく、変更管理されたバージョン付き設定から取得します。資産別の上限と会計ルールも必要です。ユーロ建てステーブルコインの追加は、ドル建て台帳にトークン記号を一つ増やすだけの変更ではありません。
復旧はアプリケーション側の責任
Circleは、移転は取り消せず、誤ったアドレスへ送った資産を回収できないと明記しています。また、スマートコントラクト、リレー、ブリッジの脆弱性もリスクとして挙げています。プロダクトチームはこれらを設計条件として扱い、送信先アドレスとチェーン文脈を検証し、高額移転にはより強い承認を要求し、停止または一部だけ観測された処理の運用手順を用意すべきです。
Ineezaの見解
EURC対応が重要なのは、CCTPがUSDC専用の経路から複数資産の決済基盤へ変わり始めたためです。連携を再利用できる利点がある一方、設定、アテステーション処理、照合の不具合が及ぼす共通の影響範囲は広がります。適切な抽象化は、汎用的なブリッジ呼び出しではなく、資産固有のポリシーを持つ共通移転エンジンです。各状態遷移をモデル化し、独立した証跡を残し、実行と台帳確定を分離すれば、障害時の資金所在を曖昧にせず再利用性を得られます。