PACT: A Contract Layer for Autonomous Agent Commerce

Introduction

Motivation The 2024-2026 wave of agent interoperability protocols solved discovery, messaging, identity, and payment execution. It did not solve commerce. An agent engaging an unfamiliar counterpart agent today has no standard way to (a) obtain a binding, priced commitment to perform work; (b) condition payment on verified completion; (c) bound its liability when the counterpart subcontracts; or (d) accumulate portable, verifiable evidence of its own reliability. The absence of these mechanisms confines agent-to-agent delegation to prearranged, high-trust relationships, precluding open markets for machine work. PACT supplies the missing layer.

Relationship to Existing Work PACT is a modern realization of the Contract Net Protocol (announcement, bidding, award), which predated the identity, payment, and verification substrate PACT builds upon. PACT composes, and does not replace: A2A for task transport; the x402 payment protocol for settlement execution; AP2 mandates for human payment authorization; OAuth 2.0 Token Exchange for delegation chains; JWS and JCS for signing; and Decentralized Identifiers for party identity. Several contemporaneous individual drafts address adjacent parts of this problem. VCAP specifies marketplace-mediated escrow with verify-then-release settlement and free-form negotiation; PACT differs in requiring no marketplace intermediary, replacing negotiation with a sealed-bid second-price award (), settling optimistically against bonds and fraud proofs (), and adding recursive contract trees () and settlement-derived attestations (). AGTP defines an application-layer transport with runtime endpoint negotiation, over which PACT exchanges can be carried. The Agentic Dispute Protocol specifies dispute handling for agent interactions; an ADP-conformant service is a candidate Arbiter for the T3-jury tier (). Verify-then-pay architectures are also explored in the literature ; PACT's optimistic model makes the opposite latency trade and compensates with bonds and challenge windows. On reputation, ATEP defines a portable credential format for an agent's cross-platform track record, and ERC-8004 provides on-chain identity and reputation registries. PACT is complementary to both: its Work Attestations are the settlement-native evidence (emitted only through bonded, escrowed contracts) that such passports and registries can carry or index. The economic design agenda for agent markets, including auction-based allocation and verifiable reputation, is surveyed in ; PACT is a concrete wire-level realization of several of its recommendations. Further contemporaneous work: Virtuals' Agent Commerce Protocol and ERC-8183 pair on-chain escrow with evaluator agents; RAILS develops verification-native clearing with admissibility-graded verifier classes. PACT differs in its open sealed-bid award, bonded recursive contract trees, rail-agnostic settlement bindings (), and settlement-derived attestations. PACT Bonds generalize leveled-commitment breach penalties from the automated-contracting literature, which also documents the over-commitment ("eager bidder") failure mode PACT's bonds price in.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

Buyer Agent:: An agent procuring work.
Seller Agent:: An agent offering to perform work.
Call-for-Bids:: A signed solicitation broadcast by a Buyer Agent; abbreviated CFB.
VTC:: Verifiable Task Contract; the signed contract object defined in .
TaskSpec:: The structured task specification committed to by "spec_hash" ().
Bond:: Value staked by a Seller Agent, slashable upon a successful fraud proof or arbitration loss.
Challenger:: Any party submitting a fraud proof during a challenge window.
Facilitator:: A service that executes escrow locks, releases, and slashes strictly according to the VTC's terms, with no discretionary control over outcomes (see ).
Verification Tier:: The method by which work product is judged ().
Arbiter:: The party or panel resolving disputes for tiers that require judgment.
Work Attestation:: The co-signed record of a settled contract ().
Contract Channel:: A session within which multiple VTCs are formed and settled off-ledger with net settlement on close ().
Watchtower:: A delegate that monitors channels and challenge windows on behalf of a party that may be offline ().

Protocol Overview PACT proceeds in four phases: Propose, Agree, Complete, Trust.

