PACT: Co-Signed Task Contracts, Delivery and Verdict Records, and Outcome Records for Autonomous Agents

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 none of them provides is interoperability at the level of the task. Two agents built by different vendors have no common record of what one asked the other to do, no common form for the result, no way to have that result judged by a third implementation against criteria fixed before the work began, and no record of the outcome that a fourth implementation can verify without trusting any of the first three. Receipts record that an action occurred, audit records establish whether behaviour matched intent, and payment schemes move value on the payer's instruction. None of them says what was agreed, what was delivered, or whether the one met the other. Those documents leave that gap on purpose, since it is outside their scope, and correctly so. It is the gap this document addresses, and only that gap.

What This Document Specifies, and What It Does Not PACT specifies exactly four things: a co-signed contract record whose digest covers its signature set (); a Delivery record and the Verdict record bound to it by digest (, ); an event trace, signed by a Facilitator, from which one Outcome Record per contract is produced (, ); and a Merkle commitment from a parent's Outcome Record to its children's (). A contract names its settlement terms by reference: a profile identifier, a digest over the profile's bytes, and a parameter object that this document does not read (). What those terms mean, and everything about who holds or moves value under them, is the profile's to say. This document specifies the records, their digests, who signs each one, the order in which a Facilitator records events, and a commitment across records. That is the whole of it. A contract carries a price and names a settlement binding, since a task contract without them is not one; what happens to the price is the profile's, and what the binding reports is the binding's. A deployment relies on other specifications, agreements or arrangements for: the meaning of the terms a contract names; agent identity and key distribution; delegation of authority from a human or organisational principal; agent discovery; transport security beyond ; an audit or accountability architecture; a transparency service; a payment rail or settlement network; a reputation system; and the resolution of any disagreement the records do not settle. Carrying terms by reference is an old pattern in this series. ACME carries a terms-of-service URL and, where a server chooses to require it, has the client assert agreement to those terms before an account is created, without defining a single term. A certificate carries its policy as an identifier whose rules live outside the IETF (, Section 4.2.1.4), and the framework for writing those rules says it does not aim to provide legal advice. The Internet Open Trading Protocol specified the messages of a trade and left the trade's terms to the parties. PACT follows that line. Two mechanisms present in the -00 revision remain withdrawn: contract channels, and the sealed-bid award procedure. The reasons are recorded in and are not repeated. The change from -01 to this revision is listed in .

Relationship to Existing Work PACT's agree, perform, verify, record loop is an instance of optimistic fair exchange , in which a third party is contacted only when the exchange fails. What that literature establishes is what a third party must be able to observe for an exchange to be fair; the records in this document are that observation, written down in a form two implementations can compare. 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. This document binds to neither and is designed to be usable alongside either. Five bodies of IETF work touch the same records, and the relationship to each is stated here so that it is not left to the reader.

RATS.: defines Verifier, Evidence and Attestation Result as terms of art: a RATS Verifier appraises Evidence about an Attester. PACT's Verifier evaluates a Delivery against an instrument the parties committed to, and its terminal record is an Outcome Record, not an attestation. The -01 revision called that record a Work Attestation and used the RATS words with other meanings; this revision renames the record and defines its remaining shared vocabulary in . Where a verification tier relies on hardware attestation, the RATS architecture applies unchanged and PACT consumes its results.
SCITT.: defines signed-statement transparency and defines COSE receipts for it. PACT does not define a transparency service; a Facilitator that wants its Outcome Records to be publicly append-only can register them with a SCITT transparency service, and says which Facilitator misbehaviour that closes. The Merkle commitment in is not a transparency log: it is a fixed commitment from one record to a known, finite set of other records, and it uses the tree of for its construction only.
HTTPAPI.: is the general mechanism for making a POST safe to retry. PACT does not use it, because every object it carries is committed by the digest of its own canonical form and that digest is the idempotency key (). Error reporting follows .
WIMSE.: gives workload and agent identity a home. PACT does not define an identity format; a kid resolves as says. An identity system defined elsewhere is used by naming its identifiers in one of the two forms that section resolves; a further form needs one resolution rule added there, and nothing else in this document changes.
SATP.: transfers a digital asset between two gateways with evidence a third party can verify. An Outcome Record moves no asset. It is a signed statement that certain records were received in a certain order, and what any of that means for an asset is the terms profile's to say.

Verification evidence for hardware-attested tiers follows the architecture of and the EAT format of . 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, and an individual submission with no formal standing in the standards process: no working group has adopted it and the IETF has not endorsed it. The question it tests is stated over protocol observables only. Given the same sequence of posted records, the same clock readings and the same reports from the settlement binding, two independent Facilitator implementations should produce the same event trace (). Given the same trace and the same terms profile, they should produce the same Outcome Record body (), byte for byte after canonicalization. The experiment succeeds if two independent Facilitators, serving Buyers and Sellers built by different implementers, reach every terminal state in with Outcome Records either can verify and that agree. It fails, and that would itself be worth recording, if the trace turns out to under-determine the outcome, which is to say if two honest implementations reading the same records disagree about what happened. Experience should be reported to the author and to the repository named in . The non-normative profile in exists so that the experiment can be run before any other profile is written.

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. Canonical form. Every JSON object defined here is 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 until a key outside the Basic Multilingual Plane is compared with one whose first differing unit lies in U+E000 to U+FFFF, where the two orders disagree. Numbers MUST be serialized as Section 3.2.2.3 requires, which is how ECMAScript prints them: the number one is 1, whatever type held it, and never 1.0. Figures. A figure line that would exceed the page width is folded with the single backslash strategy of , and a figure that contains a fold begins with the header line that RFC requires. The figure is read after unfolding; the digests it prints are whole once the fold is removed. Object digest. The digest of an object is the string sha256: followed by the lowercase hexadecimal SHA-256 of the canonical form of the whole object, including every signature member it carries. Every hash member in this document that names another object (vtc_hash, delivery_hash, challenge_hash, the object member of a trace entry) is that object's digest, and an element of the list D in is the 32 bytes that digest's hexadecimal encodes. A digest that excluded signatures would prove what was written and not who agreed to it; the -00 revision had that defect and the -01 revision fixed it for the contract only. This revision applies one construction everywhere. Signing input. A signature over an object is computed over the canonical form of the object with the signing member (signature or signatures) removed, as specifies. The digest of an object and the signing input of an object are therefore different byte strings, and the difference is the signature set. Version. The pact member carries a version of the form major.minor; this document defines 0.2. 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, with two exceptions: the contents of terms.parameters (), which the named profile defines and this document does not read; and the members of a Delivery's evidence, a Challenge's proof and a TaskSpec's constraints beyond those names, which the verification profile defines. 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 event is the instant that counts, that instant is what the trace carries, and parties SHOULD allow for skew when acting near a boundary. says what that clock can and cannot prove. Amounts. An amount is a decimal string with no sign, 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 examples use chain identifiers. This document carries amounts; it does not say what any amount is for. Where a record produced under this document lists amounts, as terms_result does (), the meaning of every entry is the named profile's. Identifiers. A party identifier is a URI. Two identifiers name the same party when they are equal after the normalization in , and every comparison of identifiers in this document is made after that normalization.

Terminology Five words in this document have meanings elsewhere that are close enough to mislead, and are defined here once.

Contract:: Used in this document for a co-signed JSON object of the form in , and for nothing else. This document takes no position on whether any such object is a contract in law, in any jurisdiction, and defines no obligation between the parties that sign one.
Verifier, Verdict:: A Verifier here is the party that evaluates a Delivery against the instrument the contract committed to, and a Verdict is its signed finding. This is not the Verifier of , which appraises Evidence about an Attester; the two roles may be played by the same software in a hardware-attested tier, and are still different roles.
Evidence:: The evidence member of a Delivery is the set of artefacts a Verifier evaluates, produced by the Seller. It is not Evidence in the sense of . The member name is kept because it is the ordinary word for what the member holds; the RATS term names a role in an attestation architecture, and this note is the disambiguation.
Facilitator:: The party that runs the state machine of for a contract: it accepts or refuses the records posted to it, records events in one order on its own clock, and signs the trace and the Outcome Record. Nothing in this document says that a Facilitator holds anything of value, and nothing in it requires that it does.

