ERC-677とは：スマートコントラクトのやり取りをより簡単に

スマートコントラクトは、トークンの交換、ステーキング、資産のブリッジング、オラクルの更新のトリガーなど、EVMチェーン上のほぼすべての重要なインタラクションを支えています。しかし、標準的なERC-20トークン規格では、「承認」してから「呼び出し」という複数ステップのUXパターンが必要になることが多く、これが手間を増やし、ガス代を高くし、ユーザーエラーの可能性を高めます。ERC-677は、トークン転送と即時のコントラクト呼び出しを組み合わせることで、これらのフローを合理化する、ERC-20への実用的な拡張です。

この記事では、ERC-677とは何か、その仕組み、どこで役立つのか、そして開発者やユーザーが2025年に注目すべき点について説明します。

ERC-20単体での問題点

ERC-20は、代替不可能なトークンに対するシンプルなインターフェース（転送、承認、転送元からの転送）を定義しています。このシンプルさがDeFiやステーブルコインの基盤となることを助けましたが、一般的なワークフローを2つのトランザクションに強制することにもなりました。

• スペンダー（支出者）の承認
• プロトコルコントラクトの呼び出し（その後、転送元からの転送を実行）

この2段階のパターンは以下の問題を引き起こします。

• トランザクション数とガス代の増加
• UXの煩雑さと混乱
• 承認レース条件や残存する許可（allowance）の発生。OpenZeppelinの承認に関するガイダンスを参照し、問題軽減のための推奨事項を確認してください。OpenZeppelin ERC-20 承認の推奨事項

ERC-20自体に関する背景については、Ethereum.orgのドキュメントを参照してください。ERC-20 標準の概要

ERC-677が追加するもの

ERC-677は、transferAndCallという1つの主要な関数でERC-20を拡張します。これにより、1つのトランザクションで、トークンが受信者コントラクトに移動し、その受信者に対して事前に定義されたコールバック（一般的にはonTokenTransfer）が任意のデータとともに即座に呼び出されます。

高レベルなフロー：

1. ユーザーがERC-677トークンのtransferAndCallに署名します。
2. トークンコントラクトが、指定された受信者にトークンを転送します。
3. トークンコントラクトが、recipient.onTokenTransfer(sender, amount, data)を呼び出します。
4. 受信者コントラクトがロジックを実行します（例：預け入れ、ステーキング、交換、またはオラクルのトリガー）。

このパターンは、個別の承認ステップの必要性をなくし、コントラクトがトークンを受け取った直後に反応できるようにします。

ChainlinkのLINKトークンは、ERC-677の実装としてよく知られています。これは、コントラクトがオラクルサービスや関連するインタラクションの支払いのためにLINKトークンの転送に即座に反応できるように設計されています。Chainlink LINKトークンとERC-677

一般的なユースケース

• ステーキングとVaultへの預け入れ: ユーザーは1つのトランザクションで預け入れを行い、Vaultはコールバックでその預け入れを記録します。
• DEXと流動性フロー: プロトコルはトークンを受け取り、直接交換または流動性の追加ロジックを実行できます。
• オラクルとサービス支払い: サービスコントラクトにトークンを転送し、同じ呼び出しで利用または請求をトリガーします。LINK ERC-677がスムーズなオラクル支払いを可能にする仕組みです。Chainlink LINKトークンとERC-677
• ブリッジとクロスチェーンプロトコル: トークン配送と、ブリッジングやメッセージングのための指示ペイロードを組み合わせます。
• クロスチェーン相互運用性: クロスチェーン利用が増加するにつれて、価値移転と実行の組み合わせは有用になります。Chainlink CCIPの設計は、ネットワークを横断するプログラム可能なトークンフローへの需要の高まりを示しています。CCIPとは

ERC-677と代替案の比較

• ERC-1363 (transferAndCallのような「payable tokens」): 同様の目標（トークン受信時にコントラクトが反応できるようにする）を持ち、支払いのような体験に適した、標準化されたコールバックを備えています。ERC-1363仕様

• ERC-777 (フックベースのトークン): よりリッチなトークンセマンティクスと受信者フックを提供します。強力ですが、歴史的には複雑さと、受信者が慎重に設計されていない場合にリエントランシーのリスクを伴いました。ERC-777仕様

• EIP-2612 (permit) と Permit2: 署名付きメッセージによるガスレス承認に焦点を当て、承認トランザクションの必要性を減らします。DEXやウォレットには最適ですが、多くの場合、その後にコントラクト呼び出しが残ります。ERC-677は、転送と実行をバンドルすることでユーザーのステップを削減します。EIP-2612 permit, Uniswap Permit2

• アカウント抽象化 (EIP-4337): ウォレットやペイマスターが複数の操作をバンドルし、ガスをスポンサーすることを可能にし、UXを向上させます。ERC-677は、プロトコル側のステップをさらに削減することでAAを補完します。EIP-4337 アカウント抽象化

要するに、permitとAAはウォレット側からの摩擦を減らし、ERC-677はトークン転送自体がスマートコントラクトロジックをトリガーできるようにすることで摩擦を減らします。

開発者向けの考慮事項とセキュリティ

トークン受信時のコールバックには、細心の注意が必要です。

• リエントランシー: トークンコントラクトは受信者ロジックを呼び出します。受信者がトークンや他の外部コントラクトに再度呼び出しを行うと、リエントランシーの脆弱性を導入する可能性があります。必要に応じて、チェック・エフェクト・インタラクション（checks-effects-interactions）またはガードパターンを使用してください。SWC-107 リエントランシー, OpenZeppelin ReentrancyGuard

