Layer 3 gap: no neutral ERC-8183 skill - proposal to add one, with the evaluator slot wired to adjudication

[Zhekinmaksim]

Use case

An agent needs to hire another agent for a paid job with escrow and settle it on-chain via ERC-8183, and needs to decide who holds the evaluator role before any funds are locked.

Layer

Layer 3, Contracts & obligations. Both SKILL.md and README.md list ERC-8183 as a layer 3 standard and both flag it as uncovered:

• SKILL.md, stack table row 3: "ERC-8183 has no neutral public skill yet"
• README.md, stack table row 3: "ERC-8183 has no public skill yet"

What is missing

There is no skill in the package for ERC-8183 at all. Layer 3 currently routes only to vendored/arkhai/* (Alkahest, natural-language agreements, git escrow) and vendored/metamask/smart-accounts-kit/ (ERC-7710 delegations). Those are good instruments but they are alternatives to ERC-8183, not coverage of it: an agent asked to work against an ERC-8183 deployment has nothing to load, and the routing tables have no row that names it.

This matters more than a normal coverage hole because of one line in the ERC-8183 security considerations:

No dispute resolution or arbitration; reject/expire is final.

ERC-8183 defines an evaluator as a single address that alone may call complete or reject once a job is Submitted, and the spec itself notes a malicious evaluator can complete or reject arbitrarily. That evaluator slot is exactly the socket Internet Court exists to fill, and today nothing in the package explains how to fill it. An agent following the standard as written will default to evaluator = client, which is the least accountable configuration available.

There is a second, concrete hazard. The prose specification, the AgenticCommerce.sol listing embedded inside the EIP, and the public erc8183-reference Base deployment disagree on several call signatures and authorization rules, including:

• fund: prose is fund(jobId, expectedBudget, optParams?) with an explicit front-running guard; the EIP-embedded AgenticCommerce.sol listing is fund(uint256 jobId, bytes calldata optParams) with no budget check; the checked erc8183-reference Base deployment follows the guarded form
• setBudget: prose says client or provider may call; the EIP-embedded listing reverts for anyone other than the provider; the checked erc8183-reference source follows client-or-provider authorization
• setProvider: prose forwards optParams to the hook; the EIP-embedded listing takes no optParams and makes no hook calls; the checked erc8183-reference Base deployment includes optParams
• submit, complete, reject: prose and the EIP-embedded listing use bytes32 payloads; the checked erc8183-reference Base deployment uses dynamic bytes, changing the selectors
• createJob: the EIP-embedded listing adds a minimum expiry of block.timestamp + 5 minutes, a hook whitelist, and an ERC-165 check that are not in the prose or the checked erc8183-reference source
• the EIP-embedded listing adds an evaluatorFeeBP paid to the evaluator on completion, which the Fees section and checked erc8183-reference Base ABI do not expose

An agent that generates calldata from the wrong source will produce reverting transactions. A skill needs to say this out loud and require ABI verification against the target contract.

Checked for duplicates

Checked again on 2026-07-26 against the current open issue list. #1, #3, #4 and #8 concern layer 6 / evidence / dispute handling; #9 and #11 concern layer 4/5 payment-flow or vendoring; #10 is not a protocol coverage request. None covers layer 3 or ERC-8183.

What a fix looks like

A neutral skill to vendor, covering:

1. the six-state lifecycle with exact caller authorization and revert conditions per transition
2. the prose vs EIP-embedded listing vs deployment divergences above, with a hard instruction to verify the ABI against the deployed contract before generating calldata
3. evaluator selection as the central design decision, mapped onto the package's Basic / Guarded / Adjudicated trust levels, with the adjudicated pattern routing to integrations/genlayer-intelligent-contracts/SKILL.md for the review interface
4. IACPHook mechanics, including that claimRefund is deliberately not hookable and why that is the guaranteed recovery path
5. ERC-8004 reputation interop through afterAction on complete/reject
6. ERC-2771 plus ERC-2612 permit for gasless flows, which is the documented compatibility path to x402 and therefore the join between layers 3 and 4

"Neutral" is the operative word from the existing SKILL.md note. ERC-8183 came out of Virtuals Protocol's ACP and their production deployment is the largest, so a vendor-published skill would carry that framing. A skill written against the EIP and testable against any compliant deployment avoids that.

I have this written and ready to publish under a permissive license for vendoring. Happy to adjust structure, naming, or routing to match how you want layer 3 to hang together.

Proposed repository: https://github.com/Zhekinmaksim/erc8183-skill

The included ABI checker has been run against the erc8183/erc8183-reference Base Mainnet deployment 0x16213AB6a660A24f36d4F8DdACA7a3d0856A8AF5 using the verified ABI from Blockscout. The address is a direct contract, not an EIP-1967 proxy. The deployment follows the prose specification for fund(expectedBudget) and setProvider(..., optParams), uses bytes rather than bytes32 for deliverable and reason payloads, and confirms claimRefund is present. ABI shape only: caller authorization was not simulated.