1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cardene(かるでね)

[ERC8183] 依頼の報酬をエスクローで支払う仕組み

1
Last updated at Posted at 2026-09-23

はじめに

初めまして。
『DApps開発入門』という本や色々記事を書いているかるでねです。

以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！

AIエージェントや外部サービスへ依頼し、成果物を確認してから報酬を支払う仕組みを説明します。
ERC8183は、依頼者が予算を預け、実行者が成果物を提出し、評価者の結果に応じて支払う規格です。

概要

依頼を受けて成果物を返す場面

依頼者がデータ分析を依頼し、結果を確認してから報酬を支払う場面を考えます。
提出後に支払うまたは返金するを決める役割が判定主体です。ERC8183では、依頼者をclient、成果物を提出する実行者をprovider、この判定主体をevaluatorとして記録します。evaluatorは人のアドレスに限らず、判定ロジックを実装したコントラクトも指定できます。

ERC8183の依頼、提出、判定、資金結果

clientは予算を預け、providerは成果物を参照する値を提出します。
evaluatorがcompleteを呼べばproviderへ支払い、rejectを呼べばclientへ返金します。期限切れの返金はevaluatorの判定ではなく、claimRefundが実行する回復経路です。
この三役を1件のジョブに保存するため、誰が依頼し、誰が提出し、誰が判定したかを同じ識別子で追跡できます。
ERC8183のコアは、成果物の内容を評価することではなく、三役の権限と判定後の資金移動を状態遷移へ結び付けることです。

予算を判定まで預ける

ERC20は、コントラクトが預かり、条件を満たした相手へ送れるトークンです。
ERC8183は、1件のジョブの予算を判定までコントラクトに置きます。
clientが提出後に資金を回収できないため、providerが提出した後の支払い条件を保てます。
支払いに使う資産はERC20です。
fundの前にclientが承認を設定し、コントラクトがtransferFromで予算を受け取ります。

ERC20については以下の記事を参考にしてください。

判定結果で資金を分ける

完了時の送金先はproviderです。
却下時と期限切れ時の返金先はclientです。
状態、呼び出し元、ERC20の送付先を同じjobIdで追跡できます。
ERC8183は、ジョブごとに決めた予算をいったんコントラクトへ移し、判定結果に応じてproviderまたはclientへ送ります。

動機

clientだけに資金回収を任せる失敗

clientだけが提出後の資金回収を実行できると、providerは作業を終えても報酬を受け取れるか分かりません。
反対に、providerが提出しただけで支払いが確定すると、clientは不完全な成果物でも返金できません。
そこで提出後の完了と却下をevaluatorに限定します。

providerの提出だけで支払いを確定する失敗

小さな依頼ではclient自身をevaluatorにできます。第三者の検証が必要な依頼では、評価ロジックを持つコントラクトをevaluatorに指定できます。つまり、evaluatorはERC8183が成果物の中身を自動採点する機能ではなく、判定結果をオンチェーンへ確定する権限です。evaluatorの判断が正しいか、紛争をどう仲裁するか、成果物の中身が本物かはERC8183の範囲外です。

判定が止まった時の返金を残す

評価が止まったまま期限を過ぎると、clientはclaimRefundを呼んで預けた予算を回収できます。
期限後の返金はhookを呼ばないため、外部拡張が停止しても回収経路を残せます。
期限切れのclaimRefundは、evaluatorの判定を代替する評価機能ではありません。
判定が実行されない場合に、預託資金をclientへ戻す回復経路です。

仕様

ジョブの進み方

ジョブはOpen、Funded、Submitted、終端状態のいずれかです。
終端状態はCompleted、Rejected、Expiredであり、そこから戻りません。
Openは依頼を作ったが、まだ予算を預けていない段階です。
この段階ではclientがproviderや予算を変更でき、要件が合わなければ送金なしでRejectedにできます。
FundedはERC20がコントラクトへ移った段階です。
ここからclientが一方的に資金を引き戻せないため、providerは提出作業へ進めます。
Submittedはproviderが成果物の参照値を出し、evaluatorの判定を待つ段階です。
Completedではproviderへ支払い、Rejectedではclientへ返金し、Expiredでは期限後の返金を記録します。

ERC8183の状態遷移

