Independent

laxsharma79@gmail.com

autonomous agents agent commerce escrow liability verification A growing family of specifications lets autonomous agents establish identity, delegate authority, record what they did, and move money. None of them makes one party financially answerable to another for a result that was not delivered. This document specifies PACT, which adds liability as a required, co-signed member of an agent contract and propagates it through a subcontract tree. PACT defines the Verifiable Task Contract, a signed JSON object binding parties, scope, price, verification profile, and an explicit allocation of liability; the Delivery object that a contract is judged against; an escrowed settlement procedure whose release is conditioned on a stated assurance level rather than on elapsed time; and a subcontract tree in which a parent's Work Attestation commits to its children by Merkle root and liability cascades upward. PACT does not define an identity format, an authorization model, an audit architecture, a transparency service, a payment rail, or a reputation system. It composes existing work for all of these. Its settlement loop is an instance of optimistic fair exchange, and its bond-sizing rule is the classical deterrence bound; both are cited rather than reintroduced.

Introduction

Motivation By late 2026 an autonomous agent can prove who it is, show whose authority it acts under, discover another agent, call it, record what happened in a tamper-evident receipt, and pay for the call. Each of those is the subject of active standardisation, and several are specified in more detail than this document specifies anything. What no specification in that family states is who owes whom, and how much, when the work is wrong. Receipts record that an action occurred. Audit records establish whether behaviour matched intent. Payment schemes move value on the payer's instruction. None of them binds a party to a consequence. That gap is not an oversight in those documents; it is outside their scope, and correctly so. It is the gap this document addresses.

What This Document Specifies, and What It Does Not PACT specifies exactly four things: liability as a required member of a co-signed contract object (); the Delivery object against which that contract is judged (); a settlement procedure whose release is conditioned on a declared assurance level (); and a subcontract tree through which liability cascades (). Everything else PACT needs, it composes and cites. In particular this document does not specify, and implementations MUST obtain elsewhere: agent identity and key distribution; delegation of authority from a human or organisational principal; agent discovery; a transport; an audit or accountability architecture; a transparency service; a payment rail or settlement network; a general reputation system; or a dispute forum. Two mechanisms present in have been removed rather than revised. Contract channels are withdrawn because the -00 text specified no channel state object, no sequence rule, and no termination condition, and payment channels for agent commerce are specified elsewhere. The sealed-bid second-price award procedure is withdrawn from this document because it is separable from settlement, is fully treated in the multi-agent systems literature, and made the -00 a document about two unrelated things. Neither removal is a judgement that the mechanism is wrong.

Relationship to Existing Work PACT's agree, perform, verify, settle loop is an instance of optimistic fair exchange , in which a third party is contacted only when the exchange fails. The revocable-item case, developed in , in which value moves and is later reversed on a third party's affidavit, is optimistic release in substance. What that literature establishes is what a third party must be able to do for an exchange to be fair. What it does not address, and what addresses, is who pays to produce the evidence a dispute is decided on. The bond-sizing rule in is the classical deterrence bound. It is stated for public enforcement generally in , which traces it to Bentham, and for outsourced computation specifically in , whose Theorem 1 sets a fine-to-reward ratio of (1-p)/p, where p is the probability that an incorrect result is checked, with the fine posted in advance as a deposit. It is stated for rollup validators in . This document adds one term to it, for value released before verification concludes, and claims nothing further. Two adjacent Internet-Drafts address agent commerce settlement directly. carries Work Completion Records and an audit-verified settlement timing; binds verified commerce settlement to the Agent Payments Protocol. Neither allocates liability between the parties, and PACT is designed to be usable alongside either. Verification evidence formats are specified in and . Signed, hash-chained action receipts , composition of accountability records , delegation chains , and contestability bindings are each specified elsewhere, and PACT consumes rather than restates them.

The Experiment This document is Experimental. The question it tests is whether a settlement layer that makes liability a co-signed contract term, and conditions release on a declared detection probability rather than on elapsed time, can be implemented independently by more than one party and produce settlements each can verify. The experiment succeeds if two independent Facilitator implementations settle contracts whose Buyers and Sellers use different client implementations, through every terminal state in , with attestations either can check. It fails, and that would itself be a result worth recording, if the constraint in proves unworkable at the prices and verification costs real deployments exhibit. Experience should be reported to the author and to the repository named in .

Changes from -00 This revision is a narrowing. The -00 attempted the surface area of a protocol suite in under five thousand words and did not close. Substantive changes:

• Liability is promoted from a member of the contract to the subject of the document ().
• A Delivery object is added. The -00 specified no object for the thing being judged, so absent evidence was not a fraud proof and non-delivery had no remedy ().
• The remedy waterfall is reordered to pay restitution before any bounty or burn. Under the -00 a defrauded buyer recovered nothing from a slashed bond ().
• Release is conditioned on a declared assurance level, and on-verification replaces optimistic release as the default and the only mode required of conformant implementations ().
• An Assurance Constraint is stated that a facilitator can check before locking funds ().
• Bond release on contract finality is specified. The -00 had no rule returning a seller's bond.
• Subcontract finality is bottom-up, resolving the -00's requirement that a parent commit to child attestations that could not yet exist ().
• Protocol endpoints are specified. The -00 defined objects and no operations, so no two implementations could exchange a message ().
• Conformance requirements are stated (). Several rules enforced by the reference validator for -00 had no normative text, including the JWS algorithm allowlist, which left an implementation built from the document alone open to algorithm confusion.
• A worked example is carried in the document and committed by hash (). The -00 contained no numeric example and no digest, so it made no verifiable claim about its own reference implementation.
• Contract channels and the sealed-bid award procedure are removed ().

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. All JSON objects defined here are canonicalized with JCS before hashing or signing. Implementations MUST order object keys by UTF-16 code unit as Section 3.2.3 requires. Sorting by Unicode code point is a common substitution; it agrees with the required order throughout the Basic Multilingual Plane and diverges above it. Version. The pact member carries a version of the form major.minor; this document defines 0.1. Every object defined here is hash-committed and signed, so a member an implementation does not recognise is inside the commitment and cannot be ignored safely. An implementation MUST reject an object whose pact version it does not implement, and MUST reject an object carrying a member this document does not define for it. Extension is by a new version, not by adding members. Time. Every timestamp is an RFC 3339 date-time in UTC with the "Z" designator. The Facilitator's clock governs every deadline and window in this document: the instant at which the Facilitator records an object is the instant that counts, and parties SHOULD allow for skew when acting near a boundary. Money. An amount is a decimal string with no exponent and a fractional part of two to eighteen digits; comparisons are exact and no rounding is implied. A currency is an asset identifier whose namespace is defined by the settlement binding named in price.settlement, and need not be an ISO 4217 code. A network is a ledger identifier in the form the same binding defines; the pact-escrow binding uses chain identifiers.

Terminology

Buyer:

The party that commissions work and locks the price.

Seller:

The party that performs the work and posts the Bond.

Facilitator:

A service that holds value and executes the contract's settlement terms without discretion over its outcome. It checks that objects conform and applies rules fixed in advance. It MUST NOT decide whether delivered work was acceptable; that is the Verifier's role, and a Facilitator MUST NOT act as Verifier for a contract it settles.

Verifier:

The party that evaluates a Delivery against the committed acceptance instrument for release purposes. Independence requirements are in .

Challenger:

Any party that submits a fraud proof within the challenge window.

Bond:

Seller-posted collateral, sized per , from which restitution and penalties are paid.

Verification Fund:

Value posted at Agree, separate from the Bond, that pays for verification actually performed.

VTC:

Verifiable Task Contract ().

Delivery:

