eip8183-agentic-commerce

name

eip8183-agentic-commerce

description

EIP-8183（Agentic Commerce）準拠のスマートコントラクト開発を包括的に支援するスキル。 AI Agent間の信頼不要な商取引（Job escrow + evaluator attestation）を実現する ERC-8183プロトコルの設計・実装・テスト・デプロイをカバー。 3者構造（Client/Provider/Evaluator）、6状態ステートマシン、 IACPHookによる拡張、ERC-8004レピュテーション連携、x402マイクロペイメント統合、 OpenZeppelin UUPS対応のリファレンス実装まで完全対応。 Use when building AI agent commerce systems, implementing ERC-8183 or EIP-8183, creating job escrow contracts, building agentic marketplaces, integrating AI agents with smart contracts, implementing evaluator attestation patterns, or working with Virtuals Protocol ACP. Also use when the user mentions agent-to-agent commerce, agentic commerce, job escrow, evaluator contracts, ERC-8004 reputation integration, or asks about AI agent on-chain transactions.

EIP-8183: Agentic Commerce スマートコントラクト開発ガイド

ERC-8183はEthereum Foundation dAIチームとVirtuals Protocolが共同策定した、 AI Agent間の信頼不要な商取引を可能にするERC標準（Draft）。 「Job escrow with evaluator attestation」パターンにより、 中央集権プラットフォームなしで「依頼→実行→検証→決済」を自動化する。

コア概念

3者構造（Client / Provider / Evaluator）

役割	権限	実体の例
Client	Job作成、Provider設定、Budget合意、エスクロー資金供託、Open状態でのReject	AI Agent、EOA、マルチシグ
Provider	Budget提案、成果物提出（submit）、完了時に報酬受取	AI Agent、サービスコントラクト
Evaluator	唯一のcomplete/reject権限、Submitted状態の最終判定	AI Agent、ZK検証コントラクト、マルチシグDAO

Evaluatorが最も重要な役割。Job作成時に固定され変更不可。 Client自身がEvaluatorを兼ねることも可能（自己評価シナリオ）。

6状態ステートマシン

Open ──fund()──→ Funded ──submit()──→ Submitted ──complete()──→ Completed
 │                  │                      │
 │reject()      reject()/expire        reject()/expire
 ↓                  ↓                      ↓
Rejected          Rejected/Expired     Rejected/Expired

状態	遷移先	トリガー
Open	Funded / Rejected	fund() / reject()
Funded	Submitted / Rejected / Expired	submit() / reject() / claimRefund()
Submitted	Completed / Rejected / Expired	complete() / reject() / claimRefund()
Completed	Terminal	エスクロー→Provider（手数料差引）
Rejected	Terminal	エスクロー→Client返金
Expired	Terminal	エスクロー→Client返金

Job構造体

struct Job {
    uint256 id;
    address client;
    address provider;      // address(0)で後から設定可能
    address evaluator;     // 必須・不変
    string  description;   // ジョブの説明
    uint256 budget;        // ERC-20トークン量
    uint256 expiredAt;     // タイムアウトタイムスタンプ
    JobStatus status;      // 現在の状態
    address hook;          // オプショナルな拡張コントラクト
}

コアインターフェース

// Job作成・設定
function createJob(address provider, address evaluator, uint256 expiredAt,
    string calldata description, address hook) external returns (uint256 jobId);
function setProvider(uint256 jobId, address provider, bytes calldata optParams) external;
function setBudget(uint256 jobId, uint256 amount, bytes calldata optParams) external;

// 資金供託・成果物提出
function fund(uint256 jobId, uint256 expectedBudget, bytes calldata optParams) external;
function submit(uint256 jobId, bytes32 deliverable, bytes calldata optParams) external;

// 評価・終了
function complete(uint256 jobId, bytes32 reason, bytes calldata optParams) external;
function reject(uint256 jobId, bytes32 reason, bytes calldata optParams) external;
function claimRefund(uint256 jobId) external;

重要な設計ポイント

• fund() の expectedBudget はフロントラン保護（Budget変更攻撃を防止）
• submit() の deliverable はbytes32（IPFSハッシュ/CID等のオフチェーン参照）
• complete()/reject() の reason はbytes32（評価証拠ハッシュ、ERC-8004連携用）
• claimRefund() はパーミッションレス（誰でも呼べる、タイムアウト後の安全弁）
• optParams は将来の拡張用バイト列

イベント

event JobCreated(uint256 indexed jobId, address client, address provider,
    address evaluator, uint256 expiredAt);
event ProviderSet(uint256 indexed jobId, address provider);
event BudgetSet(uint256 indexed jobId, uint256 amount);
event JobFunded(uint256 indexed jobId, address client, uint256 amount);
event JobSubmitted(uint256 indexed jobId, address provider, bytes32 deliverable);
event JobCompleted(uint256 indexed jobId, address evaluator, bytes32 reason);
event JobRejected(uint256 indexed jobId, address rejector, bytes32 reason);
event JobExpired(uint256 indexed jobId);
event PaymentReleased(uint256 indexed jobId, address provider, uint256 amount);
event Refunded(uint256 indexed jobId, address client, uint256 amount);

Hook（IACPHook）拡張システム

Hookにより、各アクションの前後にカスタムロジックを注入できる。 詳細は references/hooks.md を参照。

