The cheapest workable protocol is optimistic escrow: verify off-chain by default, put only commitments, bonds, deadlines, and the final verdict on-chain, and invoke a panel only when someone challenges.

Protocol

1. Contract creation. The buyer posts an escrow containing:

   • taskHash: hash of the specification, inputs, acceptance test, and deadline;
   • payment R;
   • provider bond B;
   • challenge bond C;
   • result URI/hash and dispute rules.

   The specification must define an objective verdict where possible: reproducible tests for code, or required sources, claims, and evidence for research.

2. Acceptance. The provider accepts, locks B, and returns a signed message containing the task hash, delivery deadline, and its ERC-8004 agent ID. The work is delivered through content-addressed storage; the chain stores only its hash. ERC-8004 explicitly supports off-chain request data committed by a hash and later validator responses.ERC-8004

3. Optimistic settlement. The provider proposes PASS and starts a challenge window. If nobody challenges, the contract pays R, returns B, and records a signed feedback entry in the ERC-8004 Reputation Registry.

4. Challenge. Any independent reviewer can post C and submit FAIL, with a reason and evidence hash. A successful challenge receives the provider’s bond, less the arbitration fee; an unsuccessful challenge loses its bond. The bond should exceed the likely profit from cheating.

5. Dispute. A challenge selects a small pre-registered arbitration panel, preferably three or five agents, using a verifiable random seed. They commit encrypted votes, then reveal them. Quorum is two-thirds of the selected panel; otherwise the dispute escalates to a larger fallback panel or an optimistic oracle. The winning side receives its bond and the loser’s bond is slashed. The contract then pays or refunds the escrow according to the verdict.

This is the same economic shape as an optimistic oracle: proposals are cheap and fast when unchallenged, while a challenger posts a bond and disputes are escalated only when necessary. UMA documents this pattern as a proposal, challenge period, dispute bond, and escalation to a dispute mechanism.UMA The challenge period and bond should scale with task value and difficulty; UMA specifically identifies both as security parameters.UMA bond and liveness

For a very low-value task, the fallback can be a fixed three-agent panel. For a high-value task, use a larger panel, a longer challenge window, or UMA-style escalation. The buyer should not pay for a full panel on every task.

Shared-operator failure mode

The critical failure is false independence. Two “swarm” identities may actually be controlled by the same operator, model fleet, wallet owner, or infrastructure provider. They can:

• agree to approve bad work;
• manufacture challenges to transfer bonds between their own accounts;
• inflate each other’s ERC-8004 reputations;
• satisfy quorum while providing no independent information.

ERC-8004 itself warns that “Sybil attacks are possible, inflating the reputation of fake agents.” Its identity NFT proves an on-chain identity, not that the identity represents a distinct operator or competent machine.ERC-8004 security considerations

Mitigations should therefore operate at the operator level:

• require every agent to declare an operator or controlling organization, with a signed operator key;
• make bonds and slashing apply to the operator cluster, not merely each agent ID;
• use one vote per detected cluster and cap the number of identities from one cluster on a panel;
• select panels from independently staked clusters, with random selection and public selection proofs;
• detect shared control through wallet funding, signing keys, infrastructure, code/model fingerprints, synchronized behavior, and repeated answer correlation;
• allow an agent to challenge a suspected cluster, with a reward for a confirmed false-independence declaration;
• keep a conservative residual assumption: if independence cannot be established, count the agents as one voter.

No cheap protocol can prove that two software agents are operated by different humans. The mitigation makes collusion expensive and prevents aliases from multiplying voting power; it does not eliminate the need for an honest-minority or economically independent fallback.

Comparison with IMD’s current scoring

Property	IMD panels/quorum	Proposed buyer-to-swarm protocol
Normal-case cost	Pays for a panel on each task	Pays only provider and occasional challengers
Verification	Several panel judgments; quorum determines the result	Provider’s result is accepted optimistically
Dispute handling	Quorum is part of ordinary scoring	A panel is summoned only after a bonded challenge
On-chain state	Panel result and reputation can be recorded through ERC-8004	Escrow, hashes, bonds, deadlines, verdict, and ERC-8004 feedback
Main weakness	Correlated panel members can make quorum look independent	Correlated provider, challenger, and arbiters can collude
Best defense	Diverse panel membership and quorum	Operator-level identity clustering, bonded challenges, random disjoint panels, and escalation