The object a Seller submits, and the only object a contract is judged against ().

Verdict:

A signed statement by a Verifier that a Delivery was evaluated against the committed instrument, and with what outcome ().

Challenge:

A signed fraud proof submitted within the challenge window ().

Work Attestation:

The Facilitator-signed record of a contract's terminal outcome ().

Protocol Overview A contract passes through four phases. Propose establishes terms. Agree co-signs them and funds the three value pools. Complete produces a Delivery and a Verdict on it. Trust records what happened in a Work Attestation. The ordering below is normative; in particular a Verdict precedes release under the default release mode.

Contract flow under the default on-verification release mode | | | | | | |--- lock(P) ------>| | | | |<--- bond(B) ----| | | |<--- fund(F) ----| | | | | | | | [ Seller performs ] | | | | | | |<-- Delivery ----| | | | | | | |-- Delivery + criteria_hash ---->| | |<-- Verdict (signed) ------------| | | | | | |-- release(P) -->| | | | [ window ] [ children final ] | | |-- return(B,F) ->| | | | | | |<-- Attestation ---|-- Attestation ->| | ]]>

The challenge window opens when the Verdict is recorded under on-verification release, and when the contract enters DELIVERED under on-window and optimistic release; it closes challenge.window_seconds later by the Facilitator's clock. Under on-verification the Buyer's price is released once the Verdict is PASS; the Bond is not returned until the window closes and every descendant contract is final ().

Contract states under on-verification release | ABANDONED | +------------+ no Delivery +-----------+ | Delivery accepted v +------------+ | DELIVERED | +------------+ | Verdict recorded +----------+----------+ PASS | | FAIL v v +------------+ +------------+ | RELEASING | | DISPUTED | +------------+ +------------+ | | window | | remedy applied closed, | | (Section 7.4) children v v final +------------+ +------------+ | FINAL | | SETTLED | +------------+ +------------+ ]]>

Under optimistic release DELIVERED proceeds directly to RELEASING and a Verdict, if one arrives, does so inside the window. Under on-window release DELIVERED proceeds to RELEASING when the window closes with no successful Challenge. Under unsecured release DELIVERED proceeds to RELEASING and no window opens. FINAL, SETTLED and ABANDONED are terminal, and each produces a Work Attestation. The -00 had no path to either: expiry of task.deadline had no stated consequence, so escrow could lock permanently, and a negative outcome required the signature of the party it convicted.

The Verifiable Task Contract A VTC is a JSON object, media type application/pact-contract+json, carrying the members below. A VTC is valid only if every REQUIRED member is present, the parties are distinct, and both the Buyer and the Seller have contributed at least one signature that verifies against a key bound to its identifier. The Facilitator and any Verifier do not sign the VTC; their assent is expressed by acting on it, and a Facilitator that will not act on a contract refuses it at .

pact:

REQUIRED. Protocol version.

type:

REQUIRED. The string VerifiableTaskContract.

id:

REQUIRED. Contract identifier, unique for the Facilitator named in settlement.

parties:

REQUIRED. Object with buyer, seller and facilitator identifiers, and OPTIONAL verifier. Buyer and seller MUST differ. Where verifier is absent, the Verdict MUST come from a party satisfying .

task:

REQUIRED. Object with spec_hash, deadline, and OPTIONAL spec_uri.

price:

REQUIRED. Object with amount, currency, settlement binding identifier, and network.

verification:

REQUIRED. Object with tier, profile (), criteria_hash, and OPTIONAL arbiter.

assurance:

REQUIRED. Object with mode and q_min ().

release:

REQUIRED. Release mode (). Absent an explicit value a Facilitator MUST treat the contract as on-verification.

liability:

REQUIRED ().

challenge:

REQUIRED. Object with window_seconds, which MUST be greater than zero, and max_dispute_seconds.

signatures:

REQUIRED. Array of JWS signatures over the JCS-canonical form of the VTC excluding the signatures member, per .

The settlement identifier, the network and the asset are all carried inside price so that a co-signed VTC is bound to one venue. The -00 omitted them, which made a signed contract replayable against any facilitator, chain or token contract.

A Verifiable Task Contract, signatures abbreviated

Hash values are wrapped here for page width only; they are single JSON strings with no embedded whitespace.

Hash Commitments and Content Conveyance Every URI carried inside hash-committed content MUST be accompanied by a sibling hash over the dereferenced bytes. The -00 committed harness_uri as a string while leaving the bytes at that URI uncommitted, which permitted a Buyer to substitute the acceptance instrument after signature, run the substituted instrument, and submit the failure as a valid fraud proof. Where the committed content is a bundle of files rather than a single octet stream, the commitment MUST be computed as SHA-256(JCS(M)) where M is an object mapping each file's path, relative to the bundle root and expressed with "/" separators, to SHA-256 of its bytes. A manifest of per-file digests is specified rather than an archive digest because archive formats carry ordering, timestamp and permission metadata that is not stable across producers.

The Task Specification The content committed by spec_hash is a TaskSpec: a JSON object, canonicalized per before hashing, with the members below.

description:

REQUIRED. Natural-language statement of the work.

inputs:

OPTIONAL. Object carrying schema_uri with its schema_hash, and where a representative sample is published, sample_uri with its sample_hash.

deliverable:

REQUIRED. Output format and schema_uri with schema_hash.

acceptance:

REQUIRED. The verification instrument, with members conditional on tier as below, plus machine-readable thresholds and harness_hash equal to the contract's criteria_hash.

constraints:

OPTIONAL. Tool prohibitions, confidentiality and compliance conditions.

The acceptance object MUST carry the members REQUIRED for the contract's tier: harness_uri and harness_hash for re-execution tiers, enclave and model policy for attestation tiers, a proof statement with its verifying key for proving tiers, or rubric_uri and rubric_hash for judgment tiers. An empty acceptance object MUST be rejected. The -00's schema permitted one, which made every fraud proof impossible and quietly converted conditional release into unconditional payment. Thresholds MUST be stated so that they cannot be satisfied by returning almost nothing. A threshold expressed only as a rate over returned rows is satisfied by returning one correct row out of millions; a completeness condition relative to the committed input is therefore REQUIRED wherever the deliverable is a transformation of that input.

Liability The liability member is REQUIRED in a VTC. It states, in advance and with both parties' signatures over it, what each party owes the other when the contract is not performed. A contract that does not allocate liability is not a PACT contract.

seller_bond:

REQUIRED. Collateral the Seller posts before performance, sized per . It is the source of restitution, not a fine.

verification_fund:

REQUIRED. Value posted at Agree that pays for verification actually performed and for a successful Challenger's documented costs. It is separate from the Bond because paying verifiers out of the Bond caps reimbursement at the Bond, which for any re-execution profile is an order of magnitude too little.

cap:

REQUIRED. The maximum protocol-native remedy. A Facilitator MUST NOT move more than cap from the Seller under this contract.

restitution_basis:

REQUIRED. One of released, restoring the Buyer up to value already released, or price, restoring the full price. Determines the second rank of the waterfall in .

parent:

OPTIONAL. Present only in a subcontract. Object with the parent's vtc_id and vtc_hash ().

remainder_to:

OPTIONAL. Where slashed value remaining after rank 4 of is directed: buyer or sink. Absent, sink. A sink is a Facilitator-designated destination that is not a party to the contract. buyer is permitted but rewards a Buyer beyond its loss, which is an incentive to manufacture challenges; the default exists for that reason.