interface IACPHook {
    function beforeAction(uint256 jobId, bytes4 selector, bytes calldata data) external;
    function afterAction(uint256 jobId, bytes4 selector, bytes calldata data) external;
}

Hookable関数: setProvider, setBudget, fund, submit, complete, reject Non-hookable: claimRefund（安全弁として意図的にHook不可）

主要Hookパターン

• レピュテーションゲート: beforeAction(fund) でERC-8004スコアをチェック
• 入札マーケット: beforeAction(setProvider) で複数Provider入札を管理
• ZKプライバシー: afterAction(submit) でZK証明の検証
• アクセス制御: beforeAction(fund) でNFTホールドやステーキング要件をチェック

リファレンス実装パターン

詳細は references/implementation.md を参照。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;

import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/AccessControlUpgradeable.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuardTransient.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

contract AgenticCommerce is
    UUPSUpgradeable,
    AccessControlUpgradeable,
    ReentrancyGuardTransient
{
    using SafeERC20 for IERC20;

    IERC20 public paymentToken;  // 1コントラクト=1トークン
    uint256 public jobCounter;
    mapping(uint256 => Job) public jobs;

    // コア実装...
}

設計上の制約

• 1コントラクト=1 ERC-20トークン（USDC用とDAI用は別デプロイ）
• 成果物はオフチェーン保存（IPFS/Arweave）、オンチェーンにはハッシュのみ
• Evaluatorは作成時に固定（変更不可）
• 紛争解決メカニズムなし（reject/expireは最終決定）

エコシステム統合

ERC-8004（レピュテーション）

Agentの身元確認・評判管理標準。ERC-8183のcomplete/rejectイベントの reasonハッシュをERC-8004レジストリに送ることで、Agent実績がオンチェーンに蓄積される。

x402（HTTPマイクロペイメント）

同期的な単発APIアクセス課金プロトコル。

• x402: 1 HTTPラウンドトリップの同期支払い向き
• ERC-8183: 非同期マルチステップ作業 + エスクロー + 評価プロセス向き

フルスタック構成

ERC-8004 (Identity/Reputation) — 「誰で、信頼できるか」
    ↕
ERC-8183 (Agentic Commerce) — 「依頼→実行→検証→決済」
    ↕
x402 (HTTP Payments) — 「どう支払うか（API課金）」

Evaluator実装パターン

Evaluatorの設計がERC-8183システムの品質を決定する最重要部分。

パターン	用途	信頼性
Client自身	低リスク・信頼関係あり	低（自己評価）
単一AI Agent	主観的タスク評価	中（単一障害点）
マルチモデル合意	高品質要求（3+モデルで70%合意）	高
ZKスマートコントラクト	決定論的タスク検証	最高
マルチシグDAO	高価値・高リスク案件	高

Agent統合パターン

イベント監視（WebSocket）

const contract = new Contract(ACP_ADDRESS, ACP_ABI, wsProvider);

contract.on("JobCreated", (jobId, client, provider, evaluator, expiredAt) => {
  if (provider === MY_AGENT_ADDRESS) handleNewJob(jobId);
});

contract.on("JobFunded", (jobId) => startWork(jobId));
contract.on("JobCompleted", (jobId) => updateReputation(jobId));
contract.on("JobRejected", (jobId) => handleRejection(jobId));

コスト考慮

• 1 Jobライフサイクル = 最低4トランザクション（create + fund + submit + complete）
• Ethereum L1: ジョブあたり$20-50（ガス代）→ L2デプロイが実質必須
• L2（Base, Arbitrum等）: ジョブあたり〜$1

コード生成ガイドライン

ERC-8183のコードを生成する際は以下を遵守：

1. OpenZeppelinを使う — SafeERC20、AccessControl、ReentrancyGuard、UUPS
2. 状態遷移を厳密に — 各関数で正しい状態チェック + 権限チェックを実装
3. Evaluatorアドレスの検証 — address(0)は不可、作成後は不変
4. claimRefundはHook不可 — 悪意あるHookによるロック防止のため意図的設計
5. expectedBudgetパラメータ — fund()でフロントラン保護を必ず実装
6. reasonハッシュを活用 — complete/rejectでオフチェーン証拠のハッシュを記録
7. 1コントラクト=1トークン — マルチトークンは攻撃面を増やす
8. L2デプロイを前提 — L1はガスコスト的に高頻度取引に不向き
9. ERC-2771対応推奨 — _msgSender()でガスレス取引をサポート
10. イベントは全て発火 — オフチェーン監視・レピュテーション連携に必須

セキュリティ考慮事項

詳細は references/security.md を参照。

• Evaluator共謀リスク → レピュテーション/ステーキングで軽減
• 紛争解決メカニズムなし → アプリケーション層で対応
• 成果物可用性 → オフチェーンストレージのSLA保証が必要
• Hook悪用 → ホワイトリスト化、ガスリミット設定
• リエントランシー → ReentrancyGuardTransient使用

リファレンスファイル

• references/implementation.md — 完全なリファレンス実装コードとパターン
• references/hooks.md — IACPHookの詳細と実装例
• references/ecosystem.md — ERC-8004/x402統合・エコシステム詳細
• references/security.md — セキュリティ考慮事項・監査チェックリスト
• references/agent-integration.md — AI Agent統合パターン（TypeScript/Python）