遷移 呼び出し条件 資金の結果
Open → Funded clientが予算を預ける。 ERC20をエスクローへ移す。
Open → Rejected clientが却下する。 預託前なので送金しない。
Funded → Submitted providerが成果物参照を提出する。 資金を保持する。
Funded → Rejected evaluatorが却下する。 clientへ返金する。
Funded → Expired 期限後にclaimRefundを呼ぶ。 clientへ返金する。
Submitted → Completed evaluatorが完了を選ぶ。 providerへ支払う。
Submitted → Rejected evaluatorが却下する。 clientへ返金する。
Submitted → Expired 期限後にclaimRefundを呼ぶ。 clientへ返金する。

期限後にFundedまたはSubmittedから返金できることは必須です。
claimRefundを誰でも呼べる実装が推奨されますが、clientだけに制限する実装も許可されます。
したがって、評価者がオフラインになっても資金が永遠にロックされる設計にはしません。
一方、期限が到来する前にclientが返金できるわけではなく、completeやrejectの認可も状態ごとに固定されます。

3者が担当する操作

clientはジョブを作り、予算を設定してERC20を預けます。
providerは成果物を提出し、完了時の支払いを受けます。
evaluatorはSubmitted後の完了または却下を決めます。
providerを作成時に未設定へできるため、clientは資金を預ける前にsetProviderを呼びます。
clientとproviderはsetBudgetで合意する金額を保存しますが、実際のトークン移動はclientがfundを呼んだ時だけ起きます。
providerはcompleteやrejectを呼べず、evaluatorは成果物を提出できません。
この認可をmsg.senderとJobに保存した3つのアドレスで照合することで、操作の担当を状態遷移へ結び付けます。

Job 

struct Job {
    uint256 id;
    address client;
    address provider;
    address evaluator;
    string description;
    uint256 budget;
    uint256 expiredAt;
    JobStatus status;
    address hook;
}

Jobは、1件の依頼の当事者、説明、予算、期限、状態、拡張先を保存する構造体です。

  • フィールド
フィールド 詳細
id ジョブを識別する連番です。
client 依頼を作り、予算を預け、返金を受け取るアドレスです。
provider 成果物を提出し、完了時に支払いを受けるアドレスです。
evaluator 完了または却下を決めるアドレスです。
description 依頼内容を表す文字列です。
budget ERC20で預ける金額です。
expiredAt 期限を表すタイムスタンプです。
status 現在の状態です。
hook 前後処理を受け取る任意のコントラクトです。

ジョブを作成して予算を預ける

createJob 

function createJob(address provider, address evaluator, uint256 expiredAt, string calldata description, address hook) external returns (uint256);

clientがOpen状態のジョブを作成し、jobIdを返します。

  1. 入力を確認する
    evaluator、期限、hookを確認します。
  2. ジョブを保存する
    当事者、説明、期限を保存します。
  3. 結果を返す
    JobCreatedを発行してjobIdを返します。
  • 引数
引数 詳細
provider 成果物を提出するアドレスです。ゼロアドレスなら後で設定します。
evaluator 完了または却下を決めるアドレスです。
expiredAt 返金可能になる期限です。
description 依頼内容です。
hook 前後処理を受け取る任意コントラクトです。
  • 戻り値
戻り値 詳細
jobId 作成したジョブの識別子です。

実行条件

項目 条件
判定を行うアドレス 完了・却下を確定する主体を空欄にしません。
判定者がいないJobは支払い結果を確定できないためです。
設定できる期限 expiredAtは実装が定める最小期限より後にします。
短すぎる期限で、providerが作業する前に返金可能になることを防ぎます。

setProvider 

function setProvider(uint256 jobId, address provider, bytes calldata optParams) external;

clientが未設定のproviderを登録します。

  1. 状態を確認する
    Openで呼び出し元がclientか確認します。
  2. providerを保存する
    providerアドレスをジョブへ保存します。
  3. 変更を通知する
    ProviderSetを発行します。
  • 引数
引数 詳細
jobId 対象のジョブです。
provider 成果物を提出するアドレスです。
optParams hookへ渡す追加データです。

実行条件

項目 条件
ジョブの段階 ジョブはOpen状態です。
作成後で、まだ予算を預ける前の段階だけ変更できます。
操作するアドレス clientです。
依頼条件と役割を決めたclientだけが提出担当を登録します。
providerの設定 まだ設定されていません。
既にproviderが登録されたJobを上書きして、提出先を途中で変えないためです。

setBudget 

function setBudget(uint256 jobId, uint256 amount, bytes calldata optParams) external;