The remaining roles are defined by what they sign and receive in , and the objects by their members in .

Data Dictionary This section lists every member this document defines, by the object that carries it, with its type, whether it is required in that object, and what it commits to. It is a dictionary and not a rulebook: the rule that a record omitting a required member, or carrying one this document does not define for it, does not conform is stated once, in ; the rules a Facilitator applies when it accepts or refuses a record are in and in the section that defines the record. No sentence in this section requires anything of any party. Where a member's meaning is the named terms profile's, the entry says so and says nothing more. Types are JSON types. A digest is a string of the form in . An amount is a string of the form in . A URI is a string. A timestamp is a string of the form in . Cardinality is written as required or optional.

Members Common to Every Record

pact:: string, required. The protocol version; 0.2 for objects defined by this document.
type:: string, required. The object's type name: VerifiableTaskContract, Delivery, Verdict, Challenge, ContractStatus, OutcomeRecord, or FacilitatorCapabilities.
signature:: object, required in Delivery, Verdict, Challenge, ContractStatus and the capability document. One JWS entry of the form in , by the single signer of that record.
signatures:: array of objects, required in the contract and in the Outcome Record. JWS entries of the form in , sorted as that section says. Commits, in the contract, to who agreed; in the Outcome Record, to which Facilitator issued it.

Contract Members Carried in the Verifiable Task Contract (), media type application/vnd.pact.contract+json.

id:: string, required. Contract identifier, unique among the contracts of the Facilitator named in parties.facilitator.
parties:: object, required. The identifiers of the parties, by role: buyer (URI, required), seller (URI, required), facilitator (URI, required), verifier (URI, optional). Commits to who plays each role for this contract.
task:: object, required. spec_hash (digest, required) commits to a TaskSpec (); spec_uri (URI, optional) says where its bytes may be fetched; deadline (timestamp, required) is the instant at or after which the deadline-passed event may be recorded ().
price:: object, required. amount (amount, required), currency (string, required), settlement (URI, required, naming a settlement binding), network (string, required, in the form the binding defines). Commits to a figure and a venue that both parties signed. The meaning of the figure is the named terms profile's.
verification:: object, required. tier (string, required), profile (string or URI, required; ), criteria_hash (digest, required; the manifest digest of the acceptance instrument per ), max_verdict_seconds (integer, required, greater than zero; the longest interval after delivered within which a first Verdict is recorded before verdict-lapsed may be). Commits to how a Delivery is judged and by what.
flow:: string, required. One of verdict-first, delivery-first, no-window (). Selects the shape of the state machine for this contract.
terms:: object, required (). profile (URI, required) names a terms profile; profile_hash (digest, required) commits to the profile's bytes as says; parameters (object, required, may be empty) carries the profile's parameters. This document reads no member of parameters; every one of them means what the named profile says.
challenge:: object, required. window_seconds (integer, required, greater than zero) is the duration of the challenge window; max_dispute_seconds (integer, required, greater than zero) is the longest interval after a challenge event within which a Verdict on that Challenge is recorded before dispute-lapsed may be.
parent:: object, optional; present only in a subcontract (). vtc_id (string, required), vtc_hash (digest, required), and facilitator (URI, required) identify the parent contract and the Facilitator that holds it.

TaskSpec Members The TaskSpec is the content committed by task.spec_hash (). It is not transmitted over the endpoints of this document.

description:: string, required. A statement of the work in natural language.
inputs:: object, optional. schema_uri with schema_hash, and where a representative sample is published, sample_uri with sample_hash; each URI with its digest over the dereferenced bytes.
deliverable:: object, required. format (string) and schema_uri with schema_hash.
acceptance:: object, required. The verification instrument: harness_uri with 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 with rubric_hash for judgment tiers; plus thresholds (object) in machine-readable form. harness_hash equals the contract's criteria_hash.
constraints:: object, optional. Tool prohibitions, confidentiality and compliance conditions, in a form this document does not define.

Delivery Members Carried in the Delivery (), media type application/vnd.pact.delivery+json.

vtc_id, vtc_hash:: string and digest, required. Identify and commit to the contract performed.
work_hash:: digest, required. Commits to the delivered bytes, or to a manifest per where the deliverable is a bundle.
work_uri:: URI, optional. Where the bytes may be fetched, subject to .
input_hash:: digest, required for tiers whose proof of nonconformance re-executes. Commits to the production input actually consumed.
evidence:: object, required. Members profiled by verification.tier and verification.profile; for the acceptance profile, profile, instrument_hash and results_hash (required) and results_uri (optional). Conformance to the profile is a validity condition of the Delivery, not a judgement on the work.

Verdict Members Carried in the Verdict (), media type application/vnd.pact.verdict+json.

vtc_id:: string, required.
delivery_hash:: digest, required. Commits to the Delivery judged, including the Seller's signature over it.
challenge_hash:: digest, optional. Present when the Verdict answers a Challenge; commits to that Challenge.
outcome:: string, required. PASS or FAIL.
profile, instrument_hash:: string and digest, required. The verification profile applied and the digest of the instrument actually run, which equals the contract's criteria_hash.
results_hash:: digest, required. The digest of the results document the verification profile defines; for acceptance, the bytes of the results file the instrument wrote.
evaluated_at:: timestamp, required. The Verifier's own clock; informational, since the trace carries the Facilitator's.

Challenge Members Carried in the Challenge (), media type application/vnd.pact.challenge+json.

vtc_id, delivery_hash:: string and digest, required. Identify the contract and commit to the Delivery challenged.
proof:: object, required. Members profiled by verification.profile; for the acceptance profile, profile, instrument_hash and results_hash (required), results_uri and failing_checks (array of strings; optional).
costs:: object, optional. amount and currency: an amount the Challenger states. This document records it in the trace and reads it for nothing; its meaning is the named terms profile's.

Contract Status Members Carried in the Contract Status (), media type application/vnd.pact.status+json, the Facilitator's signed response to every accepted POST.

vtc_id, vtc_hash:: string and digest, required.
state:: string, required. A state name from .
trace:: array of objects, required. The event trace so far, in the order recorded (). Each entry carries event (string, required), at (timestamp, required), object (digest, required where the event was caused by a posted record, and on dispute-lapsed, where it names the Challenge that lapsed), and the event-specific members listed in .
issued_at:: timestamp, required. When this status was signed.

Outcome Record Members Carried in the Outcome Record (), media type application/vnd.pact.outcome+json.

vtc_id, vtc_hash:: string and digest, required.
parties:: object, required. The contract's parties object, copied, so that the record names its subjects and which side of the contract each was on.
outcome:: object, required. state (string, required; FINAL, SETTLED or ABANDONED) and challenge_upheld (boolean, required).
work_hash:: digest, required where a Delivery was recorded. Binds the record to what was produced.
trace:: array of objects, required. The complete event trace, ending with the terminal event.
terms_result:: object, required (). profile and profile_hash (copied from the contract), currency (string), and transfers (array of objects), each with event (integer, the zero-based index of the trace entry the transfer follows), from (string), to (string), amount (amount) and code (string). The entries are the named profile's output for the trace; this document defines their form and two arithmetic invariants over them, and nothing about their meaning.
children_merkle_root:: digest, required where the contract has registered children and absent otherwise ().

Capability Document Members Carried in the Facilitator capability document (), media type application/vnd.pact.facilitator+json.