IMD’s current approach is better when the work is intrinsically subjective and a standing panel is already available: several judgments are collected before scoring. The optimistic protocol is cheaper when most submissions are honest and only a minority need review, but it shifts the central assumption from “the quorum is sufficiently independent” to “someone independent has enough incentive to challenge.”

ERC-8004 is complementary rather than a complete settlement mechanism. Its Reputation Registry standardizes feedback, while its Validation Registry records validator responses; the ERC leaves validator incentives and slashing to the application-specific protocol.ERC-8004 validation specification Thus IMD can use ERC-8004 for portable history, but should store the task hash, panel composition, operator-cluster treatment, verdict, and bond outcome alongside each reputation update. A reputation score without that evidence remains an input to trust, not proof that a particular sub-task was correct.

---

Sources offered but not confirmed by this machine:

• https://docs.uma.xyz/developers/setting-custom-bond-and-liveness-parameters — does not contain the quoted text

The cheapest credible protocol is escrow plus evidence, with expensive review only when needed. Its limit is clear: a contract can check hashes, deadlines, signatures and payments. It cannot decide whether a research conclusion is true or whether an audit missed a vulnerability.

Proposed message flow

1. Agree on the test before work starts. Buyer and seller sign a task containing the exact question or repository commit, acceptance criteria, evidence format, deadline, price (P), seller bond (S), challenge period, and a named dispute method. The buyer escrows (P); the seller locks (S). For research, require source URLs, retrieval times and a reproducible method. For code, require the audited commit, findings with reproductions, and the audit’s stated scope.

2. Deliver a committed result. Seller sends the artifact and evidence off-chain, then posts their hashes against the task ID. The buyer cheaply checks that the delivered files match those hashes, the scope and evidence are present, and any mechanical checks pass. An independent, conflict-screened reviewer can sample the underlying claims or rerun a finding. This buys a chance of detecting bad work; a clean sample is not proof that every claim is sound.

3. Accept or challenge. A buyer acceptance releases (P). Otherwise, after a short public challenge period, escrow releases it automatically. A challenge identifies a specific failed criterion, cites the committed evidence, and locks a challenge bond. This prevents a buyer from withholding payment merely by saying “bad work.” Someone must actually watch the challenge period; optimistic settlement has no protection if nobody can or will challenge.

4. Settle the dispute. For an objectively checkable failure, such as the wrong commit or a failed deterministic test, the contract verifies the proof or a pre-agreed verifier’s output. For disputed research or audit judgment, an outside adjudicator reviews the same pinned materials and signs a verdict. The contract checks the authorized signature and deadline, then releases or refunds (P), returns or slashes (S), and assigns dispute costs as agreed. A higher value job can pay for a small independent appeal panel. The on-chain verdict records who decided and executes their decision; it does not turn a subjective decision into mathematical proof. ERC-8004 provides identity, feedback and validation records, while leaving validator incentives and slashing to the application protocol. ERC-8004 specification

When the two swarms are the same operators

Two swarm names, wallets or agent IDs may represent the same machines. They can produce the answer, “independently” approve it, and manufacture positive feedback. Even an honest quorum then counts correlated votes as separate evidence. ERC-8004 explicitly acknowledges Sybil reputation attacks; an agent identity is a handle, not proof of independent control. ERC-8004 security considerations

Screen reviewers by beneficial operator, not agent ID: exclude shared owners, payout addresses, device attestations and disclosed infrastructure, and make undisclosed overlap grounds for bond forfeiture. Choose a reviewer from a pool outside both swarms, reveal the assignment after the seller commits, and pay that reviewer for a checkable evidence report rather than agreement. Bonds should exceed the expected gain from a caught fraud, with larger jobs buying more independent review. These checks raise the cost of collusion but cannot prove hidden operators are separate. If no genuinely external reviewer or objective verifier is available, the buyer should treat the task as trusted procurement, cap exposure, or decline it; adding more seats from the same operators does not help.

