EIP-8141「Frame Transactions」は、Ethereumの取引を検証・ガス代承認・実行という複数の処理単位に分ける提案です。 実現すれば、利用者自身がETHを保有していなくても、アプリやスポンサーがガス代を負担したり、利用者がERC-20トークンで実質的に精算したりできるようになります。 ただし、2026年9月時点では仕様はDraftであり、一般ユーザーが現在利用できる機能ではありません。
EthereumがEIP-8141をHegotáへ組み込む方針
CoinDeskは2026年9月7日、Ethereumのコア開発者がEIP-8141を「Scheduled for Inclusion」に移し、Hegotáアップグレードへ組み込む方針を固めたと報じました。HegotáはGlamsterdamに続くネットワークアップグレードとして計画されています。
EIP-8141の正式名称は「Frame Transaction」です。Ethereumの通常取引に新しい取引形式を加え、取引の有効性確認、ガス代の支払い承認、ユーザーが希望する処理の実行を、それぞれ独立したフレームとして記述します。
重要なのは「ガス代が不要になる」という話ではない点です。Ethereumネットワークへ支払われる手数料は引き続きETH建てですが、そのETHを取引の送信者本人が用意する必要がなくなります。例えば、UniswapのようなDEXを利用する際、ウォレット運営者やアプリ側がETHを立て替え、利用者からUSDCなどのERC-20トークンを受け取って精算する設計が可能になります。
なお、EIPの公式ページでは現在もDraftと表示されています。アップグレードへの採用方針が決まったことと、仕様が確定してメインネットで利用可能になったことは区別する必要があります。
ETHを持たないとトークンを動かせない問題
現在のEthereumでは、ウォレットにUSDC、USDT、DAIなどを保有していても、ガス代に使うETHがなければ送金やDEX取引を実行できません。UniswapでUSDCを交換する場合も、Aaveへ資産を預ける場合も、基本的には取引を開始するアカウントがETHを準備します。
これは暗号資産に慣れた利用者には当然の仕組みでも、新規ユーザーには大きな障壁です。ステーブルコインを取引所からウォレットへ送った後、別途ETHを購入し、同じネットワークへ送金しなければならないケースがあるためです。異なるネットワークへETHを送ってしまう、必要量を判断できないといった失敗も起こり得ます。
Frame Transactionsでは、取引を実行するアカウントとガス代を承認するアカウントを分離できます。決済アプリが初回利用分を負担する、DAOが特定操作を補助する、スポンサーが利用者のERC-20を受け取ってETH建てガス代を支払う、といったモデルをEthereumの取引形式に組み込めるようになります。
MetaMaskなどの一般的なウォレットやUniswapのフロントエンドにとっては、「最初にETHを入金してください」という導線を減らせる可能性があります。ただし、どのウォレットやDEXが採用するかは各プロジェクトの判断であり、EIP-8141の導入だけで既存サービスが自動的に対応するわけではありません。
Frame Transactionsはどのように動くのか
EIP-8141では、一つの取引を複数のフレームへ分解します。大きく見ると、署名などを確認する検証フレーム、誰がガス代を支払うかを承認する処理、送金やスマートコントラクト呼び出しを行う実行フレームで構成されます。
例えば、利用者がUniswapでUSDCを別のトークンへ交換し、ガス代相当額をUSDCでスポンサーへ支払うケースを考えます。利用者の署名を検証し、スポンサーがガス代支払いを承認し、USDCをスポンサーへ移転したうえで、DEXの交換処理を実行できます。必要に応じて、スポンサー側で未使用分の精算やETHへの交換を行う後処理も設計可能です。
Ethereumへ支払う最終的な手数料までUSDCになるわけではありません。スポンサーはブロックへ取り込まれる取引のガス代をETHで負担し、利用者との間でUSDCなどを使って精算します。そのため「EthereumがETHを廃止する」「バリデーターが任意のトークンを直接受け取る」という意味ではありません。
Safeのようなスマートアカウントでは、複数署名や独自の認証条件を設定できます。Frame Transactionsが導入されれば、このようなプログラム可能な検証とガス代支払いを、Ethereumプロトコルに近い層で扱えることが期待されます。
DEXの承認と交換を一括処理できる利点
Ethereum上のDEXでは、ERC-20トークンを初めて交換するとき、一般にトークンコントラクトのapproveとDEXのswapが別々の処理になります。Uniswapで交換する場合、利用者は先にトークンの使用を許可し、その後に交換を実行します。
EIP-8141は、複数のフレームをアトミックなバッチとして扱う仕組みを定義しています。公式仕様には、ERC-20の承認とDEXの交換をまとめ、交換が失敗した場合には承認も巻き戻す例が掲載されています。
この仕組みは、不要な承認だけが残る問題を抑えるうえで有用です。現在は、価格変動、スリッページ条件、流動性不足などでUniswapの交換が失敗しても、それ以前に行った承認が残る場合があります。Frame Transactionsで両方を不可分にすれば、交換が成立しなかったのに権限だけが残る状態を避けやすくなります。
Aaveへの預け入れや、複数のDeFiプロトコルをまたぐ操作にも同じ考え方を応用できます。ただし、複雑な一括処理は署名画面の理解を難しくする可能性もあります。ウォレット側には、各フレームの送付先、トークン移動、承認範囲を人間が理解できる形で表示する対応が求められます。
ERC-4337やEIP-7702との違い
ETHを持たない利用者の取引は、EIP-8141を待たなくてもERC-4337のPaymasterを利用して実現できます。ERC-4337では、利用者がUserOperationを作成し、Bundlerが複数の操作をまとめ、EntryPointコントラクトを通してEthereumへ送信します。Paymasterは利用者に代わってガス代を支払うコントラクトです。
Coinbase Smart Walletなど、ERC-4337やEIP-7702を活用するウォレットは、すでにガス代スポンサーやバッチ処理を製品へ組み込めます。一方、この方式にはBundler、EntryPoint、Paymasterといった専用インフラが必要です。
EIP-8141は、検証・支払い・実行の分離を新しいEthereum取引形式としてプロトコルへ取り込む点が異なります。Ethereum Foundationは、スマートアカウントを標準的なアカウントモデルに近づけ、BundlerやRelayerへ必ずしも依存しないネイティブなアカウント抽象化を長期目標として示しています。
EIP-7702は、既存の外部所有アカウントがスマートコントラクトのコードを利用できるようにする重要な段階です。2026年時点でアプリを開発する場合、実用面ではEIP-7702とERC-4337が中心であり、EIP-8141は将来のネイティブ対応として追跡する位置付けになります。
利便性の裏側にあるリスク
ガス代スポンサーは無料サービスとは限りません。Uniswapなどを組み込むアプリがETHを立て替える場合、ERC-20で請求する手数料、為替レート、上限、返金方法を明確にする必要があります。利用者が直接ETHで払うより総コストが高くなる設計も考えられます。
スポンサーにもリスクがあります。EIP-8141の公式仕様は、取引がブロックへ入る前に利用者がERC-20残高を移動し、スポンサーへの支払いを成立させなくする可能性を挙げています。公開メンプールでトークン払いを受け付ける設計では、残高確認だけでなく、取引全体が成立する条件を慎重に設計しなければなりません。
また、柔軟な署名方式や鍵の更新はSafeのようなスマートアカウントの利便性を高める一方、検証コードの不具合という新しい危険も生みます。悪意あるスポンサー、過剰なERC-20承認、分かりにくいバッチ署名にも注意が必要です。
利用者は「ガスレス」という表示だけで判断せず、支払うトークンと金額、スポンサー、交換レート、付与する権限を確認すべきです。開発者はスポンサー障害時に利用者自身がETHで送信できる代替経路も検討する必要があります。
まとめ
EIP-8141「Frame Transactions」は、Ethereumの検証、ガス代承認、実行を分離し、ETHを持たない利用者でも取引しやすくする提案です。UniswapなどのDEXでは、アプリによるガス代負担、ERC-20による実質精算、承認と交換のアトミックな一括処理が代表的な応用になります。
一方、ネットワークの手数料そのものは引き続きETHで支払われます。無料化ではなく、誰がどの資産で負担するかを柔軟にする変更と理解するのが正確です。
2026年9月時点ではHegotáへの組み込み方針が示された段階で、EIP-8141の仕様はDraftです。現在の実装ではERC-4337、Paymaster、EIP-7702が引き続き重要であり、ウォレットやDEXはFrame Transactionsの仕様確定とクライアント実装を確認しながら対応を判断することになります。