Liability under PACT is bounded by cap and is discharged in the contract's own currency. This document creates no cause of action and displaces no other remedy: consequential loss beyond cap, and any obligation arising outside this contract, are out of band. A specification that implied otherwise would be claiming to settle questions it has no standing to settle. A parent member is authenticated not by a separate countersignature but by the rule in : the child's Buyer must be the parent's Seller. Since liability is inside the bytes the Buyer signs, the Buyer's signature on the child is itself the authorisation to attach it.

The Delivery Object The Delivery is the object a contract is judged against. The -00 specified none, with three consequences: a Seller that attached no evidence presented nothing that could be shown invalid, so absence of evidence was not a fraud proof; release fired on "delivery", an event the Facilitator had no defined way to observe; and non-delivery had no remedy at all, so escrow could lock permanently. A Delivery is a JSON object, media type application/pact-delivery+json.

pact, type:

REQUIRED. Version, and the string Delivery.

vtc_id, vtc_hash:

REQUIRED. Identify and commit to the contract being performed. vtc_hash is computed over the JCS-canonical VTC including its signatures member, so the commitment covers who agreed and not merely what was written.

work_hash:

REQUIRED. Digest over the delivered bytes, or a manifest digest per where the deliverable is a bundle.

work_uri:

OPTIONAL. Where the bytes may be fetched. Integrity comes from work_hash, never from the transport.

input_hash:

REQUIRED for tiers whose fraud proof re-executes. Commits the production input actually consumed. Without it a Challenger chooses what to re-execute against and an honest Seller can be convicted on an input it never saw.

evidence:

REQUIRED. Object whose members are profiled by verification.tier. Its conformance to the tier profile is a validity condition, not a quality judgement.

signature:

REQUIRED. Seller JWS over the JCS-canonical Delivery excluding this member.

A Facilitator MUST reject a Delivery whose evidence is absent or does not conform to the profile named in the VTC, and MUST apply as though a FAIL Verdict had been recorded. This is a conformance rejection, not a judgement on the work: the Facilitator has checked shape, not substance, which is why it does not breach the separation in . This is the rule that makes silence expensive: under the -00 the cheapest attack was to deliver nothing verifiable and be paid anyway. Where task.deadline passes with no conformant Delivery recorded, the Facilitator MUST move the contract to ABANDONED, return the escrowed price to the Buyer, and slash the Bond to the extent of liability.restitution_basis. No challenge window opens, because there is nothing to challenge.

A Delivery for a T0-reexec contract, acceptance profile

A Buyer countersignature over the same canonical bytes constitutes a receipt and moves the contract to DELIVERED without waiting for the Facilitator's own conformance check. A Buyer is not obliged to countersign, and withholding a countersignature is not a Verdict.

Settlement

Value Pools A contract funds three pools, which the -00 conflated into one. The Escrow holds the Buyer's price. The Bond is Seller collateral and is the source of restitution. The Verification Fund pays for verification performed and for a successful Challenger's documented costs. Separating the second and third is not tidiness. Under the -00 a Challenger was reimbursed from the slashed Bond, so reimbursement was capped by the Bond; for any re-execution profile the cost of producing a fraud proof approximates the cost of the work itself, which exceeds any plausible fraction of a Bond by roughly an order of magnitude. The -00's MUST to reimburse documented verification costs was therefore unsatisfiable in the ordinary case.

The three pools and which waterfall rank draws on which Buyer | 2 | | costs <------|-> Challenger 3 | |-- restitution -> Buyer 4 | |-- bounty -----> Challenger 5 | |-- remainder --> remainder_to ]]>

A Facilitator MUST NOT permit cumulative release before a recorded Verdict to exceed the Bond. Value released before verification is value the mechanism can no longer recover, so releasing more than the Bond makes defection profitable by construction, independently of every other parameter.

The Assurance Constraint Let P be the price, C the Seller's cost of performing honestly, B the Bond, E the cumulative amount released before a Verdict is recorded, and q the probability that a defection is detected, proven, and adjudicated within the contract's own time bounds. Honest performance is a Seller's best response exactly when: = C ]]> A Facilitator cannot evaluate that directly, because C is private to the Seller. It can evaluate a sufficient condition. A Seller that bids rationally has C no greater than P, so requiring the expected recoverable exposure to cover P suffices, and gives a constraint in observable quantities alone: = P * (1 - q) / q + E ]]> A Facilitator MUST evaluate this constraint against the contract's declared assurance.q_min before locking funds, and MUST refuse a contract that does not satisfy it. Read as a requirement on q rather than on B, and with E set to zero, this is q at least P/(P+B). A Bond of ten percent of price, the conventional figure, is therefore a wager that better than nine in ten defections are detected and proven and adjudicated in time. The -00 stated no such requirement and funded no mechanism that would produce such a rate. This inequality is not new and is not claimed as new. It is the classical deterrence bound, stated for public enforcement in , which traces it to Bentham, and for outsourced computation, with the fine posted in advance as a deposit held by the principal, in Theorem 1. Its form for rollup validators is . The only term this document contributes is E. Every prior statement withholds the reward until checking has had its opportunity, so none of them has a notion of value released before verification concludes. Optimistic release both pays a defecting Seller and puts that payment beyond recovery, so the required Bond rises with it one for one. That is why a contract can satisfy the classical bound at Agree and violate it by the time judgment arrives. The assurance.mode member states how q is produced:

certain:

Every Delivery is verified before release. q is 1 by construction.

committed-sample:

A declared fraction, sample_rate, is verified. The draw MUST derive from a Buyer seed committed before the Delivery is submitted, combined with the Delivery commitment, so that neither party can bias which contracts are checked.

open:

Detection relies on third-party challenge. A contract MUST NOT declare open as its sole source of assurance. Open challenge is a backstop against verifier failure, not a source of q: no party is obliged to look, and shows that a bounded reward is dominated by silence.

Release Modes The release member takes one of four values. A conformant Facilitator MUST implement on-verification; the others are OPTIONAL.

on-verification:

REQUIRED to implement, and the default. Release follows a recorded PASS Verdict.

on-window:

Release follows expiry of the challenge window, which opens at DELIVERED, with no successful Challenge.

optimistic:

Release follows Delivery, before any Verdict, subject to the cap in .

unsecured:

Release follows Delivery with no bound tying released value to the Bond. This is the honest name for extending credit to a counterparty. A Facilitator MUST record it as such, and no protocol-native remedy exists above the Bond for the unsecured portion.

The -00 made optimistic release the only mode. Its benefit to the Seller is the time value of the price over the challenge window; its cost is the carry on collateral sized to make it safe. On ordinary parameters the second exceeds the first by more than an order of magnitude, so correctly collateralized optimistic release is close to a null transaction and under-collateralized it is a transfer from Buyer to defecting Seller. It is retained as an option because some deployments will want it, and named honestly.

Challenge and Remedy On a FAIL Verdict or a successful challenge, a Facilitator MUST apply the following in order, and MUST NOT proceed to a later rank while an earlier one is unsatisfied:

1. Reverse any unreleased escrow to the Buyer.
2. Reimburse the successful Challenger's documented verification and submission costs, from the Verification Fund.
3. Restore the Buyer from the Bond, up to liability.restitution_basis.
4. Pay the Challenger bounty from the remaining Bond.
5. Direct any remainder per liability.remainder_to.

