はじめに
ステーブルコイン決済を実装するとき、「この実装は法的に問題ないのか」と不安になる方は少なくないと思います。
資金決済法をはじめとする関連法令や、決済スキーム上の責任範囲など、技術とは別のレイヤーでの困難性が付き纏います。
もっとも、実装上の論点も単純ではなく、単にステーブルコインを送れるだけでは、実用的な決済UXにはなりません。
ユーザーに事前にネイティブトークンを求める設計は摩擦が大きく、実用的な決済にはガスレス設計がほぼ必須になります。
さらに、ガスレス技術にはEIP-2612、EIP-3009、ERC-4337、EIP-7702など複数の方式があり、それぞれ前提・対応範囲・責任分界が異なります。
ブロックチェーン技術によって、既往の決済スキームに当てはめにくいグレーゾーンが生じているのも事実です。
本稿では、白黒の境界を引くことはしませんが、その技術的側面とユーザー意思の両面からグレーゾーンの濃淡を整理してみたいと思います。
ガスレスとは何か
さて、ガスレスと言っても、ブロックチェーンへの書込みにガスを支払わなくてはならない事実に変わりはありません。
実際には、事業者側[1]が支払うことになります。
このあたりは、サーバーレスと言いつつサーバー自体は存在するという構図によく似ています。
では、ガスレスはどのようにしてガス支払いをユーザーから引き剥がしているのでしょうか？
共通しているのは、ユーザーがトランザクションを直接送らず、その代わりに署名済みの実行指示を用意する点です。
その実行指示を事業者側のシステムがオンチェーンに持ち込み、コントラクト側が、その署名や権限で実行してよいかを検証します。
つまり、署名検証や実行権限管理を、プロトコルレイヤーからコントラクトレイヤーへ持ち上げることで実現されています。したがって、ガスレスは費用負担の委任という狭い概念ではなく、技術的には実行そのものの委任を伴う概念であると言えます。
もちろん、モチベーションの源泉の大きな部分として、ユーザーがネイティブトークンを持たずとも支払いできるようにしたいというのはあったでしょう。
しかし、その実現方式としての本質は、ユーザー本人ではない誰かがオンチェーン実行を担うことであり、その実行権限をどう設計するかは非常に重要な論点となります。
権限制御の柔軟化による新たな論点
ガスレス実現のために署名検証や権限制御がコントラクトレイヤーへ移行したことで、権限制御は格段に柔軟になりました。
その反面、「誰が秘密鍵を持つか」という単一軸だけでは整理しづらくなります。
たとえば、アカウントの秘密鍵を持っていなくても、後述のallowanceやSession Keyを通じて、ユーザー資産を一定範囲で動かせる場合があります。
逆に、事業者側がオンチェーン実行を中継していても、認可が特定の支払い内容に閉じていれば、事業者側に残る裁量は小さくなります。
つまり、見るべきなのは秘密鍵の所在だけではありません。
ユーザーが何を認可し、その結果として誰がどこまで資産操作の裁量を持つのかです。
冒頭で述べた通り、本記事では法的な結論は出しません。
到底断言できる話ではありませんし、資金決済法、銀行法、犯収法その他の該当性は、スキーム、契約関係、資金の流れ、受取人、利用者属性、国内外性、運用実態によって変わります。
しかし、採用する技術方式によって生じる論点を提示し、その濃淡の方向性を整理することはできるでしょう。
「ガスレス決済」という単語で捨象されている論点を整理し、各技術レイヤーで何を委任し、何を委任していないのかを見ていきましょう。
ガスレス方式の整理
ガスレスの実現手段は、大きく2つに分けられます。
①特定のコントラクト上のガスレス関数
1つは、特定のコントラクトが署名ベースの実行機能を持つパターンです。
EIP-2612のpermitや、EIP-3009のtransferWithAuthorizationがそれにあたります。
この方式では、トークンコントラクト自体が署名を検証し、その結果としてallowanceを作ったり、送金を実行したりします。
特定のコントラクトに紐づく実装のため、対応しているトークンやメソッドは限られます。
②Account Abstraction
もう1つは、アカウント側に署名検証や権限管理を持たせるパターンです。
ERC-4337、Session Key、EIP-7702などのAA（Account Abstraction）文脈はこちらに入ります。
この方式では、トークン側がガスレス関数を実装している必要はありません。
アカウント側が「この操作は実行してよい」と判断できれば、任意のコントラクト呼び出しに対してガスレス実行を組み立てることができます。
この分類はグレーゾーンを論じるうえで重要でしょう。
特定コントラクト上のメソッドなのか。それとも、アカウント側の抽象化レイヤーなのか。
この違いによって、実装できる範囲も、対応できるユースケースも変わります。
ただし、この分類だけで十分ということでもありません。
特定コントラクト上のガスレス関数であっても、permitのようにallowanceを作るものと、EIP-3009のように送金内容そのものを固定するものでは、ユーザーが認可している内容が違います。
同じように、AAやSession Keyも、それ自体が特定の決済モデルを意味するわけではありません。
設計次第で、単発支払いにも、継続課金にも、包括的な資産操作権限にもなります。
したがって、ガスレス決済を整理するには、まず「どのレイヤーで署名検証・権限制御をしているか」を見たうえで、「その認可がユーザーの支払い意思にどれだけ近いか」を見る必要があります。
ユーザー意思と認可実態
決済として見たときに重要なのは、ユーザーがどんな支払い意思を持っていて、その意思がオンチェーン上でどのような認可として表現されているかです。
- 「この相手に、この金額を支払う」という認可なのか
- 「事業者側が、一定額までユーザー資産を動かしてよい」という認可なのか
- 「一定期間、一定条件のもとで、複数回の実行を許す」という認可なのか
これらは、すべてガスレス決済と呼べてしまいます。
しかし、ユーザーが渡している権限の性質はかなり違いますし、それらがユーザー意思に反する場合も出てくるでしょう。
単発の支払いに閉じているなら、事業者側に残る裁量は小さく、ユーザー意思との乖離も小さくなります。
一方で、広いallowanceや緩いSession Keyを渡す場合、秘密鍵そのものを預かっていなくても、事業者側が一定範囲でユーザー資産を動かせる状態になります。
支払い意思と認可実態の距離はどこまで許容されるのか。
また、支払い意思との距離が小さく見える場合でも、事業者側に残る操作権限をどこまで大きくしてよいのか。
このあたりが、ガスレス決済のグレーゾーン焦点になります。
EIP-3009：transferWithAuthorization
単発決済の基準点として分かりやすいのは、EIP-3009のtransferWithAuthorizationです。
これはtransferのガスレス版で、以下のような条件（authorization）を指定できます。
from
to
value
validAfter
validBefore
nonce
signature
つまり、誰から、誰へ、いくら送るかが署名時点で固定されます。
relayerは、そのauthorizationをトークンコントラクトに中継できます。
しかし、宛先や金額を変えることはできません。
事業者やrelayerに残る裁量は、基本的には実行タイミング（あるいは実行しないこと）に限られます。
ユーザーが承認しているのは、広い引き出し枠ではなく、特定の受取人に対する特定金額の移転です。
この点で、単発のステーブルコイン決済ではかなり整理しやすい方式です。
もっとも、金額が毎回固定されない継続課金や従量課金で採用するとなると難しくなります[2]。
課金発生のタイミングとユーザー署名のタイミングを揃えるのが難しくなるため、決済UXとしては重くなります。
別の認可モデルの必要性を感じる場面も出てくるでしょう。
EIP-2612：permit
一方で、approveのガスレス版であるEIP-2612のpermitは性質が違います。
owner
spender
value
deadline
nonce
signature
ユーザーはガスを払わずにallowanceを作れます（＝spenderがユーザー残高から動かせる累積上限額を指定できます）。
spenderはその後、transferFromできます（＝実際にユーザー残高から任意の宛先に引き出せます）。
つまり、permitは「支払い」そのものではなく、「支払い枠」を作る操作です。
もちろん、単発購入で、3,000 JPYCの商品に対して3,000 JPYCだけallowanceを作り、即座にtransferFromするなら、実質的には即時決済にかなり近く見えます。
この場合、allowanceは支払い意思を実現するための技術的な経路にすぎない、と説明しやすいでしょう。
しかし、商品代金を大きく超えるallowanceを取れば様子は変わります。
たとえば、1,000 JPYCの商品に対して50,000 JPYCのallowanceを取る場合、事業者やサーバー鍵は、少なくともallowanceの範囲内ではユーザー資産を動かせます。
秘密鍵そのものを預かっているわけではありません。
しかし、一定範囲でユーザー資産を処分できるなら、それは単なる決済実行の補助なのか、より広い資産操作権限なのか、という論点が生じます。
過剰allowanceはどこから決済ではなくなるのか
難しいのは、単なる決済に基づく支払いなのか、より広い資産操作権限なのかがきれいに二分できないことです。
1,000 JPYCの商品に対して1,000 JPYCのallowanceなら、支払いに近い。
では、1,001 JPYCならどうでしょうか。
1,100 JPYCならどうでしょうか。
2,000 JPYCならどうでしょうか。
現金決済では、1000円の商品に対して1万円札を渡し、お釣りを受け取ることがあります。
これに似た発想で、少し過剰なallowanceを作り、実際には必要額だけtransferFromする設計はどう評価すべきでしょうか。
998 JPYCの商品に対して1,000 JPYCのallowanceを作る程度であれば、現金のお釣りに近い説明ができるかもしれません。
しかし、過剰部分が大きくなるほど、その説明は苦しくなります。
さらに、実際に過剰にtransferFromしたうえで差額を返金する設計ならどうでしょうか。
技術的には可能です。
しかし、ユーザーの支払い意思との距離は広がります。
本来1,000 JPYCの商品を買う意思しかなかったユーザーから、一度50,000 JPYCを引き出し、後で49,000 JPYCを返金する。
この構造を、単なる支払い実行と言い切れるでしょうか。
あるいは、ユーザーが自分でpermit: 0に戻せる導線があれば十分なのでしょうか。
ここで問題になるのは、技術仕様だけではありません。
- ユーザーは何を承認したと理解していたのか
- 事業者側にどこまで裁量が残っているのか
- 残ったallowanceを誰が、いつ、どう扱うのか
- 漏洩時に何ができてしまうのか
このあたりが、単なるガスレス方式の違いではなく、決済スキーム上の論点になります。
ERC-4337：Account Abstraction
Account Abstractionでは、この問題がさらに一般化されます。
ERC-4337では、通常のtransactionのかわりにUserOperationを使います。
UserOperation {
sender
nonce
callData
gas fields
paymasterAndData
signature
}
ユーザーはtransactionではなくUserOperationに署名します。
bundlerがそれをEntryPointコントラクトに投げ、Smart AccountはvalidateUserOpで署名や権限を検証します。
このとき、署名検証ロジックはアカウント側にあります。
そのため、何をもって「本人の承認」とみなすかをかなり自由に設計できます。
EOA signatureだけでなく、passkey、multisig、Session Key、独自policyなども選択肢に入ってきます。
EIP-7702
なお、EIP-7702もこの文脈で理解できます。
ERC-4337では、基本的にユーザーごとにSmart Accountをデプロイし、そのSmart Accountが署名検証や権限制御を担います。
一方で、EIP-7702は、EOAのままコントラクトコードを実行ロジックとして使えるようにするプロトコル拡張です。
つまり、ERC-4337でSmart Accountが担っていたようなことを、ユーザーごとにコントラクトウォレットをデプロイせず、EOA上で直接やれるようにする方向の仕組みです。
メリットとしては、ユーザーごとにコントラクトウォレットをデプロイする際の事業者側のガス負担やタイムラグを避けられること、ユーザー側もそれまで使っていたEOAアドレスを変えず、資産移動なしにガスレスの恩恵を受けられることが挙げられます。
ただし、Account Abstractionのエコシステム自体はERC-4337もEIP-7702も共通であり、権限管理という側面では、どちらの方式でも同様の論点となるため、以降は両者をまとめて「AA」と呼ぶことにします。
AAは特定の支払い方式ではありません。
単発支払いに近い認可も作れますし、継続課金に近い認可も作れます。
設計を間違えると、包括的な資産操作権限にもなります。
AAだから安全、AAだから危険、という話ではありません。
結局は、その上でどのようなpermissionを設計しているかです。
Session Key
さて、このSession Keyはグレーゾーンの温床とも言えるでしょう。
というのも、極めて柔軟な権限譲渡が可能な技術であるうえ、ブロックチェーン黎明期のアカウント概念と名目上は異なるパターンであるためです。
既往のパターンに当てはめにくい技術であり、名目上の違いを隠れ蓑にしやすい実態もあるのではないかと思います。
あらためて、Session Keyは、AA文脈でよく使われる認可設計のパターンです。
ブロックチェーン版のIAMのようなもので、root権限を持つメインアカウントが、特定のscope、limit、expiry、revocationを持つ下位権限を発行します。
基本的にAAで用いるコントラクトウォレットは、安全性の観点から、広く利用されている監査済み実装の中から選定することが多くなりますし、Session Keyの実装もその選定に依存します。
とはいえ、多くの実装で以下のようなパラメーターを設計できるようになっています。
- 誰が実行できるか
- どのcontractを呼べるか
- どのfunctionだけ許すか
- recipientは固定か
- 1回上限はいくらか
- 期間累積上限はいくらか
- いつまで有効か
- revokeできるか
決済で使うなら、たとえばJPYCだけ、transferだけ、事業者アドレス宛だけ、月間累積金額に上限あり、有効期限あり、revoke可能、というように縛ります。
この場合、事業者が持っているのは、ユーザー資産全体を自由に動かす権限ではありません。
特定のトークンを、特定の宛先へ、一定条件の範囲内でのみ動かす権限です。
これなら、「ユーザー資産を預かった」というより、「ユーザーが自分のアカウントに、特定用途の実行権限を設定した」と説明しやすくなります。
逆に、制約が弱いSession Keyは危険です。
たとえば、JPYCをtransferできるが、recipientは任意、amountは大きな上限、expiryはなし、という権限を渡すとします。
もはやこうなってしまうと「この事業者への支払い」ではなく、「一定額まで任意宛先へ送れる権限」と言ったほうが近くなるでしょう。
さらに制約が弱ければ、実質的にはメイン秘密鍵に近い権限になり得ます。
どこまで制約すれば、実質的な権限がないとみなされるのか
この濃淡が絡んでくるのが、まさにカストディということになります。
「ユーザーの資産を、事業者がユーザーの関与なしに動かせる状態か」という観点で実態判断されるものと思いますが、ではどこまで制約すれば、実質的な権限がないとみなされるのでしょうか。
たとえば、すでに広く用いられている決済方式として、電気料金や通信料金のように、毎月の請求額が変わる「自動引き落とし」があります。
口座振替であれば、ユーザーは口座振替依頼書やWeb口座振替受付を通じて、特定の収納企業による引落しをあらかじめ承認します。
オンチェーンでこれを模倣して、宛先固定、token固定、期間上限、revoke可能なSession Keyを発行すれば、それはカストディ非該当だと言えるでしょうか？
たとえば、JPYCだけ、この事業者宛だけ、月間1万円まで、有効期限は12か月、ユーザーがrevoke可能、という条件です。
もしカストディではないとしたら、どの条件を外すとカストディになってしまうのでしょうか。
このように、一筋縄ではいかない論点が出てきます。
そもそも、Session Keyはユーザーの関与なしには発行できませんし、ユーザーが主体的にrevokeもできるとして、Session Keyは「ユーザーの関与が必要」な技術だと言い切ってしまってよいのでしょうか？
初回の同意のみで以降はユーザーの関与などなしに資産移動できる形態が、実質的に秘密鍵と何が違うのか。このあたり、まさにグレーゾーンと言えます。
Session Keyのrevocability
Session Keyが事業者サーバーに格納される構成の場合、ユーザーが主体的にrevokeできるかどうかは論点の濃淡を左右する要素となりうるでしょう。
ここで、パスキーをオーナー権限としたスマートコントラクトウォレット（ERC-4337）を考えてみましょう。
パスキーはユーザー端末のsecure enclaveに保持されるので一見するとユーザー主権に見えますが、ウォレットアプリ提供サイドが用意していない内容で署名は生成できません。
アプリ上にrevoke経路がなかった場合は、主体的にrevokeできるとは言いづらくなります。
これがEOAをオーナー権限とした構成だった場合、EOAの秘密鍵をエクスポートできる仕様でありさえすればユーザーの主体的署名は比較的容易に生成可能です。
しかし、これは私が技術者だから容易だと感じるだけであって、一般ユーザーを基準にして、秘密鍵がエクスポートできるだけでは主体的にrevokeできるとは言えないと一刀両断される可能性もあるでしょう。
その他の論点
技術要素に直接紐づかないものの、放念できない論点もあります。
電子決済手段か暗号資産か
ステーブルコインであるJPYCはブロックチェーンに乗っていますが、法的には「電子決済手段」です[3]。
一方で、ネイティブトークンは「暗号資産」です。
下手に暗号資産を取り扱ってしまうと、暗号資産交換業の規制へ抵触する可能性が生じます。
Session Keyを発行する場合、対象トークンをJPYCに限定するなどして、抵触可能性を下げておくことが望ましいでしょう。
デポジット
チャージができる設計は、前払式支払手段への該当性に注意が必要です。
これらはここまで述べてきた権限管理とは別の論点で、該当性を判断する必要があるでしょう。
ステーブルコインから店舗独自のポイントに変換するのか、有効期限はどうなのか、払い戻しはできるのか、などの設計次第で、前払式支払手段に該当する可能性があります。
クロスボーダー
海外受取人への支払いも要注意です。
とくに、オンチェーンでは国内宛か海外宛かはアドレスだけでは分かりません。
しかし、取引実態として国境をまたぐ支払いならクロスボーダー決済や収納代行に該当する可能性があります。
オフチェーン制約
ここまで、金融資格を持たずにオンチェーン権限制御によって規制への抵触性をどう回避するかという暗黙の前提を置いて論じてきました。
しかし、オンチェーン権限制御だけで決済スキーム全体を完結させることが、必ずしも唯一の正解ではないでしょう。
Web3的には、支払い先、金額、上限、有効期限、revoke可能性などを、できるだけオンチェーンの制約として表現する設計は分かりやすく、理想的です。
トラストレスな設計に近づけるうえでも、法的評価の前提を整理するうえでも、オンチェーン完結型の認可設計は魅力的です。
しかし、そもそも既存の決済システムは、オンチェーンなど関係なく存在していますし、オンチェーンで完結させることが唯一の安全担保の手法でもありません。むしろ、オンチェーンによる制御のほうが特殊だと感じる人が世間には多いでしょう。
- 加盟店契約によって受取人を管理する
- 不正利用時の補償や取消処理を用意する
- 監査ログ、権限分掌、障害対応、精算管理を整備する
こうした業務統制や、あるいは業資格の取得によって、支払い意思や実行範囲を担保しているわけです。
たとえば、すでに銀行業や暗号資産交換業を持っているプレイヤーと組んでソリューションを展開するなら、オンチェーンで完結させることにこだわらず、業務統制や契約・監督規制で補う設計も十分に考えられます。
まとめ
こうして見ると、「どの技術方式を採用したか」だけでは到底論じきれないことがわかります。
秘密鍵を預かっていない、ノンカストディアルだ、AAを使っている、Session Keyだ、といったラベルだけでは不十分です。
- ユーザーは何を支払うつもりだったのか
- その意思を、オンチェーン上ではどのような資産操作権限として表現しているのか
- オンチェーンで縛っていない部分を、業務統制や契約・監督規制でどう補っているのか
こうした観点を総合的に見て、技術的な実装が法的な規制にどう関わるのか、本質的側面を整理したうえで当局の判断を仰ぐ必要があるでしょう。
しかも、幸か不幸かブロックチェーン上の内容は公開情報です。すでに社会実装が認められていそうな設計があった場合にそれを模倣することは比較的容易です。
しかし、その設計の実質的意味を考慮せずに技術的側面だけを模倣すると、法的なリスクを見落とす可能性があることには注意が必要です。
Discussion