Hi ,
the hook system in ERC-8183 is the right design. it keeps the Job primitive lean while allowing domain-specific logic at each state transition. Two concrete use cases where hooks connect to open problems:
-
Evaluator attestation format. The Evaluator in 8183 calls
complete()orreject(), but the format of what the evaluator attested is not standardized. Two evaluators assessing the same job type produce incomparable attestation records. We’ve been working on a structured attestation interface / factual, signed, machine-readable statements with a score (0-1000), confidence metric, and decay semantics . That could serve as the attestation layer the Evaluator writes into. A pre-completion hook that verifies the evaluator’s attestation conforms to a standard format would make Job outcomes comparable across platforms. -
Risk-gated job acceptance. Right now, a Client funds a Job without knowing whether the broader system is under stress. During the Aave/rsETH exploit on April 18, $6.2B left Aave in 48 hours — agents executing jobs against affected assets had no standard way to check system risk before committing funds to escrow. A pre-funding hook that reads a cross-chain risk signal interface (
isCrisis()) would let agents skip job creation during adverse regime conditions, rather than discovering the risk after funds are locked.
Both of these are hook-compatible — they don’t require changes to the Job primitive. They need standardized interfaces that hooks can call. We’re drafting an ERC for this trust infrastructure layer (five interfaces: attestation, decision trail, accountability, risk signals, asset passports) that’s designed to sit underneath 8183’s evaluator and hook system.
Thread with the draft: https://ethereum-magicians.org/t/erc-xxxx-trust-infrastructure-for-autonomous-agents-and-tokenized-assets/28322
Question for @davidecrapis.eth : Is there a plan for standardizing what the Evaluator attests (beyond the binary complete/reject), or is that intentionally left to the hook layer?
Pat