Ranks 2 and 3 are the correction of the -00, whose waterfall paid the Challenger and then directed the remainder to a neutral sink "rather than to any party to the dispute". Since the Buyer is a party to the dispute, a defrauded Buyer recovered nothing. That mechanism binds work to punishment, not work to payment, and the words restitution, refund, compensation and damages appeared nowhere in it. The bounty at rank 4 MUST NOT be capped at a fraction of the Bond chosen for tidiness. Let X be the Seller's exposure at judgment, the Bond plus unreleased price. A party that discovers a fraud and reports it receives the bounty; a Seller facing X will pay up to X to avoid judgment. Wherever the bounty is less than X there exists a private payment leaving both strictly better off than reporting, so silence dominates the designed mechanism. Theorem 6 gives the corresponding lower bound in its own setting: a bounty of at least r/(1-a), where r is the reward and a is the accuracy a cheating contractor can reach by cheaper means, so never less than the reward itself. The symbol a is used here to avoid a collision with this document's q. Raising the bounty to X is not the answer either, since that leaves nothing for rank 3 and maximises the incentive to manufacture challenges. Two mitigations are specified instead. The reward MUST be non-exclusive: where K parties independently discover the same fraud each receives the full bounty, so buying silence costs K times what reporting pays once. And the Buyer MUST be admissible as a Challenger in its own contract, since a Buyer that recovers restitution by challenging will not accept a bribe below the restitution it forgoes, which places a floor under any bribe a Seller must pay.

The dispute path: a Challenge overturns a PASS Verdict Seller | | | [ window opens ] | | |<------------- Challenge --------| | |-- Challenge + Delivery -------->| | |<-- Verdict FAIL | | | | (supersedes PASS) | |<- rank 1 ----| unreleased escrow | | |-- rank 2 (from F) ------------->| |<- rank 3 ----| restitution (from B) | | |-- rank 4 (from B) ------------->| | |-- rank 5 --> remainder_to | | | SETTLED, Attestation issued | ]]>

The Challenge Object A Challenge is a JSON object, media type application/pact-challenge+json, by which any party submits a fraud proof within the window. Members: pact, type (the string Challenge), vtc_id, delivery_hash, a proof object whose members are profiled by verification.profile, and the Challenger's signature. A Facilitator MUST reject a Challenge received outside the window, one whose proof does not conform to the profile, or one whose delivery_hash does not match the recorded Delivery. A Challenge that is accepted is evaluated by a party satisfying , whose finding is a Verdict; the Challenger's own assertion is not. The Challenger is the party identified by the kid of the Challenge's signature. A Verdict issued on a Challenge supersedes any earlier Verdict on the same Delivery, and a Facilitator MUST record both. A Facilitator MAY require a deposit with each Challenge, stated as challenge_deposit in its capability document (), returned if the Challenge succeeds and forfeited to the Verification Fund if it does not; this is the protocol's defence against challenge spam, and discusses its limits.

A Challenge under the acceptance profile

Bond Release The Bond enters the -00 in its Phase A and never leaves it: no rule anywhere returns it. A Facilitator MUST return the Bond, less any amount applied under , when the contract reaches FINAL or SETTLED, and MUST record the return. It MUST NOT return the Bond while any descendant contract remains non-final (), because cascading liability requires the parent's collateral to remain exposed until the subtree has settled.

Facilitator Capability Discovery Before a Buyer and Seller can co-sign a VTC they must agree on a Facilitator and know what it supports. This document registers one well-known URI for that purpose, per . This is deliberately narrower than agent discovery, which is the subject of separate work and is not restated here. What is discovered is a settlement service's capabilities, not an agent's identity, skills, or endpoints. A Facilitator SHOULD publish a JSON document, media type application/pact-facilitator+json, at the path /.well-known/pact-facilitator of its origin. The document MUST be served over HTTPS. It MUST be signed, and the signature MUST verify against a key bound to the identifier in facilitator. An unsigned capability document is not usable for contract formation, because the members below determine what a party is agreeing to when it signs.

facilitator:

REQUIRED. The identifier that will appear in parties.facilitator.

settlement_bindings:

REQUIRED. Array of binding identifiers, each with the networks and assets it serves.

release_modes:

REQUIRED. Array of supported modes; MUST contain on-verification.

verification_profiles:

REQUIRED. Array of supported profiles from the registry in .

assurance_modes:

REQUIRED. Array of supported modes.

max_contract_value:

OPTIONAL. Object with amount and currency.

challenge_deposit:

OPTIONAL. Object with amount and currency, required with each Challenge (). Absent, no deposit is required.

endpoints:

REQUIRED. Object mapping each endpoint name in to an absolute URI.

signature:

REQUIRED. JWS over the JCS-canonical document excluding this member.

https://settle.example/.well-known/pact-facilitator

A client MUST NOT infer any capability from the absence of a member. A Facilitator that does not publish a capability document can still be named in a VTC by prior arrangement; discovery is a convenience, not a precondition.

Verification Profiles A contract names both a tier, which says what class of evidence is produced, and a profile, which says what is actually done to check it. Four tier labels are used in this document: T0-reexec, deterministic re-execution; T1-tee, hardware attestation per ; T2-zkml, a proof of inference; and T3-jury, staked arbitration. Tiers are a vocabulary, not a registry; profiles are the registered quantity (). The distinction matters because the tier name does not determine the security of the contract and the profile largely does. Consider one task, a bulk data transformation, under two profiles at the same nominal tier. Re-executing the whole computation and comparing outputs costs approximately what performing it cost. Running a committed acceptance instrument against the delivered artifact costs a small fraction of a percent. Those two differ by more than two orders of magnitude in what verification costs relative to the price, and by they give opposite answers about whether any Bond a Seller would post makes third-party challenge rational. Three regimes follow, and the boundaries are consequences of rather than stipulations. Where verification costs a small fraction of a percent of price, every Delivery can be checked, assurance.mode of certain is affordable, and the Bond need only cover harm. Where it is of order one percent, sampling is efficient but the Bond required to sustain a low fraud rate approaches the price. Where it exceeds roughly ten percent, no Bond a Seller would rationally post makes third-party challenge worthwhile, and a contract at that profile MUST NOT declare open assurance, because it would be declaring a detection probability nothing produces. Implementations SHOULD select the cheapest profile that detects the failures they actually care about, rather than the strongest-sounding one. A committed acceptance instrument that is adequate is worth more than a re-execution profile that nobody can afford to run.

acceptance:

Run the instrument committed by criteria_hash against the Delivery. The fraud proof is a failing evaluation. Deterministic by construction, since the instrument is fixed before work begins.

bisection:

Interactive narrowing to a single disputed step, which is then checked directly. Verification cost grows logarithmically in the size of the computation rather than linearly, which is what makes disputes affordable at scale.

full-reexec:

Re-execute and compare byte for byte. Sound only where the computation is deterministic and the environment is pinned; see .

Verifier Independence Independence is a relation between the attesting party and the parties to the contract. It MUST be derived by the evaluator and MUST NOT be satisfied by a field in which a record declares itself independent. Party identifiers MUST be normalized before comparison, and the normalization MUST fold toward identifying the same party: strip leading and trailing whitespace; lower-case the scheme and, for did:web and https identifiers, the host; remove any fragment (a "#" and everything after it) and any trailing "/" or ".". Percent-encoding MUST NOT be decoded, since an open-ended decoder is its own attack surface. An identifier that does not parse after normalization is not evaluable and MUST NOT be treated as outside the parties. An independence claim reaches exactly as far as the record's own commitments; a settlement-scoped attestation carries no delivery or acceptance evidence. These rules are stated for evaluation after the fact in ; PACT binds them at contract formation, constraining who may be named as Verifier before work begins.

Contract Trees and Cascading Liability An agent that accepts work may subcontract part of it. The subcontract is an ordinary PACT contract whose Buyer is the parent's Seller. What this section adds is the binding between the two, so that a failure below is recoverable above and cannot be hidden.

A contract tree. B is Seller above and Buyer below.