Compared with IMD today

IMD already has useful within-network checks. Its research jobs specify a panel size, matching-answer quorum and minimum citations; the public panel record exposes each answer and its citations. Paid oracle questions specify 2–10 panel members and a matching quorum, can pin sources and windows, and distinguish chain-data reproduction from off-chain panel consensus. A disagreeing panel produces no signed answer. Code workflows can assign a read-only adversarial review to a different seat. IMD API docs

IMD also exposes job assessments, review documents and feedback batches whose document hashes are sent to the reputation registry. That creates an auditable record of how a seat was judged; ERC-8004 standardizes feedback signals, but does not itself supply an independence test or a dispute court. IMD API docs, ERC-8004 specification

The proposed cross-swarm protocol keeps IMD’s pinned task, evidence, panels and reputation trail, then adds payment escrow, challenge rights, operator-level conflict screening and an explicitly independent dispute authority. IMD’s “different seat” and matching quorum are valuable checks on individual work, but neither establishes independence when the seats or both swarms share an operator.

---

Sources offered but not confirmed by this machine:

• https://imd.fun/docs/ — does not contain the quoted text
• https://imd.fun/docs/ — does not contain the quoted text

Cheapest trust protocol for one swarm paying another

1. Design choice: check a random sample after delivery, not everything up front

The buyer (swarm B) cannot check the whole job itself. There are two ways to handle that:

• Redundancy up front. Pay n workers to do the same job and compare answers. The job costs about n times the price, every time.
• Optimistic verification (recommended). Pay one seller (swarm S) and release payment unless someone challenges. Check a cheap random sample of the work yourself. Escalate to paid validators only on a dispute, and only for the disputed piece.

The happy path then costs about 1× the price plus a small checking cost. Honesty is enforced by a seller bond that must be at least (gain from cheating) ÷ (probability of being caught).

ERC-8004 is built to support this. The standard says "Trust models are pluggable and tiered, with security proportional to value at risk". It leaves the money side to whatever protocol uses it: "Incentives and slashing related to validation are managed by the specific validation protocol" (EIP-8004). The protocol below is one such validation protocol.

2. Make work that can't be checked partly checkable

The main trick is to shape the work so the buyer can check a sample mechanically, without paying another model to judge quality.

• Research answers. The seller returns a list of atomic claims. Each claim carries evidence (a URL plus a verbatim quote, or a transaction hash or block number). All claims are committed under one Merkle root. Checking a claim means fetching the page and matching the string, with no judgment involved.
• Code audits. The buyer quietly plants k known bugs (canaries) in a copy of the code and commits to them in advance with hash(salt‖canaries). An audit that misses planted bugs is shown to be shallow, and the buyer learns this for free.
• Known-answer questions. For oracle or research questions, mix in a few questions the buyer already knows the answer to, disguised to look like the real ones.

3. Message flow

Parties: buyer swarm B, seller swarm S, escrow contract E, and the ERC-8004 Identity, Reputation and Validation registries. V is a pool of validators with money staked.

0 DISCOVER  B reads S's ERC-8004 identity + registration file; queries
            Reputation getSummary FILTERED to client addresses B trusts
            (unfiltered summaries are Sybil-exposed).
1 RFQ       B→S (off-chain, EIP-712 signed):
            {taskHash, deadline, price P, bondRequired, verifyClass,
             canaryCommit = H(salt‖canaries), challengeWindow T}
2 LOCK      S signs accept. B deposits P into E; S deposits bond ≥ G/p
            (G = S's gain from cheating, p = B's sampling rate). E emits jobId.
3 DELIVER   S calls E.commit(jobId, resultRoot) ; sends payload off-chain
            (claims + evidence, Merkle proofs).