Phase P: Propose The Buyer Agent broadcasts a Call-for-Bids (CFB) containing at minimum: a task specification or its hash, a deadline, a maximum price, the required Verification Tier, and a bid deadline. The CFB MUST be signed by the Buyer Agent. Seller Agents respond with sealed bids committing to a price, a bond amount, and acceptance of the Verification Tier. Bids MUST be submitted as cryptographic commitments (commit-reveal or recipient-key encryption) such that no bidder can observe another's bid before the bid deadline. Unless the CFB states a different ranking basis, bids are ranked by price alone. The Buyer Agent MUST award to the best-ranked bid at the price of the second-best-ranked bid (Vickrey award). Rationale: second-price sealed-bid awards make truthful bidding a dominant strategy, removing the incentive for adversarial inter-agent negotiation (see ). Free-form negotiation between agents is NOT RECOMMENDED for unattended operation. A CFB awards a single task. Combinatorial awards over bundles of tasks are out of scope for this version; see for the false-name-bidding rationale. A CFB is a JSON object with members: "pact", "type" ("CallForBids"), "id", "buyer", "task" (containing "spec_hash", "deadline", and the specification itself inline as "spec" or by reference as "spec_uri"; see and ), "max_price", "verification" ("tier", "criteria_hash"), "bid_deadline", "challenge" defaults for the resulting VTC, and "signatures". Bids received after "bid_deadline" MUST be rejected. A Bid is a JSON object with members: "pact", "type" ("Bid"), "cfb_id", "bidder", "commitment" (a hash over price, bond amount, and a bidder-chosen nonce), and "signatures". After "bid_deadline", bidders reveal price, bond, and nonce; the Buyer Agent MUST verify each revelation against its commitment before ranking. Media types for both messages are registered in . Note that these protocol messages are distinct from the static capability document of .

Phase A: Agree The Buyer Agent and the awarded Seller Agent construct a VTC (). Both parties MUST sign the JCS-canonicalized VTC using JWS . The Buyer Agent then locks the contract price with a Facilitator using a conditional-settlement binding (), and the Seller Agent posts its Bond. Where the Buyer Agent acts on behalf of a human or organization, its authority SHOULD be represented by an OAuth token containing an "act" delegation chain , and payment authorization MAY additionally be represented by an AP2 Intent or Cart Mandate .