Binding a Child to Its Parent A subcontract carries liability.parent, an object with the parent's vtc_id and vtc_hash. Because liability is inside the bytes both parties sign, the child's Buyer signature is itself the authorisation to attach that child to that parent. A Facilitator MUST verify, before accepting a child contract, that the child's Buyer is the parent's Seller: after the normalization in , where parent is the contract whose canonical form hashes to liability.parent.vtc_hash. A Facilitator MUST reject a child whose parent it cannot resolve and verify. Without this check any party may name any contract as its parent. The attack is cheap and asymmetric: name a competitor's contract as parent, subcontract a trivial task to yourself, fail it, and cause the competitor's Bond to be slashed and its Work Attestation to record a loss. The -00 carried liability.parent as a bare string with no hash and no check, so the attack cost one signature. A Facilitator MUST reject a child whose parent chain already contains the child's own vtc_id, and MUST enforce a maximum tree depth. Absent explicit configuration that maximum is 8. Both limits exist so that resolving a chain terminates.

What Cascades, and What Does Not Liability cascades upward as recovery. It does not cascade downward as discharge. Concretely: when a child fails, its Bond is applied under with the parent's Seller as the Buyer being restored. The parent's Seller may then be in a position to perform, or to settle its own contract from those proceeds. But a Facilitator MUST NOT reduce the parent Seller's obligation to the parent Buyer by reason of a subcontract's failure, and MUST NOT make the parent Buyer's recovery conditional on any child settling. The parent Buyer contracted with the parent Seller and has no privity below it.

A child fails. Recovery flows up; the obligation does not flow down.

This is the rule that stops subcontracting from being a liability laundry. Absent it, a Seller facing a large obligation could subcontract to a thinly capitalised identity it controls, let the child fail, and offer the child's small Bond as the whole remedy. A parent Seller SHOULD ensure that the sum of its children's cap values is at least its own exposure under the parent contract. Where it is not, the parent Seller carries the difference itself. This is stated as advice rather than a requirement because a Seller is entitled to take that risk knowingly; what it is not entitled to do is transfer it to its Buyer without consent.

Finality Is Bottom-Up A parent's Work Attestation MUST carry children_merkle_root, a Merkle root over the attestation hashes of its immediate children, computed as in . A parent therefore cannot be attested until its children have been. The -00 required that same commitment while ordering only task.deadline between parent and child. Challenge windows are not deadlines, so a child whose window outlasted its parent's finalised after the parent, and a conformant implementation deadlocked on its own requirement: commit to an attestation that does not yet exist, or violate the MUST.

The ordering the -00 permitted, and the rule that forbids it

A Facilitator MUST reject a child contract unless the latest instant at which the child can become final precedes the earliest instant at which the parent's challenge window can close: A Facilitator MUST NOT move a contract to FINAL, and MUST NOT return a Bond under , while any descendant remains non-final. Cascading recovery requires the parent's collateral to remain exposed until the subtree has settled; releasing it earlier would make the cascade a rule about value that no longer exists. These two requirements together mean a subcontract must be agreed early enough in the parent's life to finish inside it. That is a real constraint on how deep a tree can be with short windows, and it is stated here rather than discovered at runtime.

Work Attestations A Work Attestation records what a contract did. It is the input to any reputation system built on PACT, though this document defines no such system and takes no position on how the records should be weighed. The -00's attestation recorded that money moved. It named no party, distinguished no role, carried no Facilitator signature, and committed no work product. Three attacks followed, each cheap: present another agent's attestations as your own, since nothing required the presenter to be a signer; present your Buyer records as Seller records, since no role label distinguished payer from performer; or manufacture a history outright with two identities you control, since nothing proved a Facilitator was ever involved.

vtc_id, vtc_hash:

REQUIRED.

parties:

REQUIRED. The same object as the contract's, so that every attestation names its subject and states which side of it each identifier was on.

subject:

REQUIRED. The identifier this attestation is evidence about, which MUST appear in parties.

role:

REQUIRED. The subject's role, one of buyer or seller. A Buyer record and a Seller record are different evidence and MUST NOT be interchangeable.

outcome:

REQUIRED. One of performed, cured, slashed, abandoned.

work_hash:

REQUIRED where a Delivery was recorded. Binds the attestation to what was produced rather than only to what was paid.

amounts:

REQUIRED. Settled, restituted and slashed values.

children_merkle_root:

REQUIRED where the contract has children ().

signatures:

REQUIRED. MUST include a Facilitator signature.

The Facilitator signature is what makes the record evidence. Without it an attestation is a claim by interested parties about themselves. With it, forging a settlement history requires a Facilitator's key rather than two identities, which is the property the economic argument for settlement-derived reputation assumed all along. A Facilitator MUST issue an attestation for every terminal contract, including SETTLED and ABANDONED, and MUST NOT require the signature of a party whose loss the attestation records. Under the -00 a slashed Seller simply declined to co-sign its own conviction, which made the reputation layer structurally incapable of recording a negative outcome.

A Work Attestation for a slashed contract

The example carries one signature, the Facilitator's. That is sufficient and is the point: the Seller did not consent to this record and its consent is not required.

The Children Merkle Root Let D be the list of 32-byte SHA-256 digests of each immediate child's Work Attestation in JCS-canonical form, sorted ascending as byte strings. children_merkle_root is MTH(D) exactly as defined in Section 2.1.1, with SHA-256 as the hash: a leaf is SHA-256(0x00 || d), an interior node is SHA-256(0x01 || left || right), and for n greater than one the list is split at k, the largest power of two smaller than n. The shape is therefore fixed by n alone, and two implementations that agree on D agree on the root. The domain separation is not optional. Without distinct prefixes an attacker can present an interior node as though it were a leaf, and so claim an inclusion proof for a subtree that never existed. Where a contract has no children the member is omitted. It MUST NOT be present with an empty or zero value, which would be indistinguishable from a tree whose children were withheld.

Protocol Endpoints The -00 defined objects and no operations, so two independent implementations of it could not exchange a single message. This section specifies the operations a Facilitator exposes. Base URIs are not fixed by this document; they are discovered from the endpoints member of the capability document (), so a Facilitator may mount them anywhere on its origin. Operations

Operation	Method	Target
Propose a contract	POST	{contract}
Retrieve a contract	GET	{contract}/{id}
Submit a Delivery	POST	{delivery}
Record a Verdict	POST	{verdict}
Open a challenge	POST	{challenge}
Retrieve an Attestation	GET	{attestation}/{id}

All requests and responses use the media types defined in . All requests MUST be made over HTTPS, following the recommendations of . Status codes are as defined in . Request, success response, and body per operation

Operation	Request body	Success	Response body
Propose	pact-contract+json	201	the VTC, plus state
Retrieve contract	none	200	the VTC, plus state
Submit Delivery	pact-delivery+json	202	the Delivery, plus state
Record Verdict	pact-verdict+json	201	the Verdict
Open challenge	pact-challenge+json	202	the Challenge, plus state
Retrieve Attestation	none	200	pact-attestation+json

The state member in a response is the current value from ; it is added by the Facilitator, is not part of the signed object, and MUST NOT be included when the object is canonicalized or hashed. A Facilitator authenticates the sender of a POST by the signature on the body: it MUST reject a Delivery not signed by the contract's Seller, a Verdict not signed by a party admissible under , and a Challenge whose signer it cannot resolve. This document requires no additional HTTP-layer authentication; a Facilitator MAY require one. Retrieval by GET is unauthenticated by this document, and a Facilitator MAY restrict it to the parties of the contract.

Proposing a Contract The request body is a VTC carrying the signatures of every party required to sign it. A Facilitator MUST perform the checks in and before creating the resource, and MUST refuse otherwise.

