| Internet-Draft | PACT | July 2026 |
| Sharma | Expires 28 January 2027 | [Page] |
Existing agent interoperability protocols move tasks (A2A) and money (x402, AP2) but provide no mechanism that binds work to payment to proof of completion. This document specifies PACT (Propose, Agree, Complete, Trust), an application-layer contract protocol for commerce between autonomous agents. PACT defines (1) a sealed-bid second-price task-award procedure; (2) the Verifiable Task Contract (VTC), a signed JSON object binding parties, scope, price, verification method, and liability; (3) escrowed, optimistically released settlement with a fraud-proof challenge window; (4) graded verification methods ranging from deterministic re-execution to zero-knowledge proofs of inference and staked arbitration; and (5) co-signed Work Attestations from which agent reputation is derived as a byproduct of settlement. PACT composes existing primitives: Decentralized Identifiers, JSON Web Signatures, OAuth token-exchange delegation chains, the x402 payment protocol, and AP2 mandates.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
PACT proceeds in four phases: Propose, Agree, Complete, Trust.¶
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 Section 12). 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 Section 12 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 Section 5.1 and Section 5.2), "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 Section 14. Note that these protocol messages are distinct from the static capability document of Section 6.¶
The Buyer Agent and the awarded Seller Agent construct a VTC (Section 5). Both parties MUST sign the JCS-canonicalized [RFC8785] VTC using JWS [RFC7515]. The Buyer Agent then locks the contract price with a Facilitator using a conditional-settlement binding (Section 8), 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 [RFC8693], and payment authorization MAY additionally be represented by an AP2 Intent or Cart Mandate [AP2].¶
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 [LUU15] [TRUEBIT]); 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.¶
Upon expiry of the final challenge window, the Facilitator closes escrow and both parties exchange co-signed Work Attestations (Section 10). An implementation MUST NOT emit a Work Attestation for a contract that did not reach settlement through a Facilitator.¶
A VTC is a JSON object with the following top-level members:¶
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-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 [RFC6920] MAY be used for interoperable hash naming. Content dereferenced from "spec_uri" is integrity-protected by the hash, not by its transport.¶
The content committed by "spec_hash" is a TaskSpec: a JSON object, canonicalized with JCS [RFC8785] before hashing, with the following members:¶
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 [A2A]); the hash commitment prevents substitution of the specification after disclosure.¶
An origin advertising PACT capability publishes a JSON document at the well-known URI [RFC8615] path "/.well-known/pact.json" containing at minimum:¶
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.¶
This document defines four initial Verification Tiers. The tier governs what constitutes a valid fraud proof (Section 4.3).¶
Additional tiers can be registered through the registry established in Section 14.¶
A settlement binding maps VTC lifecycle events (lock, release, slash, close) onto a payment system. This document defines:¶
Settlement bindings are rail-agnostic by design: bindings for other machine-payment rails (for example, the Stripe/Tempo Machine Payments Protocol [MPP]) 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.¶
A VTC MAY name a "parent" contract, forming a contract tree. The following invariants apply:¶
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 Section 9, 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 (Section 4.4), fabricating a favorable history requires funding real, bonded, fee-bearing contracts, making Sybil and wash-trading attacks economically bounded (Section 12). Agents SHOULD support selective-disclosure presentation of attestation aggregates (e.g., SD-JWT [RFC9901] or BBS-based proofs [BBS]) so that track records can be proven without revealing counterparties. Attestations MAY additionally be exported into portable passport formats such as ATEP [ATEP] or anchored in on-chain registries such as ERC-8004 [ERC8004].¶
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 [PERUN].¶
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 (Section 4.1) 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 [LONELY]. 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 Section 4.1 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 [YOKOO]; 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 (Section 10). 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) [SSF], permitting mid-contract suspension of a compromised counterparty.¶
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 (Section 10) permit reputation without counterparty disclosure. Channel micro-contracts are visible only to the channel parties until close.¶
This document requests registration of:¶