Phase C: Complete The Seller Agent delivers work either atomically or as a sequence of hash-committed checkpoints. Settlement is optimistic: upon delivery of each checkpoint or the final work product, the Facilitator SHOULD release the corresponding payment immediately, subject to a challenge window whose duration is fixed in the VTC. During the challenge window, any party MAY submit a fraud proof appropriate to the contract's Verification Tier. A valid fraud proof MUST cause the Facilitator to revert unspent releases, slash the Seller Agent's Bond, and record the outcome in the parties' Work Attestations. Disputes in judgment-based tiers are resolved by the named Arbiter. From the slashed Bond, the Facilitator MUST reimburse a successful challenger's documented verification and submission costs and MUST pay the challenger a bounty capped at a small fraction of the Bond; any remainder MUST be directed to a neutral sink rather than to any party to the dispute. Rationale: with slashing alone, rational verifiers stop checking (the verifier's dilemma ); deployed optimistic systems pay bounded defender bounties, capped to avoid first-claimant races and self-challenge griefing. Total dispute duration MUST be bounded by the VTC's "challenge" parameters.

Phase T: Trust Upon expiry of the final challenge window, the Facilitator closes escrow and both parties exchange co-signed Work Attestations (). An implementation MUST NOT emit a Work Attestation for a contract that did not reach settlement through a Facilitator.

The Verifiable Task Contract A VTC is a JSON object with the following top-level members:

pact:: REQUIRED. Protocol version string.
type:: REQUIRED. "VerifiableTaskContract".
id:: REQUIRED. Unique contract identifier.
parties:: REQUIRED. Object: "buyer" and "seller" identifiers, which SHOULD be DIDs resolvable to verification keys.
task:: REQUIRED. Object: "spec_hash" (hash of the TaskSpec, ) and "deadline".
price:: REQUIRED. Object: "amount", "currency", "settlement" (binding identifier, ), and OPTIONAL "channel".
verification:: REQUIRED. Object: "tier" (), "criteria_hash", and OPTIONAL "arbiter".
liability:: REQUIRED. Object: "seller_bond", OPTIONAL "parent" (), OPTIONAL "insurance".
challenge:: REQUIRED. Object: "window_seconds" and OPTIONAL "max_dispute_seconds" bounding total dispute duration.
signatures:: REQUIRED. Array of JWS signatures over the JCS-canonical form of the VTC excluding the "signatures" member. MUST contain at least one signature from each party.

A VTC is valid only if all REQUIRED members are present and all signatures verify against keys bound to the party identifiers. The "task" member MAY additionally carry "spec_uri".

Hash Commitments and Content Conveyance Hash-valued members ("spec_hash", "criteria_hash") are commitments, not retrieval keys. The committed content MUST be conveyed to every party required to act on it (inline, or by a companion URI member such as "spec_uri") before that party signs. A recipient MUST verify that the conveyed content matches the hash before signing, and each party MUST retain the preimage at least until the later of contract finality and the end of any audit period agreed in the VTC. In a dispute, presenting content that matches a co-signed hash constitutes proof of the agreed content. Hash values are algorithm-prefixed (e.g., "sha256:..."); the "ni" URI scheme MAY be used for interoperable hash naming. Content dereferenced from "spec_uri" is integrity-protected by the hash, not by its transport.

The Task Specification The content committed by "spec_hash" is a TaskSpec: a JSON object, canonicalized with JCS before hashing, with the following members:

description:: REQUIRED. Natural-language statement of the work, written for machine comprehension.
skill:: OPTIONAL. Identifier of a published skill the task targets (e.g., an A2A AgentSkill "id").
inputs:: OPTIONAL. Object: input "schema_uri", a hash-committed representative "sample_uri", and a "size_hint".
deliverable:: REQUIRED. Object: output format and "schema_uri".
acceptance:: REQUIRED. Object conveying the verification instrument for the contract's tier: a test "harness_uri" for T0-reexec, model and enclave policy for T1-tee, a proof statement for T2-zkml, or a rubric for T3-jury, plus machine-readable "thresholds". The instrument is the content committed by the CFB's "verification.criteria_hash"; the two MUST match, and the conveyance and retention rules of apply.
constraints:: OPTIONAL. Object: tool prohibitions, confidentiality, and compliance conditions. The task deadline is carried in the "task" member of the CFB and VTC, not here.

Where the natural-language "description" and the acceptance instrument conflict, the acceptance instrument governs. PACT settlement is gated on verification, so the operative definition of completion is the one the verifier applies; the description conveys intent, and sellers are expected to price bids from the acceptance instrument and sample inputs rather than from prose alone. Confidential tasks MAY publish a CFB that omits the inline "spec" and gates "spec_uri" behind authentication (mirroring the authenticated extended card pattern of ); the hash commitment prevents substitution of the specification after disclosure.

Discovery: the pact.json Well-Known URI An origin advertising PACT capability publishes a JSON document at the well-known URI path "/.well-known/pact.json" containing at minimum:

pactVersion:: REQUIRED. Supported protocol version(s).
roles:: REQUIRED. Array: "buyer", "seller", or both.
verification_tiers:: REQUIRED. Supported tiers ().
settlement:: REQUIRED. Supported settlement bindings.
channels:: OPTIONAL. Boolean; Contract Channel support.
min_bond_pct:: OPTIONAL. Minimum bond as percent of price.
attestation_jwks:: OPTIONAL. URI of the key set used to sign Work Attestations.

Naming note: the well-known name "pact.json" is unrelated to the artifact files of the Pact consumer-contract-testing framework, to the Pact smart-contract language, and to the AgentPact agent-node network, none of which occupies a well-known URI; no registry conflict exists.

Verification Methods This document defines four initial Verification Tiers. The tier governs what constitutes a valid fraud proof ().

T0-reexec:: Deterministic re-execution. The work product is recomputable; a fraud proof is a failing re-execution transcript. Suitable for code, data transformation, and other reproducible tasks.
T1-tee:: Attested execution. The Seller Agent executes within a trusted execution environment; delivery includes a remote-attestation quote binding program, input, and output. Attestation Evidence and Attestation Results MUST be conveyed as Entity Attestation Tokens under the RATS architecture , with the Facilitator or Arbiter acting as RATS Relying Party. A fraud proof is an invalid or mismatched attestation.
T2-zkml:: Zero-knowledge proof of inference. Delivery includes a succinct proof that a committed model produced the output from the committed input. A fraud proof is a failed proof verification. At the time of this writing, proof generation is practical for models up to roughly the 1B-parameter class; layerwise and sampled partial verification MAY be used to extend coverage.
T3-jury:: Staked arbitration. The named Arbiter (a panel of staked jurors, human or machine) rules on subjective criteria; jurors on the losing side of the ruling are slashed.

Additional tiers can be registered through the registry established in .

Settlement Bindings A settlement binding maps VTC lifecycle events (lock, release, slash, close) onto a payment system. This document defines:

pact-escrow:: An x402 payment scheme (in the v2 sense: schemes define payment formation, verification, and settlement semantics; extensions are non-payment add-ons) in which a Facilitator holds funds under a conditional-release predicate keyed to VTC events, evaluated at the facilitator "/verify" and "/settle" interfaces with phase-dependent amounts (following the precedent of the "upto" scheme) and CAIP-2 network identifiers. The predicate MUST enforce the challenge window. This scheme is aligned with the deferred-settlement direction in the x402 ecosystem (escrow deposit, off-chain vouchers, batch redemption) and with the community escrow-scheme proposal; it adds what neither provides: release gated on verified work, bonds, and slashing.
ap2-mandate:: A binding in which release is additionally gated on presentation of a valid AP2 Payment Mandate , for contracts whose buyer-side authority originates from a human payment delegation.

Settlement bindings are rail-agnostic by design: bindings for other machine-payment rails (for example, the Stripe/Tempo Machine Payments Protocol ) or conventional payment systems follow the same lifecycle mapping and are out of scope for this document. Escrowed funds SHOULD be held in an instrument (for example, an on-chain contract) that the Facilitator cannot unilaterally redirect, preserving the property that the Facilitator executes the VTC's terms without discretionary control over funds.

Contract Trees and Liability A VTC MAY name a "parent" contract, forming a contract tree. The following invariants apply:

A child contract's deadline MUST NOT exceed its parent's.
The seller of a parent contract is the buyer of its children.
A successful fraud proof or arbitration loss at a child node slashes the child seller's bond; if the resulting remedy is insufficient to cure the parent's obligations, the parent seller's bond is exposed in turn (cascade).
The Work Attestation of a parent contract MUST include a Merkle commitment over the attestation hashes of all its children, so that a single root attestation proves the delegation tree.

Work Attestations and Reputation A Work Attestation is a JSON object recording: the VTC id and hash, the settlement outcome (settled, cured, slashed, arbitrated), the amounts, timestamps, and the tree commitment of , signed by both parties (JWS over JCS). Reputation in PACT is defined as the set of an agent's Work Attestations. Because attestations are emitted only upon facilitated settlement (), fabricating a favorable history requires funding real, bonded, fee-bearing contracts, making Sybil and wash-trading attacks economically bounded (). Agents SHOULD support selective-disclosure presentation of attestation aggregates (e.g., SD-JWT or BBS-based proofs ) so that track records can be proven without revealing counterparties. Attestations MAY additionally be exported into portable passport formats such as ATEP or anchored in on-chain registries such as ERC-8004 .

Contract Channels Two agents anticipating repeated dealings MAY open a Contract Channel: a master VTC that locks an aggregate escrow and fixes standing terms. Individual micro-contracts within the channel are formed and settled by exchanging signed channel states off-ledger; either party MAY close the channel by presenting the latest mutually signed state to the Facilitator, which nets and settles the balance. Channel state MUST be strictly monotonic (sequence-numbered) and each state MUST be signed by both parties. Because a stale channel state can be presented while a party is offline, a channel party MUST be able to delegate challenge-window monitoring to a third party (a watchtower), and challenge windows SHOULD be sized to tolerate expected participant downtime. The construction follows the generalized state-channel literature .

Security Considerations Adversarial negotiation. Free-form inter-agent negotiation exposes agents to persuasion and prompt-injection attacks by their counterparties. PACT's sealed-bid second-price award () removes the strategic value of such manipulation for the award itself. Task specifications MUST be treated as untrusted data, never as instructions. Auction manipulation. Second-price awards carry known attack surfaces . Loser collusion and bid rotation raise clearing prices; bond costs and attestation-weighted bidder eligibility raise the price of sustained cartels. The Buyer Agent, which conducts the award, MUST NOT be able to introduce or alter a bid after observing others: the bid-commitment requirement of exists to prevent shill insertion of a price-setting second bid, and TEE-sealed bidding MAY be used for stronger guarantees. False-name (Sybil) bidding yields no advantage in single-item second-price awards ; it does in combinatorial awards, which is why bundle auctions are out of scope for this version. Sybil and wash trading. Reputation derives only from settled, bonded, fee-bearing contracts (). Facilitator and arbiter fees, bond opportunity cost, and Merkle-committed counterparty diversity raise the cost of manufactured histories. Verifiers of reputation SHOULD weight attestations by counterparty distinctness and settled value. Facilitator compromise. The Facilitator executes but does not adjudicate; it MUST NOT exercise discretion over award or adjudication outcomes, and it MUST publish an auditable log of locks, releases, and slashes. Multi-facilitator escrow (threshold release) is RECOMMENDED for high-value contracts. Verifier and oracle risk. T1 inherits the trust model of the TEE vendor; T2 inherits the soundness of the proof system; T3 inherits the incentive design of the jury. The VTC's tier choice is a security parameter and MUST be explicit. Griefing. Every challenge MUST carry a challenger stake, forfeited if the challenge fails; this bounds the cost that frivolous challenges can impose on honest sellers. Market-level failure. Implementations SHOULD support velocity caps and position limits per identity, and SHOULD subscribe to revocation and risk events using the OpenID Shared Signals Framework 1.0 and CAEP 1.0 (Final Specifications) , permitting mid-contract suspension of a compromised counterparty.

Privacy Considerations VTCs commit to task content by hash; the content itself need not be disclosed to facilitators, arbiters (absent a dispute), or registries. Selective-disclosure attestation proofs () permit reputation without counterparty disclosure. Channel micro-contracts are visible only to the channel parties until close.

IANA Considerations This document requests registration of:

The well-known URI "pact.json" in the "Well-Known URIs" registry . URI suffix: "pact.json"; change controller: IETF; reference: of this document.
The media types "application/pact-contract+json" (the VTC, ), "application/pact-attestation+json" (), "application/pact-cfb+json", and "application/pact-bid+json" (), per the procedures of .
A new "PACT Verification Tiers" registry with initial entries T0-reexec, T1-tee, T2-zkml, T3-jury (); registration policy Specification Required .
A new "PACT Settlement Bindings" registry with initial entries pact-escrow and ap2-mandate (); registration policy Specification Required .