facilitator:: URI, required. The identifier that appears in parties.facilitator.
issued_at:: timestamp, required. When the document was signed. Nothing in a document survives its Facilitator withdrawing a profile; says when to fetch it again.
settlement_bindings:: array of objects, required. Each with id (URI), networks and assets (arrays of strings), all required.
flows:: array of strings, required. The flows of the Facilitator implements; requires verdict-first among them.
verification_profiles:: array of strings, required. A contract naming a profile not listed is refused ().
terms_profiles:: array of objects, required, with at least one entry. Each with id (URI) and profile_hash (digest): the terms profiles, at the revisions named, whose schedules this Facilitator evaluates.
max_contract_value:: object, optional. amount and currency; a contract whose price, stated in the same currency, exceeds it is refused, as is one whose price is stated in another currency ().
challenge_deposit:: object, optional. amount and currency; see .
retrieval:: string, optional. parties, the default of , or open.
endpoints:: object, required. Maps each endpoint name in to an absolute URI.

Roles A role is defined by where its identifier appears, what it signs, and what it receives. Nothing else about a role is defined here. Roles, by what each signs and receives

Role	Identifier appears in	Signs	Receives
Buyer	`parties.buyer`	the contract	Contract Status, Outcome Record
Seller	`parties.seller`	the contract; the Delivery; as the Buyer of a child, that child's contract ()	Contract Status, Outcome Record
Facilitator	`parties.facilitator`, `parent.facilitator`, the capability document	Contract Status, Outcome Record, the capability document	every posted record
Verifier	`parties.verifier`, or the `kid` of a Verdict	the Verdict	the Delivery and, on a Challenge, the Challenge
Challenger	the `kid` of a Challenge	the Challenge	Contract Status

One identifier may play more than one role across contracts, and and say which combinations within one contract a Facilitator refuses.

Protocol Overview A contract passes through four phases: Propose establishes the record, Agree co-signs it and a Facilitator accepts it, Complete produces a Delivery and a Verdict on it, and Record produces an Outcome Record. Every step after Agree is an event the Facilitator records on its own clock, in one order, and the sequence of those events is the contract's trace. The trace is the protocol's central object: the state machine is defined over it, every response a Facilitator gives carries the prefix recorded so far, and the Outcome Record carries the whole of it.

Message flow under the verdict-first flow, without a Challenge | | | | | | |-- POST contract ->| | | |<-- Status --------| [ accepted ] | | | | [ funded ] | | | | | | | | [ Seller performs ] | | |<-- POST Delivery --| | | |-- Status --------->| [ delivered ] | | | | | | |---- Delivery, criteria_hash ------->| | |<--- POST Verdict -------------------| | |---- Status ------------------------>| | | [ verdict PASS ] [ window-opened ] | | [ window-closed ] [ children-final ] | | [ terminal FINAL ] | | | | | |<-- Outcome Record-|-- Outcome Record ->| | ]]> Every accepted POST is answered with a Contract Status (), a Facilitator-signed object carrying the state and the trace so far. Nothing in the figure moves value, and no arrow in it is named for a movement of value. What a terms profile does at each bracketed event is the profile's, and it is reported once, in the Outcome Record, as a list the profile produced and the Facilitator signed.

States

Contract states FUNDED -delivered-> DELIVERED | | | | deadline- | deadline- | window-opened | passed | passed v | | WINDOW_OPEN <------+ | | | | | | | challenge | | window | verdict PASS | | v | closed | on it, or | | DISPUTED----|--------+ dispute- | | | | lapsed | | verdict | | | | FAIL | | v v v v +--------------------------------------------------+ | AWAITING_CHILDREN | +--------------------------------------------------+ | children-final, then terminal v FINAL SETTLED ABANDONED ]]> The figure omits three arrows that the table carries: a FAIL Verdict recorded in DELIVERED or in WINDOW_OPEN also leads to AWAITING_CHILDREN; under the no-window flow delivered leads there directly; and a Verdict that is late (verdict-lapsed) opens the window without one. FINAL, SETTLED and ABANDONED are terminal and each produces exactly one Outcome Record. The -01 revision had a state, RELEASING, named for a movement of value; it is gone. FUNDED remains, named for the event the settlement binding reports (), and nothing here says what that report means. The state named PROPOSED in earlier revisions is gone. Between the parties' signatures and the Facilitator's acceptance a contract exists only on the parties' side, so no Facilitator could observe that state, and the -01 reference implementation never reported it, although the -01 Section 12.1 example printed it in a 201 response.

Events A trace entry is a JSON object with event (one of the names below), at (the Facilitator's clock when it was recorded), object where the entry records a posted record (that record's digest, ), and the members listed for the event. A Facilitator MUST record the entries of one contract in the order it recorded them and MUST NOT reorder, remove or alter an entry once a Status carrying it has been issued ( says what that rule does and does not prove). Events: the state each is recorded in, the state that follows, and what the entry carries

