PACT: Liability and Settlement for Autonomous Agent Contracts

1.1. 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.¶

1.2. 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 (Section 5.3); the Delivery object against which that contract is judged (Section 6); a settlement procedure whose release is conditioned on a declared assurance level (Section 7); and a subcontract tree through which liability cascades (Section 10).¶

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 [I-D.laxsharma-pact-00] 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.¶

1.3. Relationship to Existing Work

PACT's agree, perform, verify, settle loop is an instance of optimistic fair exchange [ASOKAN98], in which a third party is contacted only when the exchange fails. The revocable-item case, developed in [ASOKAN98THESIS], 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 Section 7.2 addresses, is who pays to produce the evidence a dispute is decided on.¶

The bond-sizing rule in Section 7.2 is the classical deterrence bound. It is stated for public enforcement generally in [POLINSKY99], which traces it to Bentham, and for outsourced computation specifically in [BELENKIY08], 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 [MAMAGEISHVILI23]. 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. [I-D.hood-agtp-commerce] carries Work Completion Records and an audit-verified settlement timing; [I-D.stone-vcap-ap2-binding] 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 [RFC9334] and [RFC9711]. Signed, hash-chained action receipts [I-D.sahu-agent-action-receipts], composition of accountability records [I-D.mih-sato-agent-accountability-composition], delegation chains [I-D.asor-wimse-agent-delegation-chain], and contestability bindings [I-D.pinto-agent-authz-contestability] are each specified elsewhere, and PACT consumes rather than restates them.¶

1.4. 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 Figure 2, with attestations either can check. It fails, and that would itself be a result worth recording, if the constraint in Section 7.2 proves unworkable at the prices and verification costs real deployments exhibit. Experience should be reported to the author and to the repository named in Section 15.¶

1.5. 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 (Section 5.3).¶
• 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 (Section 6).¶
• 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 (Section 7.4).¶
• 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 (Section 7.3).¶
• An Assurance Constraint is stated that a facilitator can check before locking funds (Section 7.2).¶
• 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 (Section 10).¶
• Protocol endpoints are specified. The -00 defined objects and no operations, so no two implementations could exchange a message (Section 12).¶
• Conformance requirements are stated (Section 13). 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 (Section 14). 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 (Section 1.2).¶

5.1. 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.¶

5.2. The Task Specification

The content committed by spec_hash is a TaskSpec: a JSON object, canonicalized per [RFC8785] 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.¶

5.3. 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 Section 7.2. 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 Section 7.4.¶

parent:

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

remainder_to:

OPTIONAL. Where slashed value remaining after rank 4 of Section 7.4 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 Section 10.1: 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.¶

7.1. 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.¶

   Escrow (P)           Bond (B)           Verification Fund (F)
   buyer's price        seller collateral  pays for checking
        |                    |                      |
 1      |-- unreleased ----> 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.¶

7.2. 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:¶

        q * ( (P - E) + B )  >=  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:¶

        B  >=  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 [POLINSKY99], which traces it to Bentham, and for outsourced computation, with the fine posted in advance as a deposit held by the principal, in [BELENKIY08] Theorem 1. Its form for rollup validators is [MAMAGEISHVILI23]. 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 Section 7.4 shows that a bounded reward is dominated by silence.¶

7.3. 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 Section 7.1.¶

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.¶

7.4. 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. [BELENKIY08] 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.¶

  Buyer        Facilitator       Verifier      Challenger
    |              |                 |               |
    |              |<-- Verdict PASS |               |
    |              |-- release(P) -> 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   |

7.5. 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 Section 9.1, 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 (Section 8), 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 Section 16.12 discusses its limits.¶

{
  "pact": "0.1",
  "type": "Challenge",
  "vtc_id":        "vtc_7f3a91",
  "delivery_hash": "sha256:5d7c...",
  "proof": {
    "profile":         "acceptance",
    "instrument_hash": "sha256:d9205d4f...",
    "results_hash":    "sha256:a91e...",
    "results_uri":     "https://watch.example/o/a91e",
    "failing_checks":  ["schema_valid_rate", "row_count_min"]
  },
  "signature": { "protected": "...", "signature": "..." }
}

7.6. 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 Section 7.4, 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 (Section 10), because cascading liability requires the parent's collateral to remain exposed until the subtree has settled.¶

9.1. 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 [X402COMPLIANCE]; PACT binds them at contract formation, constraining who may be named as Verifier before work begins.¶

10.1. 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:¶

   child.parties.buyer  ==  parent.parties.seller

after the normalization in Section 9.1, 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.¶

10.2. 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 Section 7.4 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 (parent Buyer)
     ^
     |  B still owes A the full parent remedy      (Section 10.2)
     |
   B (parent Seller, child Buyer)
     ^
     |  C's Bond restores B under rank 3           (Section 7.4)
     |
   C (child Seller)  -- fails --

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.¶

10.3. 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 Section 11. 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.¶

  PERMITTED BY -00 (deadlock):

  parent  |=== work ===|== window ==|
          |                         ^ parent final, must commit
          |                           to a child attestation that
  child   |==== work ====|== window ==|  does not exist yet
                                      ^ child final

  REQUIRED BY -01:

  parent  |=== work ===|===== window =====|
                                          ^ parent final
  child   |=== work ===|== window ==|
                                    ^ child final, in time

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:¶

   child.task.deadline
     + child.challenge.window_seconds
     + child.challenge.max_dispute_seconds
   <
   parent.task.deadline
     + parent.challenge.window_seconds

