eip8183-agentic-commerce

EIP-8183（Agentic Commerce）準拠のスマートコントラクト開発を包括的に支援するスキル。 AI Agent間の信頼不要な商取引（Job escrow + evaluator attestation）を実現する ERC-8183プロトコルの設計・実装・テスト・デプロイをカバー。 3者構造（Client/Provider/Evaluator）、6状態ステートマシン、 IACPHoo

SKILL.md

GitHub

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）

Похожие навыки: agents

agent-memory-yamadashy-repomix

Use this skill when the user asks to save, remember, recall, or organize memories. Triggers on: 'remember this', 'save t...

Автор: yamadashy
21,427

openai-whisper-api

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞

Автор: clawdbot
7,675

video-frames

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞

Автор: clawdbot
7,675