Event	Recorded in; then. Members and condition
`accepted`	none; then ACCEPTED. `object` is `vtc_hash`. The contract passed .
`funded`	ACCEPTED; then FUNDED. `ref` (string, optional, in the form the settlement binding defines). Recorded when the settlement binding named in `price.settlement` reports that whatever the named terms profile requires before work starts is in place; how a Facilitator observes that is the binding's to say. Where the profile requires nothing, `funded` follows `accepted` in the same operation.
`deadline-passed`	ACCEPTED or FUNDED; then AWAITING_CHILDREN. `task.deadline` has passed with no `delivered` entry.
`delivered`	FUNDED; then DELIVERED, or under `no-window` AWAITING_CHILDREN directly. `object` is the Delivery's digest. The Delivery passed .
`window-opened`	DELIVERED; then WINDOW_OPEN. Recorded in the same operation as the entry it follows, with the same `at`: under `delivery-first` the `delivered` entry; under `verdict-first` a PASS `verdict` or `verdict-lapsed`. `closes_at` (timestamp, required) is `at` plus `challenge.window_seconds`.
`verdict`	DELIVERED (`verdict-first`, no Verdict standing), WINDOW_OPEN (`delivery-first`, no Verdict standing) or DISPUTED (answering a pending Challenge); then as the condition says. `object` is the Verdict's digest; `signer` (the `kid` of its signature); `outcome` (PASS or FAIL); `answers` (digest of the Challenge, present exactly when the Verdict carries `challenge_hash`); `supersedes` (digest of the Verdict that stood, present exactly when one did). Then: FAIL leads to AWAITING_CHILDREN; PASS in DELIVERED leads to `window-opened`; PASS in WINDOW_OPEN changes the state of nothing; PASS in DISPUTED leads to WINDOW_OPEN once no Challenge is pending.
`verdict-lapsed`	DELIVERED; unchanged. Under `verdict-first`, `verification.max_verdict_seconds` have passed since `delivered` with no `verdict`. `window-opened` follows in the same operation.
`challenge`	WINDOW_OPEN or DISPUTED; then DISPUTED. `object` is the Challenge's digest; `signer` (the `kid` of its signature); `costs` copied from the Challenge when present. The Challenge passed before `closes_at`.
`dispute-lapsed`	DISPUTED; then WINDOW_OPEN. `object` is the Challenge's digest. `challenge.max_dispute_seconds` have passed since that `challenge` entry with no Verdict answering it. Leads to WINDOW_OPEN once no Challenge is pending; the earlier Verdict, if any, stands.
`window-closed`	WINDOW_OPEN; then AWAITING_CHILDREN. `closes_at` has passed and no Challenge is pending. The window is never extended: a dispute that outlasts it delays this entry and does not move `closes_at`.
`child-registered`	any non-terminal; unchanged. `object` is the child contract's digest; `facilitator` (URI). .
`child-final`	any non-terminal; unchanged. `object` is the child's Outcome Record digest; `child` (the child contract's digest).
`child-unresolved`	any non-terminal; unchanged. `child` (the child contract's digest). The child's latest finality instant () has passed and no Outcome Record for it is held.
`children-final`	AWAITING_CHILDREN; then terminal follows. Every registered child has a `child-final` or `child-unresolved` entry. A contract with no registered children records this entry on entering AWAITING_CHILDREN.
`terminal`	AWAITING_CHILDREN; then FINAL, SETTLED or ABANDONED. `state` (the terminal state) and `challenge_upheld` (boolean). ABANDONED where `deadline-passed` was recorded; SETTLED where the standing Verdict is FAIL, with `challenge_upheld` true when that Verdict answers a Challenge; FINAL otherwise.

The standing Verdict is the last verdict entry in the trace that no later entry supersedes. A Challenge is pending from its challenge entry until a verdict entry answers it, a dispute-lapsed entry names it, or a terminal entry is recorded. Every instant in the table is read from the Facilitator's clock, and an entry conditioned on an instant having passed is recorded at the first opportunity after it, which need not be that instant. Two Facilitators given the same posted records, the same clock readings and the same reports from the settlement binding record the same trace; that is the determinism the experiment in tests, and the reason every condition above is stated over the trace, the clock and the binding's report, and nothing else. An instant has passed when the Facilitator's clock reads that instant or a later one, and a record received when the clock reads an instant has arrived at it, so a Challenge received when the clock reads closes_at is after the window. Before acting on a posted record a Facilitator MUST first record every clock-driven entry that is due, so that the record is judged in the state the clock produced; entries due at the same instant are recorded in the order of the table. The at of an entry MUST be no earlier than that of the entry before it, and a Status's issued_at MUST be no earlier than the at of its last entry.

The Verifiable Task Contract A VTC is a JSON object, media type application/vnd.pact.contract+json, with the members in . A VTC is valid only if every required member is present, the Buyer and the Seller are distinct after normalization (), any named Verifier satisfies , and both the Buyer and the Seller have contributed exactly 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 . 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 revision omitted them, which made a signed contract replayable against any facilitator, chain or token contract.

A Verifiable Task Contract, signatures and parameters abbreviated The values are the reference repository's (), with the signatures abbreviated. The parameters object is shown elided on purpose: nothing in this document depends on what is in it.

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 revision 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 proof of nonconformance. The -01 revision stated the rule and its own reference TaskSpec broke it for three of four URIs; this revision's example carries all four sibling hashes, and the validator checks each. 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 the digest of its bytes in the string form of , over every file in the bundle. A file whose name, or any directory on whose path, begins with a dot is not part of a bundle. 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 same construction commits to a terms profile ().

The Task Specification The content committed by spec_hash is a TaskSpec: a JSON object with the members in , canonicalized per before hashing. It is not transmitted over the endpoints of this document; the parties exchange it before signing, and spec_uri may say where. 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 revision's schema permitted one, which made every proof of nonconformance impossible. 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.

Terms The terms member names the settlement terms both parties signed, by reference. It carries a profile URI, a profile_hash, and a parameters object. This document defines no obligation between parties and takes no position on the legal effect of any object it defines; what the named profile says the parties have agreed to, and what any of it means between them, is the profile's and its authors' to say. profile_hash is the manifest digest of over the profile's bundle. A bundle usable with this document contains at least three files: the profile's prose, parameters.schema.json, a JSON Schema for the parameters object, and vectors.json, whose form gives. A digest over prose alone would commit the parties to bytes and not to behaviour; the schema and the vectors are what make two implementations of the profile checkable against each other. A Facilitator MUST refuse a contract whose terms.profile and terms.profile_hash do not match an entry in the terms_profiles array of its own capability document (; terms-unsupported), so that no party signs terms the Facilitator will not evaluate, and MUST refuse a contract whose parameters do not validate against the named profile's parameters.schema.json (terms-parameters-invalid). This document reads parameters for no other purpose; the named profile's schedule and admission rule read them as the profile's. The rule of that an undefined member is rejected does not apply inside parameters; the profile's schema governs there. A profile usable with this document defines, in its prose, a schedule: a total, deterministic function from a contract and a trace prefix () to the list of entries the profile emits at the last event of that prefix, in the form of . Total means every event in has a defined result, including the ones a profile author would rather not think about: a lapsed dispute, an unresolved child, a contract abandoned before it was funded. Deterministic means the result depends on the contract, the trace and nothing else, so that any party holding those can recompute it. The prose also names the accounts the schedule moves value between, and says which of them are internal, opened empty and required to close empty, and which are external. A profile MAY also state an admission rule: a condition on the contract, evaluated once at accepted, whose failure is reported with a problem type from the profile's namespace (). This document does not register profiles and defines none normatively; carries one for the experiment. Everything the -01 revision said in its Section 5.3, and everything it said in its Section 7 about what is posted, released, returned or forfeited and when, is now the content of a profile. The member that carried those figures inside the contract is gone; the figures a profile needs are in parameters, and the -01 figures in particular are the parameters of the profile in .

Verdicts, Challenges and the Window

Flows The flow member selects one of three shapes for the state machine of . A conformant Facilitator MUST implement verdict-first and MUST list it in the flows member of its capability document (); the others are OPTIONAL, and a Facilitator MUST refuse a contract naming a flow it does not advertise (flow-unsupported).

verdict-first:: A Verdict is recorded before the window opens. The window opens on a PASS Verdict or on verdict-lapsed; a FAIL Verdict ends the contract without a window.
delivery-first:: The window opens at delivered. One Verdict MAY be recorded inside the window without a Challenge, and a second only in answer to one; a FAIL ends the contract, a PASS changes nothing.
no-window:: No window opens and no Verdict is accepted; delivered is followed by the terminal path.

The -01 revision had four release modes. Two of them produce the same trace and differed only in which event a profile acts on, which is a profile parameter and not a protocol matter. The mapping is in . The window opens at the instant of the window-opened entry and closes at that instant plus challenge.window_seconds, carried in the entry as closes_at. A Facilitator MUST NOT accept a Challenge after closes_at, MUST NOT extend the window for any reason, and MUST NOT record window-closed while a Challenge is pending.

Verdicts A Verdict is a signed statement that a Delivery was evaluated against the committed instrument, and with what outcome. It is a JSON object, media type application/vnd.pact.verdict+json, with the members in , signed once.

A Verdict The Verifier is the party identified by the kid of the Verdict's signature. Where the contract names parties.verifier, a Facilitator MUST refuse a Verdict signed by any other party; otherwise it MUST refuse a Verdict whose signer does not satisfy (verifier-not-independent). It MUST refuse a Verdict for a contract with no delivered entry (no-recorded-delivery); one whose delivery_hash does not match that entry, or whose profile or instrument_hash does not match the contract (verdict-nonconformant); one received in a state, or under conditions, that the table in does not list for it, or under the no-window flow (wrong-state); and one carrying challenge_hash that names no pending Challenge, or omitting it while the contract is DISPUTED (verdict-nonconformant). A Verdict recorded while one stands supersedes it, and both stay in the trace; since a Verdict is accepted while one stands only in DISPUTED, only a Verdict that answers a Challenge ever supersedes. 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 of , arriving from the verification side. Under verdict-first a Verifier that never answers would leave a contract in DELIVERED forever, and the -01 revision had no rule for it. verification.max_verdict_seconds bounds the wait: when it passes with no Verdict, the Facilitator records verdict-lapsed and opens the window, so that the contract can still be challenged and can still end. What a lapsed Verdict costs anyone is the profile's.

Challenges A Challenge is a JSON object, media type application/vnd.pact.challenge+json, with the members in , by which a party submits a proof of nonconformance (what optimistic systems call a fraud proof) inside the window. A Facilitator MUST refuse a Challenge received when the contract is not in WINDOW_OPEN or DISPUTED, or after closes_at (challenge-window-closed); one whose delivery_hash does not match the delivered entry (object-conflict); one whose proof does not conform to the verification profile (proof-nonconformant); one whose signer it cannot resolve (signature-invalid); and one signed by the contract's Seller (unexpected-signer), since a performer's statement against its own Delivery is not a proof of nonconformance and the -01 revision left the case open. A Facilitator MUST NOT refuse a Challenge on the ground that its signer is the contract's Buyer. A Challenge that is accepted is evaluated by a party satisfying , whose finding is a Verdict carrying challenge_hash; the Challenger's own assertion is not a finding, unless the Challenger is the verifier the contract names, whose Verdict is the finding by definition. A named Verifier that finds its own PASS wrong posts a Challenge and answers it. The Challenger is the party identified by the kid of the Challenge's signature. A capability document MAY advertise challenge_deposit. Whether anything must accompany a Challenge, how it is posted and what becomes of it are the terms profile's and the settlement binding's to say; this document carries the member and reads it for no purpose. discusses what a deposit does and does not prevent.

A Challenge under the acceptance profile

Disputes and Lapses A contract with a pending Challenge is DISPUTED. It leaves that state when a Verdict answers the Challenge, or when challenge.max_dispute_seconds pass with none and the Facilitator records dispute-lapsed. A lapsed Challenge changes no Verdict: the Verdict that stood before it stands after it. A Facilitator MAY accept further Challenges while DISPUTED, each of which is pending on its own account, and MUST NOT record window-closed until none is pending.

The dispute path: a Challenge answered by a FAIL Verdict | | | [ challenge ] | | |-- Challenge + Delivery -------->| | |<-- POST Verdict | | | | [ verdict FAIL, answers, | | | supersedes ] | | | [ children-final ] | | | [ terminal SETTLED, | | | challenge_upheld true ] | |<- Outcome ---| | ]]> The figure carries no rank, no waterfall and no amount. The -01 revision drew five numbered transfers on this diagram; every one of them is now a line in a profile's schedule, keyed to the terminal entry, and reported in terms_result.

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. Three profiles are defined below by name; any other is identified by a URI under its definer's control, and this document creates no registry for them. The distinction matters because the tier name does not determine how much checking a contract gets 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 about what performing it cost; running a committed acceptance instrument against the delivered artifact costs a small fraction of that. Those are the author's estimates, not measurements (the measurements mentions are of the protocol, not the work), and the two can differ by orders of magnitude in what checking costs relative to the price. A terms profile may make that ratio matter; this document requires of a verification profile the five statements listed after the profiles below, one of which is an order-of-magnitude estimate of its cost relative to the work, since a figure nobody can estimate is a figure nobody can use. 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 proof of nonconformance is a failing evaluation. Deterministic by construction, since the instrument is fixed before work begins. Cost: a small fraction of the work for a data transformation, by estimate.
bisection:: Interactive narrowing to a single disputed step, which is then checked directly. Cost grows logarithmically in the size of the computation rather than linearly.
full-reexec:: Re-execute and compare byte for byte. Sound only where the computation is deterministic and the environment is pinned; see . Cost: approximately the work.