A Facilitator MUST NOT move a contract to FINAL, and MUST NOT return a Bond under Section 7.6, 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.¶

11.1. 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 [RFC9162] 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.¶

12.1. 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 Section 13 and Section 7.2 before creating the resource, and MUST refuse otherwise.¶

POST /pact/v1/contracts HTTP/1.1
Host: settle.example
Content-Type: application/pact-contract+json

{ "pact": "0.1", "type": "VerifiableTaskContract",
  "id": "vtc_7f3a91", ... }

HTTP/1.1 201 Created
Location: /pact/v1/contracts/vtc_7f3a91
Content-Type: application/pact-contract+json

{ "pact": "0.1", "type": "VerifiableTaskContract",
  "id": "vtc_7f3a91", "state": "PROPOSED", ... }

12.2. 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.¶

12.3. Error Responses

A Facilitator MUST report failures using [RFC9457] problem details, media type application/problem+json, with a type drawn from the registry in Section 18. 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.¶

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json

{
  "type":   "https://pact-spec.github.io/problem/
             assurance-constraint-unsatisfied",
  "title":  "Assurance constraint not satisfied",
  "status": 422,
  "detail": "Bond 18.00 is below the minimum 20.00 required
             for q_min 0.90 at price 180.00 with E 0.00.",
  "section": "7.2",
  "required_bond": "20.00"
}

The section member is REQUIRED on any problem arising from a rule in this document and carries the section number stating that rule.¶

12.4. 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 Section 9.1 for the contract named, and MUST NOT accept a Verdict for a contract that has no recorded Delivery.¶

{
  "pact": "0.1",
  "type": "Verdict",
  "vtc_id":        "vtc_7f3a91",
  "delivery_hash": "sha256:5d7c...",
  "outcome":       "PASS",
  "profile":       "acceptance",
  "instrument_hash": "sha256:d9205d4f...",
  "results_hash":    "sha256:7e02...",
  "evaluated_at":  "2026-11-10T09:14:22Z",
  "signature": { "protected": "...", "signature": "..." }
}

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 Section 9.1 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 Section 5.1, arriving from the verification side rather than the acceptance side.¶

12.5. Exchange

 Buyer/Seller            Facilitator             Verifier
      |                       |                      |
      |-- POST {contract} --->|                      |
      |<-- 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.¶

13.1. Signatures

Every signature carried by a VTC, Delivery, Verdict, Challenge, Work Attestation, or capability document is a JWS [RFC7515] 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 [RFC7515] 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 [RFC7518], or EdDSA [RFC8037] 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 [RFC7515] 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 [RFC8725].¶

13.2. Rules Not Expressible in a Schema

• parties.buyer and parties.seller MUST be distinct after the normalization in Section 9.1.¶
• 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 Section 7.2 against its declared q_min.¶

13.3. 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.¶

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.¶

16.1. 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.¶

Section 9.1 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.¶

16.2. 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. Section 13.1 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. Section 13.1 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.¶

16.3. 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.¶

Section 5.1 requires a sibling hash over the dereferenced bytes for every URI inside committed content, and Section 12.4 requires a Verdict to commit to the instrument it actually ran, which closes the same attack from the verification side.¶

16.4. 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. Section 10.1 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 Section 10.2: cascade is recovery for the parent Seller and never discharge of its obligation to the parent Buyer.¶

16.5. 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.¶

Section 7.4 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.¶

16.6. 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.¶

Section 6 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.¶

16.7. 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. Section 5 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. Section 6 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 Section 13.1 stops a signature over one object type standing for another.¶

16.8. 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 Section 18.3 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.¶

16.9. 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. Section 11 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.¶

16.10. 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.¶

16.11. 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 (Section 13.1.1), 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.¶

16.12. 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 Section 7.5 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.¶

17.1. 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.¶

17.2. 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 Section 11 and is not specified here.¶

17.3. 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.¶

17.4. 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.¶

18.1. Media Types

IANA is requested to register the following in the "Media Types" registry, per [RFC6838]. 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 Table 6¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary; the content is JSON text as defined in [RFC8259], encoded in UTF-8¶

Security considerations:

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

Interoperability considerations:

Objects MUST be canonicalized per [RFC8785] 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¶

18.2. Well-Known URI

IANA is requested to register the following in the "Well-Known URIs" registry, per [RFC8615].¶

URI suffix:

pact-facilitator¶

Change controller:

IETF¶

Specification document(s):

This document, Section 8¶

Status:

permanent¶

Related information:

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

18.3. PACT Verification Profiles Registry

IANA is requested to create a registry named "PACT Verification Profiles". The registration policy is Specification Required [RFC8126].¶

Instructions for the designated expert. A profile determines what a fraud proof consists of and, through Section 7.2, 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 Section 9.1.¶

18.4. 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 Section 7.4 then has no rank 1.¶

18.5. Problem Types

This document creates no registry for its problem types. [RFC9457] 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 [RFC9457] 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.¶