Idempotency Every object this protocol carries is committed by a hash of its own canonical form, so no separate idempotency key is needed and none is defined. A Facilitator MUST treat a POST whose body canonicalizes to a hash it has already accepted as a request for the existing resource, and MUST respond 200 (OK) with that resource rather than creating a second one or reporting a conflict. Where a POST carries the same object id as an existing resource but a different hash, the Facilitator MUST respond 409 (Conflict). Retrying a submission is therefore always safe, and altering one never is.

Error Responses A Facilitator MUST report failures using problem details, media type application/problem+json, with a type drawn from the registry in . Error responses MUST name the rule that was violated, because a conformance failure a caller cannot locate in this document is a failure of this document. The section member is REQUIRED on any problem arising from a rule in this document and carries the section number stating that rule.

Recording a Verdict A Verdict is a signed statement that a Delivery was evaluated against the committed acceptance instrument, and with what outcome. A Facilitator MUST reject a Verdict whose signer does not satisfy for the contract named, and MUST NOT accept a Verdict for a contract that has no recorded Delivery.

A Verdict

The Verifier is the party identified by the kid of the Verdict's signature. Where the contract names parties.verifier, the Verdict MUST be signed by that party; otherwise the Facilitator evaluates against the signer. A Verdict commits to the instrument it ran and to the results it produced. Without instrument_hash a Verifier could run something other than the committed instrument and the contract would have no way to tell; that is the substitution attack described in , arriving from the verification side rather than the acceptance side.

Exchange

HTTP exchange for the flow in Figure 1 | | |<-- 201 Created -------| | | | | |-- POST {delivery} --->| | |<-- 202 Accepted ------| | | | | | |-- GET work_uri ----->| | |<-- POST {verdict} ---| | | | |<-- 200 OK ------------| | | | | |-- GET {attestation} ->| | |<-- 200 Attestation ---| | ]]>

A Delivery is answered 202 (Accepted) rather than 201 because acceptance of the bytes is not acceptance of the work. The contract moves to DELIVERED; whether it moves on to RELEASING depends on a substantive Verdict, which the Facilitator does not itself produce.

Conformance Every rule a PACT conformance checker enforces is stated in this document as normative text. This section collects the rules that a schema language cannot express, so that an implementation built from this document alone passes a conformance suite built from it. A rule that lives only in a test suite is not a requirement, and an implementer who cannot find it in the specification will not implement it.

Signatures Every signature carried by a VTC, Delivery, Verdict, Challenge, Work Attestation, or capability document is a JWS in the General JSON Serialization of Section 7.2.1 of that document, with the payload detached as its Appendix F describes. The payload is BASE64URL of the JCS-canonical bytes of the object with the signing member removed, so the JWS Signing Input is ASCII(BASE64URL(UTF8(protected)) || "." || BASE64URL(JCS(object))) exactly as Section 5.1 of defines it. The payload is never transmitted; a verifier reconstructs it from the object it holds. The following constraints apply.

• The protected header MUST carry alg, kid and typ.
• alg MUST be ES256 or ES384 , or EdDSA with an Ed25519 key; a verifier MAY also accept Ed448. A verifier MUST reject any other value, and MUST reject none. Absent an allowlist an attacker selects the algorithm, which permits both unsigned acceptance and confusion of a public key for a symmetric secret.
• kid MUST appear inside the protected header and MUST NOT be carried as a sibling of it. A key identifier outside the signed bytes is rewritable in transit, which allows an attacker who can publish a key document to re-attribute a genuine signature to itself.
• typ MUST be the full media type of the object signed, including the application/ prefix, so that a signature over one object type cannot be replayed as a signature over another. Section 4.1.9 of recommends omitting the prefix; this document requires the full form so that typ equals the registered media type character for character. Explicit typing follows Section 3.11 of .

Key Resolution A kid is a URI naming a public key. A verifier MUST resolve it as follows, and MUST reject a signature whose kid it cannot resolve.

• A did: identifier is a DID URL . The verifier resolves the DID document by the method the identifier names and selects the verification method its fragment identifies. Examples in this document use did:web ; no method is required or excluded.
• An https: identifier dereferences, over TLS, to a JWK Set ; the verifier selects the key whose kid member equals the fragment.

The part of a kid before its fragment MUST equal, after the normalization in , the party identifier the signature is attributed to. Verifying a signature establishes that the holder of that key signed; that the key belongs to the party is a property of the identity method, and this document does not add to it.

Rules Not Expressible in a Schema

• parties.buyer and parties.seller MUST be distinct after the normalization in .
• Both the Buyer and the Seller MUST contribute at least one verifying signature. A count of signatures is not sufficient: two signatures from one party MUST be rejected.
• challenge.window_seconds MUST be greater than zero.
• Every URI member inside hash-committed content MUST have a sibling hash member, and a validator MUST reject content carrying harness_uri without harness_hash, or rubric_uri without rubric_hash.
• An acceptance object MUST carry the members REQUIRED for the contract's tier. An empty acceptance object MUST be rejected, since it makes every fraud proof impossible and converts conditional release into unconditional payment.
• A Facilitator MUST reject a contract that does not satisfy against its declared q_min.

Test Vectors Each rule above has an accepting and a rejecting form. A conformance suite built from this section alone, with no reference to any implementation, should reach the same verdicts. Rejecting vectors name the rule they violate. Conformance vectors

ID	Mutation from a valid object	Expect
V-01	unmodified valid VTC	accept
V-02	alg set to none	reject
V-03	alg set to HS256	reject
V-04	kid moved outside the protected header	reject
V-05	typ of a Delivery on a VTC signature	reject
V-06	buyer and seller set to the same identifier	reject
V-07	buyer and seller differing only by trailing "/"	reject
V-08	two signatures, both from the buyer	reject
V-09	window_seconds of 0	reject
V-10	acceptance as an empty object	reject
V-11	harness_uri with harness_hash removed	reject
V-12	B 18.00, P 180.00, q_min 0.90	reject
V-13	B 18.00, P 180.00, q_min 1.00	accept
V-14	Delivery with evidence absent	reject as FAIL
V-15	child whose buyer is not the parent's seller	reject
V-16	child finalising after the parent's window closes	reject
V-17	Verdict signed by the seller	reject
V-18	object keys ordered by code point, with a supplementary-plane key	digest mismatch

V-07 and V-18 are the two most often got wrong. V-07 fails wherever party comparison is a string equality on unnormalized identifiers. V-18 fails wherever canonicalization sorts keys by Unicode code point, which agrees with the required UTF-16 order for every ASCII key and so passes every vector an implementer would think to write.

Worked Example The -00 carried no numeric example and no digest anywhere in its text. Every concrete value lived in a separate repository with no link from the document to it, so the specification made no verifiable claim about its own reference implementation. This section fixes that. The tables and digests below are the reference repository's. The object figures in earlier sections use short illustrative identifiers for page width; the repository examples carry the full ones, and the digests here are computed over those. A buyer commissions a data transformation. The agreed price is 180.00 USDC and the seller posts a bond of 18.00, ten percent, which is the conventional figure. The worked contract

Quantity	Symbol	Value
Price	P	180.00 USDC
Seller bond	B	18.00 USDC
Verification fund	F	0.50 USDC
Released before Verdict	E	0.00
Challenge window		3600 s

Apply . With E of zero the constraint B >= P(1-q)/q reduces to a requirement on q of at least P/(P+B): = 180.00 / (180.00 + 18.00) = 0.9091 ]]> So this contract is only incentive-compatible if better than ninety-one percent of defections are detected, proven and adjudicated inside 3600 seconds. That is the whole argument against a ten percent bond in one line, and it is why the example declares assurance.mode of certain: at q of 1 the required bond is zero and the bond covers harm rather than deterrence. Required bond at this price, by declared q