A verification profile usable with this document states five things: what artefact is evaluated and against what; what constitutes a valid proof of nonconformance, including whether absence of evidence is one; that its proof can be evaluated by a party other than the Seller; its cost relative to the work, to order of magnitude; and whether it is deterministic and with what tolerance (). acceptance states these below; the other two are sketches that a full profile document completes; a profile defined elsewhere states them in its own document.

Verifier Independence and Identifier Normalization Independence is a relation between the party that signs a Verdict and the parties to the contract. It MUST be derived by the Facilitator and MUST NOT be satisfied by a field in which a record declares itself independent. Rules of this kind are stated for evaluation after the fact in ; this document binds them at contract formation. A Facilitator MUST refuse a Verdict whose signer is, after normalization, the contract's Buyer, Seller or Facilitator, and MUST refuse a contract whose parties.verifier is any of those three (verifier-not-independent). The last case is the rule the -01 revision stated as a prohibition on the Facilitator's conduct; it is an identifier comparison and is stated as one. 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 ".". The path of a did:web identifier is case sensitive and MUST NOT be folded. 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.

Contract Trees 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, in both directions and across Facilitators, so that a parent's Outcome Record can commit to its children's and a reader of the parent's record can find and check them.

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

Binding a Child to Its Parent A subcontract carries parent, a top-level member with the parent's vtc_id, vtc_hash and facilitator. Because parent is inside the bytes both parties sign, the child's Buyer signature is itself the authorisation to attach that child to that parent. The -01 revision carried this member inside the member it has since removed; it is structural and is now where structure is. The child's Facilitator need not resolve the parent, and across Facilitators it often cannot. It MUST record parent as signed, and MUST allow the identifier in parent.facilitator to retrieve the child's Status and Outcome Record (). The check that the child's Buyer is the parent's Seller is made where the parent is: at registration. The -01 revision required a Facilitator to reject a child whose parent chain contained the child's own identifier and to enforce a maximum depth. Neither rule survives, because neither is needed. A child commits to its parent's digest, and the parent's digest exists before the child is signed, so no contract can commit to a descendant and a cycle cannot be formed; depth is bounded by whatever a Facilitator is willing to register, and no Facilitator sees more than one level.

Registration and Children Final The parent's Facilitator learns of a child when the child's co-signed contract is posted to the parent's children resource (). Any holder of that contract may post it; the registration is authenticated by the child's own signatures, and the child's Buyer, which is the parent's Seller, is the party that ordinarily holds it. A registered child is identified at the parent's venue by its digest, so its id need not be unique there. A Facilitator MUST refuse a registration, with the problem type named, when: the body is not a valid contract (, the rules on members and signatures; its terms and deadline are its own Facilitator's to check); its parent.vtc_hash is not the parent's digest or its parent.facilitator is not this Facilitator (parent-unresolvable); its parties.buyer is not the parent's parties.seller after normalization (parent-unresolvable); its latest finality instant is not earlier than the parent's (, finality-ordering-violation); or the parent is terminal (wrong-state). An accepted registration is recorded as child-registered. Without the first 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 put a failed child under the competitor's record. The -00 revision carried the parent as a bare string with no hash and no check, so the attack cost one signature. A child becomes final for its parent when the parent's Facilitator holds the child's Outcome Record. It may obtain that record itself, by retrieving it from the child's Facilitator, or receive it by a POST to the child's entry under that resource (). Either way the Facilitator MUST verify the record's Facilitator signature against a key bound to the identifier the registration recorded, and MUST verify that its vtc_hash is the registered child's digest, refusing a record that fails either check (child-outcome-invalid), before recording child-final. Where the child's latest finality instant passes with no record held, the Facilitator records child-unresolved. children-final follows when every registered child has one entry or the other, and the parent's terminal entry follows that. A child that is never registered does not exist for the parent. Nothing in this document compels a parent's Seller to register a child, and says what that means.

Finality Is Bottom-Up A parent's Outcome Record MUST carry children_merkle_root over the Outcome Records of its registered children (), so a parent cannot be recorded until its children have been, and the parent waits in AWAITING_CHILDREN until they are. For that wait to be bounded, every child must be able to reach a terminal state, or be declared unresolved, before its parent needs it. The latest finality instant L of a contract is computed from its own members and nothing else: Every wait in is bounded by one of those members, and a Challenge can only be received before closes_at, so no sequence of events carries a contract past its L except waiting for its own children. A Facilitator MUST refuse to register a child unless L(child) is earlier than L(parent), and MUST record child-unresolved for a registered child no later than the first opportunity after L(child) if it holds no Outcome Record for it by then. The -01 revision compared the child's latest finality with the parent's earliest window close, and bounded neither: under its default mode the first Verdict could take forever, so the inequality guaranteed nothing. max_verdict_seconds is what makes L finite, and the waiting state is what makes the rule honest about the case where a child is late anyway.

Bottom-up finality What a child's outcome means for its parent is not stated here. No entry in a parent's schedule depends on any child's outcome unless the named terms profile says so; what this document guarantees is that the parent's Outcome Record commits to whichever child records exist when it is issued and names, in its trace, every child that does not.