clientまたはproviderがOpenのジョブへ予算を設定します。

  1. 権限を確認する
    呼び出し元がclientまたはproviderか確認します。
  2. 予算を保存する
    amountをジョブへ保存します。
  3. 変更を通知する
    BudgetSetを発行します。
  • 引数
引数 詳細
jobId 対象のジョブです。
amount 合意する予算です。
optParams hookへ渡す追加データです。

実行条件

項目 条件
ジョブの段階 ジョブはOpen状態です。
予算を預けた後は金額を変更できないようにします。
操作するアドレス clientまたはproviderです。
両者が合意した金額を保存し、どちらか一方だけの変更に限定しません。

fund 

function fund(uint256 jobId, uint256 expectedBudget, bytes calldata optParams) external;

clientが保存済みの予算とexpectedBudgetを確認してERC20を預け、Fundedへ進めます。

  1. 予算を照合する
    保存値とexpectedBudgetを比較します。
  2. ERC20を預ける
    clientからコントラクトへ送付します。
  3. 状態を更新する
    Fundedへ移してJobFundedを発行します。
  • 引数
引数 詳細
jobId 対象のジョブです。
expectedBudget clientが確認した予算です。
optParams hookへ渡す追加データです。

実行条件

項目 条件
操作するアドレス clientです。
予算を実際に送付する資金の所有者だけがfundを開始します。
providerの設定 providerが設定されています。
送金後に提出先が未確定になるJobを作らないためです。
保存済み予算との照合 保存済み予算とexpectedBudgetが一致します。
clientが確認した金額とコントラクトの記録を照合し、古い金額で送金する事故を防ぎます。
トークンの支払い準備 ERC20の承認額と残高が足ります。
不足している場合は送金とFundedへの状態変更を成立させません。

成果物を提出して判定する

submit 

function submit(uint256 jobId, bytes32 deliverable, bytes calldata optParams) external;

providerが成果物を参照するdeliverableを提出し、Submittedへ進めます。

  1. 提出者を確認する
    呼び出し元がproviderか確認します。
  2. 参照値を記録する
    deliverableをイベントへ記録します。
  3. 状態を更新する
    Submittedへ移してJobSubmittedを発行します。
  • 引数
引数 詳細
jobId 対象のジョブです。
deliverable CIDや証拠ハッシュなど、成果物を参照する32バイトの値です。
optParams hookへ渡す追加データです。

実行条件

項目 条件
操作するアドレス providerです。
登録された提出担当以外が成果物を差し替えないためです。
ジョブの段階 ジョブはFunded状態です。
予算が預けられているが、まだ成果物が提出されていない段階です。

complete 

function complete(uint256 jobId, bytes32 reason, bytes calldata optParams) external;

evaluatorがSubmittedのジョブを完了にし、エスクローからproviderへ支払います。

  1. 評価者を確認する
    呼び出し元がevaluatorか確認します。
  2. 支払額を計算する
    手数料を控除する実装では残額を計算します。
  3. 支払う
    Completedへ移してproviderへ送金します。
  • 引数
引数 詳細
jobId 対象のジョブです。
reason 評価理由や証拠を参照する32バイトの値です。
optParams hookへ渡す追加データです。

実行条件

項目 条件
操作するアドレス evaluatorです。
提出者自身が完了を確定して支払いを得る経路を分けます。
ジョブの段階 ジョブはSubmitted状態です。
成果物参照が記録された後でなければ、支払いを確定できません。

reject 

function reject(uint256 jobId, bytes32 reason, bytes calldata optParams) external;

ジョブを却下し、予算が預けられていればclientへ返金します。

  1. 呼び出し元を確認する
    状態に応じてclientまたはevaluatorか確認します。
  2. 状態を更新する
    Rejectedへ移します。
  3. 返金を記録する
    預託済みならclientへ返金してイベントを発行します。
  • 引数
引数 詳細
jobId 対象のジョブです。
reason 却下理由や証拠を参照する32バイトの値です。
optParams hookへ渡す追加データです。

実行条件

ジョブの段階 操作できるアドレス
Open clientだけです。
預金前のJobを依頼者が取り消せる状態です。
FundedまたはSubmitted evaluatorだけです。
預金後の返金・却下を依頼者が一方的に決めないためです。

期限切れの返金

claimRefund 

function claimRefund(uint256 jobId) external;