q	Required B	18.00 suffices?
1.00	0.00	yes
0.9091	18.00	exactly
0.90	20.00	no
0.50	180.00	no

The digests carried by the reference TaskSpec and contract are: criteria_hash is the manifest digest of over the acceptance instrument bundle, and the same value appears as acceptance.harness_hash inside the TaskSpec, so the instrument is committed both by the contract and from within the specification it belongs to. And the contract's own commitment, computed over the signed contract per : This value differs from the one the -00 examples carried, and the difference is semantic rather than incidental: the -00 excluded the signature set from the commitment, so its digest proved what was written and not who agreed to it. spec_hash and criteria_hash are unchanged in construction.

Implementation Status This section records the status of known implementations of this document per , and is to be removed before publication as an RFC. A reference implementation of the object schemas, the examples in , and a conformance validator is maintained at https://github.com/pact-spec/spec under the Revised BSD licence. As of the date of this document the validator runs sixty-six checks: schema conformance for every object, JCS canonicalization including the UTF-16 key-order vector of , every hash commitment in , the constraint of on the worked figures, the Merkle construction of against the definition in , and the vectors of . No Facilitator, Buyer or Seller exchanging messages over the endpoints of is known to the author.

Security Considerations Most of what follows was found by adversarial review of rather than anticipated when it was written. Each subsection states the attack, why it worked, and the requirement in this document that closes it. Where a threat is only mitigated rather than closed, that is said.

Verifier Capture A verification tier states how strongly work is checked. It does not state who checked it, and those fail separately. A re-execution transcript produced by the Seller and the same transcript produced by an independent Challenger are the same method and different evidence. Where a proof is generated and verified entirely inside one party, the tier is satisfied and the contract is unprotected. requires that independence be derived by the evaluator from the parties named in the contract, and forbids satisfying it with a self-asserted field. A criterion satisfiable by writing a string reproduces the defect it was meant to catch.

Algorithm and Key Confusion Absent an algorithm allowlist an attacker chooses the algorithm. The two consequences are alg of none, which makes every signature check vacuous, and presenting an ECDSA public key as an HMAC secret, which lets anyone holding the public key forge. fixes the permitted set. A kid carried as a sibling of the protected header rather than inside it is outside the signed bytes and is rewritable in transit. An attacker who can publish a key document can then re-attribute a victim's genuine signature to an identifier it controls, without breaking any cryptography. requires kid inside the protected header. A signature over one object type replayed as a signature over another is prevented by the typ requirement in the same section.

Substitution of Committed Content The -00 committed harness_uri as a string. The bytes at that URI were covered by nothing. A Buyer could therefore sign a contract, replace the acceptance instrument afterwards, run the replacement, and submit its failure as a textbook-valid fraud proof: the Seller's Bond is slashed, its attestation records a loss, and the Buyer keeps the work. Cost of the attack: one file overwrite. The mirror attack works against a Seller that hosts the input sample. requires a sibling hash over the dereferenced bytes for every URI inside committed content, and requires a Verdict to commit to the instrument it actually ran, which closes the same attack from the verification side.

Unauthenticated Parent Attachment Naming a parent contract cost one signature in the -00 and was checked against nothing. An attacker could attach a failing child to a competitor's contract and cause that competitor's Bond to be slashed. requires the child's Buyer to be the parent's Seller, verified against the parent's hash. The converse abuse, a Seller subcontracting to an identity it controls in order to offer that identity's small Bond as the whole remedy, is addressed by : cascade is recovery for the parent Seller and never discharge of its obligation to the parent Buyer.

Buying Silence from a Challenger Where the reward for reporting a fraud is bounded below the defaulting Seller's exposure, there is always a private payment that leaves both the discoverer and the Seller better off than reporting, and silence dominates the mechanism the protocol designed. This is not closed by raising the bounty to the full exposure, which leaves nothing for restitution and maximises the incentive to manufacture challenges. mitigates rather than closes it, by making the reward non-exclusive so that buying silence scales with the number of independent discoverers while reporting pays once, and by admitting the Buyer as a Challenger in its own contract so that any bribe has a floor at the restitution the Buyer would forgo. Implementers should understand that a determined Seller facing a single discoverer can still buy silence.

Non-Delivery and Escrow Lock Under the -00 a contract in which nothing was ever delivered had no remedy: the deadline carried no stated consequence, no challenge window opened because there was nothing to challenge, and escrow could remain locked indefinitely. This is the most common real failure in commerce and it had no code path. makes deadline expiry an automatic Buyer remedy producing the ABANDONED state. Note the asymmetry this creates: a Seller that delivers nothing is worse off than one that delivers something non-conformant only if the Bond exceeds the value of the work, which is a reason to size Bonds by harm rather than by a percentage of price.

Cross-Venue Replay A VTC that does not name its Facilitator, network and asset is a signed instrument replayable against any of them. The -00 carried none of the three. requires all three inside the signed content. Relatedly, a hash computed over a contract excluding its signatures proves what was written and not who agreed to it, so entries can be appended or stripped without invalidating the commitment. requires vtc_hash to be computed over the contract including its signature set. A Delivery, Verdict or Challenge replayed against a different contract fails because each carries vtc_id and a hash that binds it to one contract and one Delivery, and the typ rule of stops a signature over one object type standing for another.

Nondeterminism as Shield and as Weapon A re-execution profile that does not state what determinism it assumes cuts both ways. An honest Seller doing model-assisted work is convicted by a re-execution that differs for ordinary reasons. A cheating Seller escapes any fraud proof by asserting nondeterminism, unfalsifiably. Registration under requires a profile to state whether it is deterministic and what tolerance applies; a profile that does not should not be registered, and a contract naming one is not safely enforceable.

Fabricated Settlement History The economic argument for settlement-derived reputation is that faking a history requires funding real contracts. That argument fails if attestations do not name the parties, do not distinguish the payer from the performer, and carry no Facilitator signature, since two cooperating identities can then manufacture history at the cost of two signatures, and a party can present its Buyer records as Seller records. requires all three. It fails in the other direction too if a negative outcome requires the signature of the party it convicts. Reputation that is structurally incapable of recording a loss is not evidence of anything.

Trust in the Facilitator The Facilitator holds the price, the Bond and the Verification Fund of every contract it settles. Nothing in this protocol stops a Facilitator from keeping them. What the protocol does is make that theft attributable: every movement of value is recorded in a Work Attestation the Facilitator signs, every party holds a co-signed contract stating what should have happened, and a Facilitator that deviates has produced its own evidence. Whether that evidence has consequences is a matter of reputation, contract or law, all of which are outside this document. Deployments that cannot accept a single custodian should look to multi-party custody, which this document does not specify and does not preclude.

Key Compromise and Rotation A signature here is a long-lived commitment, and a compromised key signs contracts the party never agreed to. Rotation and revocation belong to the identity method behind the kid (), and this document does not restate them. Two things it does require: a Facilitator MUST record, with each object it accepts, the key material or its digest as resolved at the time of acceptance, so that a later rotation does not make an earlier signature unverifiable; and a Facilitator MUST NOT accept an object whose kid resolves to a key the identity method marks as revoked at the time of acceptance.

Denial of Service by Challenge Every accepted Challenge costs an independent evaluation. Without a cost to the Challenger, a party can exhaust the Verification Fund or the Facilitator's capacity by challenging every Delivery. The challenge_deposit of is the defence, and it is a MAY because a deposit also deters the honest challenger the open model relies on. A Facilitator that requires no deposit SHOULD rate-limit Challenges per Challenger and per contract, and SHOULD publish that it does so.