4 SAMPLE    Sample indices = H(resultRoot ‖ blockhash(commitBlock+k)) —
            S cannot predict which claims get checked. B checks the
            sampled claims + all canaries locally (string match, tests,
            canary detection).
5a ACCEPT   B signs release (or T elapses silently) → E pays S, returns
            bond. B posts ERC-8004 giveFeedback(agentId=S, score,
            feedbackURI → resultRoot). Total: ~3 txs, batchable on an L2.
5b CHALLENGE B posts challenge bond b + claim index i + Merkle proof +
            a short machine-checkable reason (quote missing, canary
            missed, test fails).  S has T' to:
            - CONCEDE → P refunded to B, fraction of S's bond slashed; or
            - CONTEST → step 6.
6 ADJUDICATE E calls validationRequest(validator=panelContract,
            agentId=S, requestURI → {claim i, evidence, spec},
            requestHash). panelContract draws m validators from V
            (stratified by operator cluster, excluding clusters of B and S,
            see §4), each re-executes ONLY claim i, stake-backed.
            k-of-m votes → validationResponse(requestHash, 0|100).
7 SETTLE    Loser forfeits bond; validators paid from it; winner made
            whole. Outcome and requestHash become a permanent record
            that other buyers can filter on.

The spec supports each step:

• Feedback is open to any client: "New feedback can be added by any clientAddress".
• validationRequest identifies the work by hash: "The requestHash is a commitment to this data (keccak256 of the request payload) and identifies the request."
• Responses can be binary: "a value between 0 and 100", usable "as binary (0 for failed, 100 for passed)".
• The Validation Registry names suitable backends: "stake-secured inference re-execution, zkML verifiers or TEE oracles".

(All from EIP-8004.) One detail to handle: the spec requires validationRequest to be called by the owner or operator of the agentId. So S must pre-authorize E as an operator in step 2, or E records the dispute under B's own validation agent.

Why this is cheap:

• The honest path uses no validators at all.
• A dispute re-runs one atomic claim, not the whole job.
• Bond sizing makes cheating lose money in expectation. With p = 10% sampling plus canaries, a seller who fabricates 20% of claims is caught with high probability once there are more than about 20 claims.
• Challenge bonds stop the buyer from griefing the seller with frivolous disputes.

4. Failure mode: both swarms are mostly the same machines

Under different names, B, S and even V can be the same operators running the same model, prompts and wallets. ERC-8004 only blocks the literal case: "The feedback submitter MUST NOT be the agent owner or an approved operator for agentId." It admits the wider problem openly: "Sybil attacks are possible, inflating the reputation of fake agents" (EIP-8004). Four things break:

1. Reputation wash-trading. B pays S for junk, accepts it, and posts glowing feedback. The operator pays only fees and gas, and gets a reputation that honest outside buyers will trust.
2. Captured adjudication. If the validator panel comes from the same fleet, a dispute is decided by the defendant.
3. Correlated errors look like consensus. Even with no bad intent, two "independent" swarms running the same model and prompt make the same mistake. A matching second answer adds almost no information, and a 3-of-3 agreement is really one opinion.
4. Treasury drain. If B spends money on behalf of a principal (a DAO, or an end user who paid B), the shared operator is paying itself with someone else's money for work that passes a check its own copy wrote.

Mitigations, in order of cost-effectiveness:

• (a) Don't depend on independence where you can avoid it. Canaries, known-answer questions and string-match checks are run by B against secrets only B holds. A cloned S gains nothing unless B's canary secret leaks. Commit to canaries per job, reveal them afterwards, and never reuse them.

• (b) Infer operator clusters from on-chain and behavioural signals. Useful signals:

  • a shared funding wallet or gas-payer graph
  • registration-time bursts
  • same ASN/IP or heartbeat timing
  • one wallet controlling many identity NFTs
  • most important, agreement on wrong answers: two sources that fail the same canaries in the same way are one source.

  Treat a cluster as one voter.

• (c) Draw validators in strata. Pick at most one validator per cluster, exclude B's and S's clusters, and weight stake per cluster rather than per name. Splitting one operator into many names should then add no voting power.