期限を過ぎたFundedまたはSubmittedのジョブをExpiredへ進め、clientへ返金します。

  1. 期限を確認する
    現在時刻がexpiredAt以後か確認します。
  2. 状態を更新する
    Expiredへ移します。
  3. 返金する
    clientへERC20を返してRefundedを発行します。
  • 引数
引数 詳細
jobId 返金対象のジョブです。

実行条件

項目 条件
ジョブの段階 ジョブはFundedまたはSubmitted状態です。
預金後に判定待ちで止まったJobだけを対象にします。
返金できる時刻 現在時刻がexpiredAt以後です。
期限前のclientによる資金回収を防ぎます。
外部hookの扱い 呼び出しません。
hookや外部サービスが停止していても、clientが期限後に資金を回収できるようにします。

IACPHook 

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

IACPHookは、コア関数の前後へ検証や通知を追加するinterfaceです。

beforeAction 

function beforeAction(uint256 jobId, bytes4 selector, bytes calldata data) external;

状態更新やERC20送付の前に呼び出します。
失敗すると、本処理を止めます。

  1. 対象を確認する
    jobIdとselectorを確認します。
  2. 条件を検証する
    dataを読み取って追加条件を確認します。
  3. 処理へ戻る
    成功ならコア処理へ戻ります。
  • 引数
引数 詳細
jobId 対象ジョブの識別子です。
selector 呼び出し対象関数を識別する4バイトです。
data 対象関数の引数を表すデータです。

実行条件

項目 条件
呼び出すコントラクト コアコントラクトだけが呼び出します。
任意の外部アドレスが直接callbackを実行して、Jobの前提を偽装する経路を分けます。
hookの判定 hookが追加条件を満たさない場合はrevertします。
コア処理の状態更新や送金も同じトランザクションで取り消されます。

afterAction 

function afterAction(uint256 jobId, bytes4 selector, bytes calldata data) external;

状態更新と送金の後に呼び出します。
失敗すると、コア処理を含むトランザクション全体を戻します。

  1. 対象を確認する
    jobIdとselectorを確認します。
  2. 結果を通知する
    dataを読み取り、外部レジストリなどへ通知します。
  3. 処理を確定する
    成功ならコア処理と通知を確定します。
  • 引数
引数 詳細
jobId 対象ジョブの識別子です。
selector 呼び出し対象関数を識別する4バイトです。
data 対象関数の引数を表すデータです。

実行条件

項目 条件
呼び出すコントラクト コアコントラクトだけが呼び出します。
状態更新と送金が終わった後の通知を、対象Jobに結び付けます。
hookが失敗した場合 失敗すると、コア処理を含むトランザクション全体をrevertします。
通知だけ失敗して支払いだけ残る状態を防ぎます。

hookの対象関数と返金経路の境界

claimRefundはhookの対象外です。

判定結果をイベントで追跡する

イベントはjobIdを検索キーにして、状態変化と資金移動を追跡します。

イベントで追えるジョブと資金の変化

JobCreated 

event JobCreated(uint256 indexed jobId, address indexed client, address indexed provider, address evaluator, uint256 expiredAt, address hook);

ジョブ作成時に当事者、期限、hookを記録します。

フィールド 読み取れる内容
jobId Job storageと後続イベントを結び付ける識別子です。
client 依頼と預託を開始した主体です。
provider 作成時点の提出担当です。ゼロアドレスなら後で設定します。
evaluator 完了または却下を決める主体です。
expiredAt 期限後返金の判定に使う時刻です。
hook 前後処理を受ける拡張先です。

ProviderSet 

event ProviderSet(uint256 indexed jobId, address indexed provider);

未設定だったproviderを登録した時に発行します。

フィールド 読み取れる内容
jobId providerを設定したJobです。
provider clientが登録した提出担当です。

BudgetSet 

event BudgetSet(uint256 indexed jobId, uint256 amount);

ジョブの予算を保存した時に発行します。

フィールド 読み取れる内容
jobId 予算が変更されたJobです。
amount fund前に合意した予算です。

JobFunded 

event JobFunded(uint256 indexed jobId, address indexed client, uint256 amount);

ERC20がエスクローへ移り、Fundedになった時に発行します。

フィールド 読み取れる内容
jobId 預託されたJobです。
client ERC20を預けた主体です。
amount エスクローへ移った予算です。

JobSubmitted 

event JobSubmitted(uint256 indexed jobId, address indexed provider, bytes32 deliverable);

providerが成果物参照を提出した時に発行します。