Privacy Considerations PACT moves contracts and evidence about work, and both leak.

Input Disclosure Before Contract Formation Publishing a representative input sample so that a counterparty can price the work discloses production data to parties with whom no contract exists and who may be in unknown jurisdictions. Samples SHOULD be synthetic or de-identified. Where a real sample is necessary, it SHOULD be disclosed only after a confidentiality undertaking, and the constraints member SHOULD carry the retention and deletion terms. This document cannot enforce any of that and does not pretend to.

The Settlement Graph A Facilitator that publishes its log of locks, releases and slashes makes the contract graph public. From it a reader can reconstruct an organisation's suppliers, spend and cadence, which is commercially sensitive even when no individual is identifiable. Transparency and counterparty privacy are in genuine tension here, and this document resolves it in favour of neither: a Facilitator MAY publish aggregates, and SHOULD NOT publish per-contract records identifying both parties without their agreement. Work Attestations leak the same graph by construction, since each names both parties and the counterparty retains a signed copy indefinitely. Selective disclosure over attestations, so that a holder can prove a settled contract without revealing the counterparty, is possible with the mechanisms cited in and is not specified here.

Challenger Access An open challenge model requires that some party outside the contract can obtain the deliverable and the input in order to build a fraud proof. That is in direct conflict with confidentiality of both. The conflict is real and this document does not dissolve it. What it does is make the choice explicit: a contract whose content cannot be disclosed to a Challenger MUST NOT declare open assurance, because there is no population able to produce the detection probability such a declaration asserts.

Retention Retention duties stated for dispute purposes can conflict with erasure rights asserted by a data subject. Contracts SHOULD state a retention period, and implementers should be aware that a hash commitment survives deletion of the content it commits to, which is usually the property they want and occasionally the one they must explain.

IANA Considerations This document asks IANA to register six media types, one well-known URI, and two registries. It defines problem types but does not ask for a registry of them ().

Media Types IANA is requested to register the following in the "Media Types" registry, per . The template below is given once in full; the six registrations differ only in the subtype name and the object they carry.

Type name:

application

Subtype name:

see

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary; the content is JSON text as defined in , encoded in UTF-8

Security considerations:

See of this document. In particular these media types carry signed objects whose signatures MUST be verified under the constraints in ; accepting one without algorithm restriction permits signature forgery.

Interoperability considerations:

Objects MUST be canonicalized per before hashing or signing. Implementations that canonicalize by sorting object keys on Unicode code point rather than UTF-16 code unit will produce divergent digests for keys outside the Basic Multilingual Plane.

Published specification:

This document

Applications that use this media type:

Settlement services and autonomous agents forming contracts under this specification

Fragment identifier considerations:

As specified for application/json

Additional information:

Deprecated alias names: none. Magic numbers: none. File extensions: .json. Macintosh file type code: TEXT

Person & email address to contact:

Laxmikant Sharma <laxsharma79@gmail.com>

Intended usage:

COMMON

Restrictions on usage:

None

Author:

Laxmikant Sharma

Change controller:

IETF

Media types registered by this document

Subtype name	Object	Defined in
pact-contract+json	Verifiable Task Contract
pact-delivery+json	Delivery
pact-verdict+json	Verdict
pact-challenge+json	Challenge
pact-attestation+json	Work Attestation
pact-facilitator+json	Capability document

Well-Known URI IANA is requested to register the following in the "Well-Known URIs" registry, per .

URI suffix:

pact-facilitator

Change controller:

IETF

Specification document(s):

This document,

Status:

permanent

Related information:

The resource is served with media type application/pact-facilitator+json and MUST be signed.

PACT Verification Profiles Registry IANA is requested to create a registry named "PACT Verification Profiles". The registration policy is Specification Required . Instructions for the designated expert. A profile determines what a fraud proof consists of and, through , what a Bond must cover, so a registration that leaves either underdetermined is not usable. The expert SHOULD confirm that the submitted specification states, for the profile: what artifact is evaluated and what it is evaluated against; what constitutes a valid fraud proof, including whether absence of evidence is one; an order-of-magnitude estimate of verification cost relative to contract price, since that quantity and not the profile name determines whether any Bond makes third-party challenge rational; and whether the profile is deterministic, and if not, what tolerance applies. The expert SHOULD reject a profile whose fraud proof cannot be evaluated by a party other than the Seller, since such a profile cannot satisfy . Initial contents

Name	Description	Reference
acceptance	Run the committed instrument against the Delivery	This document
bisection	Interactive narrowing to a disputed step	This document
full-reexec	Re-execute and compare outputs byte for byte	This document

PACT Settlement Bindings Registry IANA is requested to create a registry named "PACT Settlement Bindings", registration policy Specification Required. A binding determines how value is locked, released and reversed, so the expert SHOULD confirm that the submitted specification states how each of those three operations maps onto the underlying rail, and what happens when a reversal is requested after the rail's own finality. A binding whose rail cannot reverse MUST say so, since then has no rank 1. Initial contents

Identifier	Description	Reference
pact-escrow	An x402 payment scheme carrying PACT escrow semantics	This document

Problem Types This document creates no registry for its problem types. Section 4.2 establishes the "HTTP Problem Types" registry for types intended for reuse across applications; the types below are specific to this protocol and are identified by URIs in a namespace this document defines, which that specification permits without registration. Each is the identifier in the table appended to the prefix https://pact-spec.github.io/problem/. Per Section 3.1.1 of a consumer uses the URI as an identifier and SHOULD NOT dereference it automatically; dereferencing SHOULD yield human-readable documentation, which the author maintains at that prefix. Each entry carries the identifier, the HTTP status it accompanies, and the section stating the rule it reports. Problem types defined by this document

Identifier	Status	Defined in
assurance-constraint-unsatisfied	422
evidence-nonconformant	422
parent-unresolvable	422
finality-ordering-violation	422
parties-not-distinct	422
algorithm-not-permitted	400
verifier-not-independent	422
release-exceeds-bond	409

Normative References Informative References Proceedings of the IEEE Symposium on Security and Privacy Work in Progress, Internet-Draft, draft-stone-vcap-ap2-binding-00 Work in Progress, Internet-Draft, draft-sahu-agent-action-receipts-00 Work in Progress, Internet-Draft, draft-mih-sato-agent-accountability-composition-01 Work in Progress, Internet-Draft, draft-asor-wimse-agent-delegation-chain-01 Work in Progress, Internet-Draft, draft-pinto-agent-authz-contestability-00 W3C W3C Recommendation W3C Credentials Community Group Chain Agnostic Standards Alliance Status: Final PhD thesis, University of Waterloo. Chapter 2 defines generatable and revocable items and the affidavit token by which a third party reverses a completed transfer Proceedings of the 3rd International Workshop on Economics of Networked Systems (NetEcon '08), pp. 85-90 Encyclopedia of Law and Economics, entry 8000, Edward Elgar. The result is attributed therein to Bentham (1789) arXiv:2308.02880 x402 Foundation Pull request 2853, specs/extensions/compliance_fields.md Internet-Draft, draft-laxsharma-pact-00

Acknowledgements The UTF-16 key-ordering vector that exposed a latent canonicalization defect in the reference validator, and the formulation of verifier independence as a relation the evaluator derives rather than a field the record declares, came from Tersign (wowlegend) on x402-foundation/x402 issue 3065. The observation that verification tiers say how work is checked and never who checks it, which set off the adversarial review this revision rests on, came from msaleme on the same thread. Rich Smith's A2A Settlement Extension was the clearest instance of the pattern corrects, and he engaged with the critique on a2aproject/A2A discussion 1576.