Outcome Records An Outcome Record records what a contract did. It is a JSON object, media type application/vnd.pact.outcome+json, with the members in . 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. A Facilitator MUST issue exactly one Outcome Record for every contract that reaches a terminal state, including SETTLED and ABANDONED, MUST sign it, and MUST NOT require the signature of any other party on it. A Facilitator MUST serve the bytes of the record it signed rather than sign it again on retrieval; under a randomized signature scheme a second signing would produce a second record with a different digest. The -00 revision's record needed the signature of the party it recorded against, which made a reputation layer built on it structurally incapable of recording a loss. The Facilitator signature is what makes the record evidence: without it the record is a claim by interested parties about themselves, and with it a fabricated history requires a Facilitator's key rather than two identities.

An Outcome Record for a contract that reached SETTLED on an upheld Challenge The record carries one signature, the Facilitator's. The Seller did not consent to this record and its consent is not required. The transfers entries are elided here because their content is the profile's; shows them filled in for its own profile.

The Terms Result terms_result reports what the named profile's schedule produced over the whole trace. It carries the profile identifier and hash copied from the contract, the currency, and transfers: an array of entries, in the order the schedule produced them, each with event (the zero-based index of the trace entry at which the schedule emitted it), from and to (account names as the profile defines them), amount, and code (a string the profile defines, naming the schedule line that produced the entry). This document defines the form of the list and two arithmetic facts about it, and nothing about what any entry means. Over the internal accounts the profile declares (), which open empty: no entry takes from an account more than that account holds at that point in the list; and after the last entry every account the profile marks internal holds zero. The two facts are constraints on a profile, checked against its vectors before a Facilitator lists it (); a Facilitator MUST NOT sign an Outcome Record whose list breaks either, since such a list shows the profile it evaluates to be defective, and MUST NOT sign one whose list differs from what the profile's schedule produces for the record's own trace. Any party holding the contract, the trace and the profile's bundle can recompute the list; that is the property the experiment in depends on. vectors.json in a profile's bundle is an array of objects, each with name, contract (a VTC, or the members of one the schedule reads), and then either trace (a complete trace) with transfers (the list the schedule produces for it) and accounts (the profile's internal accounts, which open empty and must close empty), or admission (an object carrying either admitted, true, or refused, the problem type the admission rule answers with for that contract). A Facilitator MUST reproduce every vector of a profile before listing that profile in its capability document (), which is the only conformance requirement this document places on a profile implementation.

The Children Merkle Root Let D be the list of 32-byte SHA-256 digests of the Outcome Record of each registered child for which the Facilitator holds one, each computed over the record's canonical form including its signatures member, 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, because the prefixes are what make MTH the function defines, and a second implementation must compute the same root. The second-preimage attack the prefixes guard against, a leaf input chosen to equal an interior node's input, needs a leaf of that input's length; the fixed 32-byte digests in D cannot supply one, so here the prefixes buy agreement with the RFC rather than a defence the construction would otherwise lack. The member is present when at least one child is registered and absent otherwise; it MUST NOT be present with an empty or zero value, which would be indistinguishable from a tree whose children were withheld. Where every registered child is unresolved D is empty and the root is MTH of the empty list, SHA-256 of the empty string; the child-unresolved entries in the trace say which records the root does not cover. The -01 revision did not say whether a leaf covered the record's signatures; this revision says it does, so a record cannot be re-signed without changing the root.

Protocol Endpoints This section specifies the operations a Facilitator exposes. This document fixes no base URI; each is discovered from the endpoints member of the capability document (), so a Facilitator may mount them anywhere on its origin.

Propose a contract:: POST {contract}; body, a contract; 201 with a Status.
Retrieve a contract's status:: GET {contract}/{id}; 200 with a Status.
Register a child:: POST {contract}/{id}/children; body, the child's contract; 201 with a Status.
Supply a child's outcome:: POST {contract}/{id}/children/{child_hash}, where child_hash is the digest by which the registration identifies the child; body, the child's Outcome Record; 200 with a Status. This resource is keyed by digest, so the id rule of does not apply to it.
Submit a Delivery:: POST {delivery}; body, a Delivery; 202 with a Status.
Record a Verdict:: POST {verdict}; body, a Verdict; 201 with a Status.
Open a Challenge:: POST {challenge}; body, a Challenge; 202 with a Status.
Retrieve an Outcome Record:: GET {outcome}/{id}; 200 with the Outcome Record.

A request naming a contract the Facilitator does not hold is refused as unknown-contract (404). A body larger than the Facilitator accepts is refused as payload-too-large (413). A failure inside the Facilitator is reported as internal-error (500), the one problem type that names no rule. A GET of an Outcome Record before the terminal entry is refused as wrong-state. 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 . A Delivery and a Challenge are answered 202 (Accepted) because, in the sense of Section 15.3.3, their processing is not complete when the response is sent: what either record leads to may depend on a Verdict the Facilitator does not itself produce. A contract and a Verdict are answered 201 (Created); the contract is the resource the Location header names, and a Verdict, to which this document gives no resource of its own, is identified by the digest the Status in the response carries. A Facilitator authenticates the sender of a POST by the signature on the body, and by nothing else in this document: it MUST reject a Delivery not signed by the contract's Seller, a Verdict not signed by a party admissible under , a Challenge whose signer it cannot resolve, and a child registration or child outcome whose body does not verify as requires. A Facilitator MAY require an HTTP-layer authentication in addition. Retrieval is discussed in .

Proposing a Contract The request body is a VTC carrying the signatures of both parties required to sign it. A Facilitator MUST perform the checks in , and before creating the resource, MUST refuse a contract whose parties.facilitator is not itself or whose price.settlement, network or currency it does not advertise (facilitator-mismatch, settlement-unsupported), and MUST refuse otherwise with the problem type that names the rule. settlement-unsupported also covers a price stated in a currency other than max_contract_value's and a price above it; a verification profile the Facilitator does not list is refused as settlement-unsupported.

Idempotency Every object this protocol carries is committed by the digest of its own canonical form, so no separate idempotency key is needed and none is defined; the general mechanism of solves a problem this protocol does not have. A Facilitator MUST treat a POST whose body has a digest it has already accepted as a request for the existing resource, and MUST respond 200 (OK) with the current Status rather than creating a second resource or reporting a conflict. Where a POST carries the same object id as an existing resource but a different digest, the Facilitator MUST respond 409 (Conflict) (object-conflict). Retrying a submission is therefore safe when the same bytes are resent, and altering one never is. A record signed afresh is a different record with a different digest, not a retry: ECDSA signatures are randomized unless produced as describes, so a client signing with ES256 or ES384 SHOULD sign deterministically or keep the bytes it sent and resend those.

Error Responses A Facilitator MUST report failures using problem details, media type application/problem+json, with a type from for a rule in this document, or from the profile's own namespace for a rule in a terms profile. A problem arising from a rule in this document MUST carry section, the number of the section stating the rule. A problem arising from a rule in a terms profile MUST carry profile and profile_section instead, since section cannot name a rule outside this document. Error responses name the rule that was violated, because a conformance failure a caller cannot locate is a failure of the specification.

Exchange

HTTP exchange for the flow in | | |<-- 201 Status --------| | | | | |-- POST {delivery} --->| | |<-- 202 Status --------| | | | | | |-- GET work_uri ----->| | |<-- POST {verdict} ---| | |-- 201 Status ------->| | | | |-- GET {contract}/id ->| | |<-- 200 Status --------| | | | | |-- GET {outcome}/id -->| | |<-- 200 Outcome -------| | ]]>

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, Status, Outcome Record or capability document has, for each signer, the form of one signature object of the JWS General JSON Serialization, 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, and verifies over the protected header exactly as transmitted, never over a header it re-serialized. The following constraints apply.