• 送信者とトークンの検証: 受信者コントラクトがmsg.senderが信頼できるトークンコントラクトと一致することを確認し、複数のトークンをサポートしている場合はトークンアドレスを検証してください。

• ホワイトリスティング: コールバックが機密性の高い操作を実行できるトークンの場合、許可された受信者コントラクトのホワイトリスティング（またはインターフェースの検証）を検討してください。

• イベント設計: リッチなイベントを発行することは、インデックス作成と分析に役立ちます。ツールの互換性のために、可能であればERC-20互換のTransferイベントをERC-677固有のデータと併せて維持してください。

• フォールバックの安全性: 受信者が期待されるコールバックを実装していない場合、機能の「サイレント」な損失を避けるために、転送はロールバックするか、安全で明示的な失敗パスに従ってください。

• ガスと失敗モード: コールバックはロールバックする可能性があります。明確なエラーメッセージで失敗を処理し、ユーザーが転送が成功したのか、トランザクション全体がロールバックしたのかを理解できるようにしてください。

一般的なスマートコントラクトの安全性については、Solidityのセキュリティに関する考慮事項のドキュメントが引き続き必須です。Solidity セキュリティに関する考慮事項

ウォレットUX：ユーザーにとってなぜ重要なのか

「承認してから呼び出す」というシーケンスをなくすことで、ERC-677は複雑なインタラクションを単一の目的を持ったアクションのように感じさせることができます。これにより、署名の疲労が軽減され、認知的負荷が減り、多くの場合ガス代が節約されます。ただし、単一のトランザクションはより複雑です。トークンを転送し、コントラクトロジックを実行しているからです。これには、ウォレットからの明確なプレビュー、シミュレーション、および読みやすいコールデータが必要です。

セキュリティ意識の高いユーザーで、ERC-677を使用するプロトコルとやり取りする場合は、人間が読める関数名、パラメータ、および推定される価値の変化を表示するハードウェアウォレットを使用すると、自信を持って署名できます。

2025年の文脈：採用と composability

2025年には、価値移転と意図（intent）の実行をバンドルする傾向が続きます。

• より多くのプロトコルが、「ワンクリック」預け入れ、交換、またはサービス支払いを好み、ネイティブな感覚で承認の煩雑さを軽減します。
• クロスチェーンフレームワークは、プログラム可能なトークン移動とメッセージペイロードを重視します。ERC-677のようなセマンティクスは、これらのアーキテクチャによく適合します。CCIPがクロスチェーンユースケースのためにトークン転送と並行してプログラム可能なメッセージを形式化する方法を参照してください。CCIPとは

コールバックフローのシミュレーション、リスクの提示、および結合された転送と実行操作をより安全にするための分かりやすいプロンプトに対する、ウォレットとミドルウェアのサポートが増加することが予想されます。

最小限のインターフェーススケッチ

概念的に、ERC-677は以下のようになります（実装は若干異なる場合があります）。

interface IERC677 {
    function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
    event Transfer([address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) indexed from, [address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) indexed to, uint256 value, bytes data);
}

interface IERC677Receiver {
    function onTokenTransfer([address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) sender, uint256 value, bytes calldata data) external;
}

トークンコントラクトは、価値を転送した直後に受信者のonTokenTransferを呼び出し、受信者が単一のトランザクションで反応できるようにします。

実用的なヒント

• プロトコル開発者向け: 期待されるコールバックインターフェースとロールバック理由を明確に文書化してください。該当する場合は、インテグレーターが動作を検証できるように、許可リストまたはインターフェースチェックを公開してください。
• インテグレーター向け: transferAndCallをシミュレートして、コールバック後の状態変更をプレビューしてください。リスクの高い受信者または不明なコールバックをユーザーに警告してください。
• ユーザー向け: 信頼できるプロトコルを優先し、トランザクションプレビューを確認してください。ウォレットが読み取り可能なデコーディングをサポートしている場合は、コールバックに渡されるパラメータを確認する時間を取ってください。

ERC-677を使用すべきか？

ERC-677を使用すべき場合：

• 主要なユーザーフローの「承認 + 呼び出し」パターンを排除したい場合。
• プロトコルがトークン受信への即時かつアトミックな反応から利益を得る場合。
• 受信者コールバックをリエントランシーに対して強化し、トークンソースを徹底的に検証できる場合。

ユースケースが純粋に承認中心（例：DEXが後でトークンを使用できるようにする）である場合は、EIP-2612またはPermit2で十分かもしれません。複数の受信者にわたるよりリッチなフックセマンティクスが必要な場合は、ERC-777を評価してください。ただし、その複雑さに注意してください。

OneKeyユーザーへの注記

ERC-677トランザクションは、トークン転送とコントラクト呼び出しを組み合わせます。署名する際には、どの関数がどのパラメータで実行されるのかを正確に確認できると便利です。OneKeyのオープンソースアプローチとEVMサポートは、transferAndCallのような高度なインタラクションに対して、透明なコールプレビューと信頼性の高い署名を提供することを目指しており、パワーユーザーは強化されたセキュリティを維持しながら、合理化されたUXを享受できます。

ERC-677を理解し、トランザクションの詳細を明確に表示するウォレットを使用することで、よりシンプルで単一トランザクションのスマートコントラクトインタラクションの恩恵を安全に受けることができます。