フィールド 読み取れる内容
jobId 提出対象のJobです。
provider 提出した主体です。
deliverable 成果物を参照するCIDやハッシュです。

JobCompleted 

event JobCompleted(uint256 indexed jobId, address indexed evaluator, bytes32 reason);

evaluatorがジョブを完了にした時に発行します。

フィールド 読み取れる内容
jobId 完了したJobです。
evaluator 判定した主体です。
reason 判定理由や証拠を参照する値です。

JobRejected 

event JobRejected(uint256 indexed jobId, address indexed rejector, bytes32 reason);

clientまたはevaluatorがジョブを却下した時に発行します。

フィールド 読み取れる内容
jobId 却下されたJobです。
rejector Openで却下したclient、またはFunded/Submittedで却下したevaluatorです。
reason 却下理由や証拠を参照する値です。

JobExpired 

event JobExpired(uint256 indexed jobId);

期限後のclaimRefundでExpiredになった時に発行します。

フィールド 読み取れる内容
jobId 期限切れになったJobです。

PaymentReleased 

event PaymentReleased(uint256 indexed jobId, address indexed provider, uint256 amount);

完了したジョブのエスクローからproviderへ送った金額を記録します。

フィールド 読み取れる内容
jobId 支払い元のJobです。
provider 純額を受け取った主体です。
amount fee控除後にproviderへ送った金額です。

Refunded 

event Refunded(uint256 indexed jobId, address indexed client, uint256 amount);

却下または期限切れでclientへ返金した金額を記録します。

フィールド 読み取れる内容
jobId 返金元のJobです。
client 返金を受け取った主体です。
amount clientへ戻した金額です。

補足

成果物と評価理由を参照値で残す

deliverableとreasonは成果物や評価理由そのものではありません。
オフチェーンのファイル、CID、証拠ハッシュを参照する32バイトの値です。
元データの正しさを検証する処理は、別の評価・検証層が担当します。

評価と支払いを別の層へ分ける

ERC8004はagentの識別情報と評判を扱います。
ERC8183は依頼の予算、提出、支払い、返金を扱います。
ERC8004はagentのアイデンティティと評判を扱います。
ERC8183は支払いとエスクローを担当します。

ERC8004については以下の記事を参考にしてください。

互換性

ERC20トークンと接続する

fundではclientの残高からコントラクトへtransferFromし、完了時はprovider、却下または期限切れ時はclientへtransferします。
採用するERC20については、clientの残高とallowance、コントラクトの受取額、終端状態後の送付先を確認します。

ERC20については以下の記事を参考にしてください。

代送信を組み込む

ERC2771のtrusted forwarderが署名済み要求を送信します。
ACP側は元の署名者を _msgSender() で判定します。

ERC2771については以下の記事を参考にしてください。

署名承認を組み込む

ERC2612を組み合わせると署名でトークン承認を作れます。
permit と fund を1つの送信へまとめられます。

ERC2612については以下の記事を参考にしてください。

規格外の拡張を切り分ける

per-job token、platform fee、evaluator fee、hook whitelist、meta-transactionは実装が選ぶ拡張です。
ERC8183のJob状態、client/provider/evaluatorの権限、完了時の支払い、却下・期限切れ時の返金と混同しません。

参考実装

IACPHook.solを読む

参照実装のIACPHook.solは、IERC165を継承して2つのcallbackを公開します。

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

beforeActionはコア処理の前、afterActionは状態更新と送金の後に呼ばれます。
hookがrevertすると対象操作全体が戻るため、hookはallowlistや入力検証を追加できますが、コアのエスクローを直接変更する前提ではありません。
claimRefundをhook対象外にして、hookが停止しても期限後の返金を残します。

AgenticCommerce.solを読む

AgenticCommerce.solはupgradeableな中核コントラクトです。
initializeで支払いトークンとtreasuryを保存し、管理ロールを付与してゼロアドレスhookを許可します。

function initialize(address paymentToken_, address treasury_) public initializer;

createJobは期限、evaluator、hook whitelist、ERC165を確認してjobs[jobId]へ保存します。
setBudgetは予算を保存し、fundはSafeERC20.safeTransferFromでclientからコントラクトへ資金を移してFundedにします。
completeはfeeを計算してtreasury、evaluator、providerへ順に送り、rejectは預託済みならclientへ返金します。
送金を行う関数はnonReentrantで保護されます。

参照実装固有の制約