The protected header MUST carry alg, kid and typ.
alg MUST be Ed25519 with an Ed25519 key, or ES256 or ES384 with a P-256 or P-384 key. A verifier MUST reject any other value, including the polymorphic EdDSA identifier of that deprecates, and MUST reject none (algorithm-not-permitted). 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.
The protected header MUST NOT carry jwk, jku, x5c, x5u, x5t, x5t#S256 or crit, and a signature entry MUST NOT carry an unprotected header; a verifier MUST reject an entry carrying any of them (signature-invalid). A key travels by reference and never inline, so that the kid rule cannot be bypassed.
The resolved key MUST be of the type and curve alg requires: Ed25519 for Ed25519, P-256 for ES256, P-384 for ES384. A mismatch is signature-invalid.
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 .
A signatures array MUST be sorted by the normalized kid of its entries (), ties broken by the unnormalized kid, both compared as sequences of Unicode code points; a verifier MUST reject an unsorted array (signatures-unordered). Two clients that each attach their own entry and exchange the object would otherwise produce two arrays, and since the digest covers the array, two digests for one agreement.
An ECDSA signature MUST have its s value in the low half of the curve order, that is s at most n/2 for the order n of the curve , and a verifier MUST reject one that does not. fixes the encoding and not which of the two valid s values is accepted; accepting both lets anyone holding a valid signature produce a second one over the same bytes without the key, and a second signature is a second digest. Ed25519 verification per already rejects a non-canonical S, so the rule is stated for ECDSA only.

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. An identity system for agents defined elsewhere, such as , is used by naming its identifiers here in one of these two forms; a further form needs a resolution rule added to this list, which is the one change it would take.

Rules Not Expressible in a Schema

parties.buyer and parties.seller MUST be distinct after the normalization in (parties-not-distinct).
A contract MUST carry exactly one verifying signature whose kid covers parties.buyer, exactly one whose kid covers parties.seller, and no other (signature-missing, unexpected-signer). A count of signatures is not sufficient: two signatures covering one identifier MUST be rejected.
challenge.window_seconds, challenge.max_dispute_seconds and verification.max_verdict_seconds MUST be greater than zero, and task.deadline MUST be later than the instant of acceptance (deadline-invalid).
Every URI member inside hash-committed content MUST have a sibling hash member, and a validator MUST reject content carrying harness_uri, rubric_uri, schema_uri or sample_uri without its hash.
An acceptance object MUST carry the members required for the contract's tier. An empty acceptance object MUST be rejected.
terms.profile and terms.profile_hash MUST match an entry the Facilitator advertises, and terms.parameters MUST validate against that profile's schema (terms-unsupported, terms-parameters-invalid).
Every object MUST validate against the schema published for its media type (schema-invalid), which includes the form of every amount (); an amount carrying more decimal places than the settlement binding named in price.settlement supports is refused (amount-invalid).

Test Vectors Most rules above have an accepting and a rejecting form; the table carries the ones a suite most often gets wrong. 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	`terms.profile_hash` not advertised by the Facilitator	reject
V-13	`terms.parameters` failing the profile's schema	reject
V-14	Delivery with `evidence` absent	reject, no entry
V-15	child whose buyer is not the parent's seller	reject
V-16	child with L(child) not earlier than L(parent)	reject
V-17	Verdict signed by the seller	reject
V-18	object keys ordered by code point rather than UTF-16 unit, a supplementary-plane key beside one in U+E000 to U+FFFF	digest mismatch
V-19	buyer and seller differing only in the case of a `did:web` path	accept
V-20	object carrying a member this document does not define for it	reject
V-21	`signatures` not sorted by normalized `kid`	reject
V-22	ECDSA signature with `s` above n/2	reject
V-23	Verdict with `delivery_hash` computed over the Delivery without its signature	reject
V-24	Outcome Record whose `transfers` overdraw an account of the profile	reject
V-25	a number serialized by the host language's default formatter, such as `1.0` for the float one	digest mismatch
V-26	a protected header carrying a member forbids: `jwk`, `jku`, `x5c`, `x5u`, `x5t`, `x5t#S256` or `crit`	reject

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. V-19 is the opposite mistake, folding more than allows, and the -01 reference validator made it. V-25 is the number half of the V-18 mistake: prints numbers as ECMAScript does, so the float one is 1 and never 1.0. The -02 reference canonicalizer printed 1.0 until this vector caught it, and the spec_hash, vtc_hash and delivery_hash of changed when it was fixed.

Worked Example The digests below are the reference repository's, at the tag named in . The object figures in earlier sections are the repository's objects with their signatures abbreviated and the contract's parameters elided; the digests here are computed over the full objects. The figures that the -01 revision printed here about a bond and a required detection rate are now the profile's; carries the rule and the parameters. A buyer commissions a data transformation at a price of 180.00 USDC under the verdict-first flow, the acceptance verification profile, and the terms profile of with the parameters shown there. The digests carried by the reference TaskSpec, contract and profile 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. profile_hash is the same construction over the profile bundle. vtc_hash is the digest of the signed contract, and delivery_hash of the signed Delivery, both per . The -01 revision printed three of the values above, spec_hash, criteria_hash and vtc_hash, and each differs from what it printed, for reasons recorded so that a reader comparing the two documents can account for the difference. spec_hash and vtc_hash differ because the -01 canonicalizer serialized numbers as the host language printed them (, V-25); spec_hash also because the TaskSpec now carries the sibling hashes always required, and vtc_hash also because the contract's members changed (). criteria_hash carries no number; it differs because the two files of the instrument bundle were edited to drop their mention of the withdrawn call-for-bids example. profile_hash is new, and delivery_hash, which the -01 figures showed only as a placeholder, now covers the Delivery's signature. The traces the reference implementation records for this contract on the path of and on the dispute path of carry the event sequences of the first two vectors in the profile's bundle, and the transfer lists the profile produces for them are those vectors' lists; the vectors name their objects by placeholder digests, so the match is of sequence and lists, not of bytes. prints both lists.

Security Considerations Most of what follows was found by adversarial review of earlier revisions rather than anticipated when they were 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. The table first: for each party, what the protocol enforces against it, what it records about it, and who can check the record without trusting the Facilitator. What the protocol enforces, records and lets others check, by party

Party	Enforced against it	Recorded about it	Checkable by
Buyer	cannot alter the task, instrument or terms after signing; cannot attach a child to a contract it is not party to	its signature on the contract; any Challenge it signs	anyone holding the contract
Seller	cannot deliver against a substituted instrument or input; is refused as Verifier when it signs under a party identifier; cannot re-sign a record without changing every digest over it	its signature on the contract and the Delivery; the Verdicts and Challenges on its Delivery	anyone holding the contract and the Delivery
Verifier	cannot be a party to the contract; must commit to the instrument it ran and its results	its Verdicts, superseded ones included	anyone holding the Delivery and the instrument
Facilitator	nothing	what it chose to sign, in the order it chose, on a clock that is its own	any holder of two of its Statuses, for equivocation; nobody, for omission or for time, without a witness outside this document

Trust in the Facilitator The Facilitator row is the honest one. This protocol enforces nothing against a Facilitator; it makes some kinds of misbehaviour attributable and says plainly which ones it does not. Equivocation, issuing two inconsistent histories for one contract, is attributable: every Status is signed, every Status's trace is a prefix of every later one, and two Statuses that break that rule are proof, checkable by anyone holding both, that the Facilitator signed contradictory records. A Facilitator that wants to make its records publicly append-only can register its Outcome Records with a SCITT transparency service and hand the receipt to the parties; this document does not require it and defines no log of its own. Omission is not attributable. A Facilitator that declines to record a Delivery, or records it late, produces no signed evidence of having declined, and a Status it does not issue proves nothing. A client SHOULD retain every Status it receives, and a party that submitted a record and holds no Status for it has a claim it can make only outside this protocol. Making omission attributable needs a witness the Facilitator does not control, such as the client gossip that Section 11.3 mentions and leaves undefined, and this document specifies none. Time is the Facilitator's. Every instant in a trace is read from its clock, and nothing in this document lets a party prove that a recorded instant is wrong. This document therefore states the assumption rather than hiding it: the Facilitator is a trusted timekeeper, and a deployment that cannot accept that should look to an external timestamping service, which this document does not specify and does not preclude. Whatever a Facilitator does with anything of value under a terms profile is the profile's subject and is not addressed here.

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.

