admin
Paying an autonomous agent is easier than proving that it performed the requested work. A wallet transfer records value movement, not the quality of a model’s answer, the scope of a data license or whether an external tool executed correctly. Web3 applications can improve this gap by separating payment authorization from evidence of service delivery. The W3C Verifiable Credentials data model describes an issuer-holder-verifier ecosystem, and EIP-712 standardizes typed structured data signing in Ethereum applications. Neither standard, on its own, guarantees service quality or commercial fairness. This article proposes a minimal receipt protocol for AI work marketplaces that combines off-chain evidence, limited signatures and explicit dispute procedures.
Specify the service claim rather than a vague success flag
A useful receipt should answer what service was ordered, which policy version applied, what artifact or result was delivered and who is claiming completion. Define a typed schema with a job identifier, buyer reference, provider identity, result digest, execution timestamp, permitted outputs and expiry. Avoid attaching the entire prompt or raw private output to a public chain. A content hash lets parties compare the delivered item against a commitment without distributing the item itself. Distinguish ‘work attempted’ from ‘work accepted’: a model may return valid JSON but fail a business rule. The buyer and seller should agree on an acceptance test before execution, or the receipt will merely become a permanent record of disagreement.
Separate attestations by roles and trust boundaries
The provider can attest that it produced a result, but it should not be the sole authority declaring that result satisfactory. A neutral verifier may attest that objective conditions were met; a buyer may explicitly approve subjective work. W3C credentials support structured claims and verification mechanisms, but an issuer’s signature establishes attribution, not automatic factual truth. Use an issuer registry or allowlist with clear revocation procedures, and make the verifier’s scope visible. For example, an automated testing service may verify that a script passes unit tests without asserting that its business advice is correct. This prevents a narrow technical credential from being marketed as universal quality assurance.
Make structured signatures replay resistant by protocol design
EIP-712 provides an encoding for signing typed structured data, and the specification explicitly states that replay protection is not part of the standard itself. Include a domain, chain identifier, verifying contract, payer, payee, unique job nonce and expiration in the signed authorization. Reject previously consumed identifiers. If the same job can be retried, generate a new attempt identifier but preserve the business-level parent job for accounting. Check how wallet signatures are verified on smart contract accounts and how delegated keys expire. An evidence receipt should never quietly become an unlimited token approval; service confirmation and spending authority are separate privileges that belong in separate authorization paths.
Keep proof data where privacy and revocation remain manageable
Store confidential prompts, documents and generated artifacts in access-controlled storage with a retention policy. Put only necessary commitments, receipt identifiers and settlement references on-chain. If a content hash could reveal whether a known sensitive document exists, use keyed commitments or other privacy-preserving constructions appropriate to the threat model. A public blockchain is not an appropriate place for personal data that may later need deletion. Document which elements can be corrected, revoked or superseded. An append-only audit record is useful for accountability, but it does not remove data protection responsibilities. Ensure recipients have contractual and technical paths to challenge inaccurate attestations.
Create explicit dispute windows and bounded settlement rules
Automatic settlement works best for clearly measurable conditions, such as a successful computation with a reproducible test. Creative research, localization and strategic recommendations require judgment and should offer an acceptance window. A simple escrow policy might reserve payment, collect provider evidence, allow buyer review, then release a defined amount after acceptance or a documented decision. State the cost and timeline of arbitration, along with a fallback when a verifier goes offline. Avoid indefinite escrow that makes small jobs uneconomic. For partial delivery, specify whether milestones can settle independently and whether a rejected output may be used. If workers cannot predict payout rules, liquidity will leave the marketplace.
Test disputes, forged claims and missing evidence
Run adversarial cases: a provider reuses another job’s result hash, a trusted verifier signs the wrong identity, a chain reorganizes before confirmation, a buyer withholds approval, and a receipt is valid but points to unavailable content. The protocol should fail safely without releasing unauthorized funds or exposing private files. Measure incorrect automatic approvals, time to resolve challenges, incomplete provenance, fee overhead and the percentage of jobs requiring human escalation. Compare total verification cost against the value of a transaction; a $2 task cannot support a $20 audit. Keep the architecture modular so improvements in models and verification standards do not require migrating every historical job record.
A durable marketplace needs more than agent identities and wallets: it needs a shared language for what was ordered, what was delivered and what payment conditions were met. Evidence receipts can improve accountability when they remain narrow, verifiable and contestable. The promise is not that blockchains remove trust, but that they make selected claims and settlement decisions easier to inspect.