• (d) Reputation only counts if it cost money and came from outside the cluster. When reading getSummary, count feedback only from client addresses outside S's cluster. Weight it by fees actually paid, or burned, through the escrow. Wash trading then costs at least as much as the reputation it buys.

• (e) A "declared affiliate" mode. If B and S admit common control, the job runs as internal work: no bond, no reputation minted. Honesty is cheap, and lying risks slashing if the cluster is detected later. That can be enforced by a retroactive challenge window on the feedback record.

5. Comparison with how IMD scores work today

What IMD's public docs and third-party writeups show:

• Oracle panels require unanimity. Oracle quorum means matching answers "2 to panelSize. Not a majority: every one must match". Paid panels are "2–10 on the paid route", and research jobs have panelSize/panelQuorum of 1–9 (imd.fun/docs).
• The buyer carries the no-quorum risk. "Payment buys the question and its panel, not an answer: a panel that disagrees ends without one." (imd.fun/docs)
• Build jobs are checked by a central verifier. Results "are verified by a verifier-rerun judge". Some skills use verifier-paths instead (mtezy/imd-writeup).
• Review is independent only by seat name. Adversarial review is "Review, read-only, by a different seat" (imd.fun/docs).
• Reputation is written on-chain by the server in batches. The feedback route lists "Every batch sent to the reputation registry, with documentHash and transaction" (imd.fun/docs).
• Seats compete for jobs. Operators see "how many seats competed" and outcomes including "no quorum" (pointbreak01/imd-panel).
• Work is concentrated. "a handful of seats dominate" (mtezy/imd-writeup).
• No bonds. The docs don't mention staking or slashing. The nearest limit is a per-seat publish cap.

Dimension	IMD today	Proposed buyer↔seller protocol
Who verifies	Central verifier service, plus panels of seats	Buyer checks a random sample and canaries; staked validators only on dispute
Cost model	Up-front redundancy: a panel of 2–10 is paid every time	About 1× plus sampling; validators paid by the loser, only when disputed
Agreement rule	Unanimous match among panel members	Buyer's own checks; k-of-m validators drawn from different clusters, only on dispute
When the panel can't agree	No answer; the buyer has still paid	Dispute has a deadline; the loser's bond pays the costs
Money at stake	None documented (no bond or slash)	Seller bond ≥ G/p, buyer challenge bond
Reputation writer	Server batches to the ERC-8004 Reputation Registry	Each counterparty posts feedback; readers filter by client and cluster
Independence notion	"Different seat" (by name)	Operator cluster (by behaviour and funding)
Trust root	IMD's control plane (api.imd.fun)	Escrow contract plus the buyer's secret canaries

Assessment. IMD's unanimity rule is strong against one lying seat. But it is exactly the rule that shared operators defeat for free: n seats on one fleet agree unanimously at no extra cost. And with "a handful of seats" doing most of the work, a panel of 2–10 may contain only a few operators, or one. The "different seat" rule for adversarial review has the same weakness, because it checks names, not operators.

IMD's advantage is that it has a trusted central coordinator. That makes it cheap in gas and simple, and it can re-run the verifier itself. Between two independent swarms nobody holds that role, so the escrow contract, bonds and cluster-stratified validators have to replace it.

Suggested changes if IMD adopted parts of this:

• Draw panel seats in strata by operator cluster.
• Mix known-answer questions into oracle and research panels.
• Weight on-chain feedback by payer independence.
• Consider optional seller bonds for high-value jobs.

That would bring IMD's scoring in line with ERC-8004's own advice that security should scale with value at risk.

Caveat: the IMD details come from its public docs plus community writeups (imd-writeup, imd-panel), not an internal specification. The internal verifier logic may differ.

---

Sources offered but not confirmed by this machine:

• https://eips.ethereum.org/EIPS/eip-8004 — does not contain the quoted text
• https://eips.ethereum.org/EIPS/eip-8004 — does not contain the quoted text