Algorithm, Key and Encoding 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. Because every digest in this document covers a signature set, a second valid encoding of one signature is a second digest for one record. ECDSA has two valid s values per signature and JWS does not choose between them; the low-S rule in does. The order of a signature set is a second source of the same problem, and the sorting rule closes it.

Substitution of Committed Content The -00 revision 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 proof of nonconformance. 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.

Fetching Committed Content A work_uri, results_uri or any other URI in a record is supplied by a counterparty and points wherever that counterparty chose. An implementation that fetches it MUST fetch over HTTPS only, MUST NOT follow a redirect to a scheme other than HTTPS, MUST refuse to connect to a private, loopback or link-local address (the ranges of , and their loopback and link-local counterparts), and MUST verify the sibling hash over the full received bytes before any byte is used for anything. A fetcher that acts on partial or unverified content has handed its counterparty a way to make it execute, store or judge something that was never committed to.

Children: Attachment and Omission Naming a parent contract cost one signature in the -00 revision and was checked against nothing. requires the child's Buyer to be the parent's Seller, checked by the Facilitator that holds the parent against the parent's own bytes. The converse gap is stated rather than closed: a parent's Seller that never registers a failing child keeps it out of the parent's record, since this document compels no registration. A profile that wants children visible must make registration worth the Seller's while, or a Buyer that wants them visible must ask for the child's Status directly, which this document does not require the child's Facilitator to give it.

Buying Silence from a Challenger Wherever what a discoverer gains by reporting is less than what a performer loses by being reported, there is a private payment that leaves both better off than reporting, and silence dominates whatever reward a profile designed. This document cannot close that, because every figure involved is the profile's. What it does is record every Challenge, in order, whoever signed it, so that a profile can act on each independently, and it forbids a Facilitator from refusing a Challenge because the Buyer signed it (), so that the party with the most to recover is always admissible.

Non-Delivery Under the -00 revision a contract in which nothing was ever delivered had no path to an end: the deadline carried no stated consequence and no window opened because there was nothing to challenge. makes the deadline an event and ABANDONED a terminal state that every contract can reach. What reaching it costs anyone is the profile's, and a profile that makes delivering nothing cheaper than delivering something wrong has recreated the -00 incentive.

Cross-Venue Replay A VTC that does not name its Facilitator, network and asset is a signed instrument replayable against any of them; requires all three inside the signed content. A digest 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; defines every digest over the 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 found wrong by a re-execution that differs for ordinary reasons. A cheating Seller escapes any proof of nonconformance by asserting nondeterminism, unfalsifiably. A verification profile MUST state whether it is deterministic and what tolerance applies, and a contract naming one that does not cannot be judged safely by anyone.

Fabricated History The argument for reputation derived from Outcome Records is that faking a history requires running real contracts. That argument fails if records do not name the parties or carry no Facilitator signature, since two cooperating identities can then manufacture history at the cost of two signatures. requires both. It fails in the other direction if a negative outcome requires the signature of the party it records against; reputation that is structurally incapable of recording a loss is not evidence of anything.

Retrieval A GET on a contract's Status or Outcome Record MUST be refused (retrieval-restricted) unless the requester is a party named in the contract's parties, the identifier in the contract's parent.facilitator, or a party the Facilitator has chosen to admit; a Facilitator MAY open retrieval more widely and SHOULD say so in its capability document (retrieval, ). How a requester proves which identifier it is, on a GET with no body to sign, is an HTTP-layer matter this document leaves to the deployment. The -01 revision left retrieval unauthenticated by default, which published every contract graph a Facilitator held to anyone who could guess an identifier.

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 retain, for as long as it retains a record it accepted, the key material or its digest as resolved at the time of acceptance, and SHOULD make it available to a party retrieving the record, so that a later rotation does not make an earlier signature unverifiable; and a Facilitator MUST NOT accept a record 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 a Verifier's or a Facilitator's capacity by challenging every Delivery. A deposit required by a terms profile, advertised as challenge_deposit (), is one defence, and this document requires none, since a deposit also deters the honest Challenger an open model relies on. A Facilitator whose profiles require 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 Contract Graph A Facilitator that publishes its Outcome Records 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: retrieval is restricted by default (), a Facilitator MAY publish aggregates, and SHOULD NOT publish per-contract records identifying both parties without their agreement. Outcome Records leak the same graph by construction, since each names both parties and the counterparty retains a signed copy indefinitely. Selective disclosure over Outcome Records, so that a holder can prove a completed contract without revealing the counterparty, is possible with mechanisms specified elsewhere 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 proof of nonconformance. 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 visible: a contract whose content cannot be disclosed to a Challenger will receive no Challenge from outside its parties, and a terms profile that counts on one has counted on nothing.

Retention Retention periods stated for dispute purposes can conflict with erasure requests from 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 seven media types in the vendor tree and one well-known URI. It creates no registry. It defines problem types but does not ask for a registry of them (). The -01 revision asked for two registries, one of verification profiles and one of settlement bindings, and listed under the second an identifier in another project's namespace that nobody had defined; both requests are withdrawn. A profile of either kind is identified by a URI under its definer's control and needs no registration.

Media Types IANA is requested to register the following in the "Media Types" registry, per , in the vendor tree. The template below is given once in full; the seven 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 can produce a divergent digest when a key outside the Basic Multilingual Plane is compared with one whose first differing unit lies in U+E000 to U+FFFF.
Published specification:: This document
Applications that use this media type:: Services and autonomous agents forming and recording task 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:: Laxmikant Sharma

Media types registered by this document

Subtype name	Object	Defined in
vnd.pact.contract+json	Verifiable Task Contract
vnd.pact.delivery+json	Delivery
vnd.pact.verdict+json	Verdict
vnd.pact.challenge+json	Challenge
vnd.pact.status+json	Contract Status
vnd.pact.outcome+json	Outcome Record
vnd.pact.facilitator+json	Capability document

The -01 revision asked for these in the standards tree under the names pact-contract+json and so on. Registration in that tree from outside the IETF stream needs approval this document does not have (, Section 3.1), and Section 3.2 opens the vendor tree to anyone who interchanges files associated with a publicly available product.

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

URI suffix:: pact-facilitator
Change controller:: Laxmikant Sharma
Specification document(s):: This document,
Status:: provisional
Related information:: The resource is served with media type application/vnd.pact.facilitator+json and MUST be signed.

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 tag:laxsharma79@gmail.com,2026:pact:problem:, a tag URI under the author's control. A tag URI is an identifier and does not dereference. Section 4 says a type URI SHOULD resolve to documentation; this document departs from that on purpose, so that an identifier does not change when hosting does, which the -01 revision's prefix on a code-hosting site could not promise, and the section named for each type is its documentation. The list of types, each with its status and the section that defines it, is printed by the reference implementation in the repository named in , and the section named for each type says what it means. Each entry carries the identifier, the HTTP status it accompanies, and the section stating the rule it reports. A terms profile that refuses a request defines its own types under its own prefix and reports them as says. Problem types defined by this document

Identifier	Status	Defined in
algorithm-not-permitted	400
amount-invalid	422
challenge-window-closed	409
child-outcome-invalid	422
deadline-invalid	422
evidence-nonconformant	422
facilitator-mismatch	422
finality-ordering-violation	422
flow-unsupported	422
internal-error	500
no-recorded-delivery	409
object-conflict	409
parent-unresolvable	422
parties-not-distinct	422
payload-too-large	413
proof-nonconformant	422
retrieval-restricted	403
schema-invalid	422
settlement-unsupported	422
signature-invalid	400
signature-missing	400
signatures-unordered	422
terms-parameters-invalid	422
terms-unsupported	422
unexpected-signer	422
unknown-contract	404
verdict-nonconformant	422
verifier-not-independent	422
wrong-state	409

The table is generated from the reference implementation's own list, so that every type an implementation of this document emits has a line here. The -01 revision listed eight of the twenty-nine its implementation used.