コード要素 実装で行うこと 規格との関係
AccessControlUpgradeable ADMIN_ROLEでfee、treasury、hook whitelistを更新する。 参照実装固有です。
UUPSUpgradeable DEFAULT_ADMIN_ROLEだけが実装を更新する。 参照実装固有です。
ReentrancyGuardTransient token送金を含む操作の再入を防ぐ。 実装上の保護です。
SafeERC20 ERC20の送付失敗を検出する。 実装上の保護です。
ERC165Checker hookがIACPHookを実装するか確認する。 参照実装固有です。
platformFeeBP / evaluatorFeeBP complete時だけ手数料を控除する。 feeは任意拡張です。

ExpiryTooShort、ProviderNotSet、FeesTooHigh、HookNotWhitelistedなどのcustom errorも、参照実装が追加した失敗条件です。

規格必須要件との差分

規格の必須要件は、Jobの状態、三役の認可、ERC20エスクロー、完了時のprovider支払い、却下・期限切れ時のclient返金です。
一方、参照実装のcreateJobは5分以上の期限、hook whitelist、ERC165Checkerを要求し、completeはplatform feeとevaluator feeを計算します。
upgradeability、role管理、fee、hook whitelistをERC8183本体の全実装に必須な条件と誤認しないようにします。

セキュリティ

evaluatorを信頼する範囲

Submitted後の完了と却下はevaluatorが決めます。
ERC8183はevaluatorの正しさや紛争仲裁を提供しないため、高額なジョブでは評判、stake、外部証明を別に設計します。
つまり、evaluatorが悪意を持つか誤判定すると、providerへの支払いまたはclientへの返金がオンチェーンで確定し、ERC8183の操作だけでは覆せない、という信頼境界です。deliverableとreasonは参照値なので、参照先の元データが存在することや、その判定が妥当であることもコントラクト単独では検証しません。採用側はevaluatorを誰が選び、stakeを没収するか、異議申立てをどの層で受け付けるかを別に決めます。

ERC8183の役割と信頼境界

hookで操作が止まる条件

hookが失敗すると、対象の操作は状態更新や送金を含めて戻ります。
hookが外部registryや別のtokenを呼ぶ場合、その外部呼出しの失敗もrevert原因になります。
beforeActionは状態更新前、afterActionは状態更新後に呼ばれます。どちらかがrevertすると、対象トランザクション全体がロールバックされるため、Jobの状態だけ進んで送金だけ失敗する形にはなりません。一方で、hookの外部依存が停止した時は通常の操作も止まります。hookの権限、外部registryの可用性、ガス上限、失敗時の再試行方針を確認し、期限到来後はhookを通らないclaimRefundへ切り替えられることを回復条件として検証します。

ERC20送金を再入から守る

fund、complete、reject、claimRefundはERC20送金を行います。
参照実装はReentrancyGuardTransientとSafeERC20を組み合わせ、状態更新と送金失敗を同じトランザクションで扱います。
再入防止だけでは、tokenの戻り値異常や送金先ごとの計算ミスを防げません。たとえばcompleteでtreasury、evaluator、providerへ分配する順序や、fee控除後のprovider純額を誤ると、二重支払いまたは残高不足になります。採用時はnonReentrantの適用範囲、状態をCompleted/Rejected/Expiredへ進める順序、SafeERC20が扱う失敗、非標準ERC20の戻り値、token自体のupgrade権限を確認します。tokenが悪意ある実装なら、コントラクト側の保護だけで完全には隔離できません。

期限返金を回復経路として残す

claimRefundはFundedまたはSubmittedかつ期限到来でだけ実行でき、hookを呼ばずにclientへ全額返金します。
そのため、hookが停止しても資金回収を妨げません。
確認すべき条件は、expiredAtを過ぎていること、状態がFundedまたはSubmittedであること、返金先がJobのclientであること、期限前に同じ経路を呼べないことです。期限後はhook非依存で全額を戻せる一方、期限設定が短すぎればproviderの提出時間を奪い、長すぎればclientの資金が拘束されます。紛争仲裁、off-chain成果物の真偽、期限設定の妥当性は別の運用・評価層で決めます。

最後に

ERC8183は、依頼者が予算を預け、実行者が成果物を提出し、評価者が支払いまたは返金を決めるジョブを標準化します。
採用時は、evaluatorの信頼性、期限切れの返金、hookの停止、参考実装との差分を確認します。

他でも色々記事を書いているのでぜひよろしければ読んでいってください！

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?