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

1.1. Motivation

By late 2026 an autonomous agent can prove who it is, show whose authority it acts under, discover another agent, call it, record what happened in a tamper-evident receipt, and pay for the call. Each of those is the subject of active standardisation, and several are specified in more detail than this document specifies anything.¶

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

1.2. 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 (Section 5); a Delivery record and the Verdict record bound to it by digest (Section 6, Section 7.2); an event trace, signed by a Facilitator, from which one Outcome Record per contract is produced (Section 11, Section 12); and a Merkle commitment from a parent's Outcome Record to its children's (Section 12.2).¶

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 (Section 5.3). 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 [RFC9325]; 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 [RFC8555] 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 ([RFC5280], Section 4.2.1.4), and the framework for writing those rules [RFC3647] says it does not aim to provide legal advice. The Internet Open Trading Protocol [RFC2801] 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 [I-D.laxsharma-pact-00] remain withdrawn: contract channels, and the sealed-bid award procedure. The reasons are recorded in [I-D.laxsharma-pact-01] and are not repeated. The changes from the -02 revision [I-D.laxsharma-pact-02] are listed in Appendix B, and that revision lists those from -01.¶

1.3. Relationship to Existing Work

PACT's agree, perform, verify, record loop is an instance of optimistic fair exchange [ASOKAN98], 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. [I-D.hood-agtp-commerce] carries Work Completion Records and an audit-verified settlement timing; [I-D.stone-vcap-ap2-binding] binds verified commerce settlement to the Agent Payments Protocol. 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.

[RFC9334] 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; the -02 revision renamed the record, and this document defines its remaining shared vocabulary in Section 2.1. Where a verification tier relies on hardware attestation, the RATS architecture applies unchanged and PACT consumes its results.¶

SCITT.

[RFC9943] defines signed-statement transparency and [RFC9942] 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 Section 17.1 says which Facilitator misbehaviour that closes. The Merkle commitment in Section 12.2 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 [RFC9162] for its construction only.¶

HTTPAPI.

[I-D.ietf-httpapi-idempotency-key-header] 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 (Section 13.2). Error reporting follows [RFC9457].¶

WIMSE.

[I-D.ietf-wimse-aims] gives workload and agent identity a home. PACT does not define an identity format; a kid resolves as Section 14.1.1 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.

[I-D.ietf-satp-core] 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 [RFC9334] and the EAT format of [RFC9711]. Signed, hash-chained action receipts [I-D.sahu-agent-action-receipts], composition of accountability records [I-D.mih-sato-agent-accountability-composition], delegation chains [I-D.asor-wimse-agent-delegation-chain], and contestability bindings [I-D.pinto-agent-authz-contestability] are each specified elsewhere, and PACT consumes rather than restates them.¶

1.4. The Experiment

This document is Experimental, 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 (Section 4.2). Given the same trace and the same terms profile, they should produce the same Outcome Record body (Section 12), 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 Figure 2 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 Section 16. The non-normative profile in Appendix A exists so that the experiment can be run before any other profile is written.¶

2.1. 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 Section 5, 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 [RFC9334], 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 [RFC9334]. 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 Section 4 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 Section 3.10, and the objects by their members in Section 3.¶

3.1. Members Common to Every Record

pact:

string, required. The protocol version; 0.3 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 Section 14.1, 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 Section 14.1, sorted as that section says. Commits, in the contract, to who agreed; in the Outcome Record, to which Facilitator issued it.¶

3.2. Contract Members

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

id:

string, required. Contract identifier, unique among the contracts of the Facilitator named in parties.facilitator, and neither "." nor "..", which resolution of {contract}/{id} (Section 13) would remove.¶

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 (Section 5.2); 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 (Section 4.2).¶

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; Section 9), criteria_hash (digest, required; the manifest digest of the acceptance instrument per Section 5.1), 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 (Section 7.1). Selects the shape of the state machine for this contract.¶

terms:

object, required (Section 5.3). profile (URI, required) names a terms profile; profile_hash (digest, required) commits to the profile's bytes as Section 5.3 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 (Section 10). vtc_id (string, required), vtc_hash (digest, required), and facilitator (URI, required) identify the parent contract and the Facilitator that holds it.¶

3.3. TaskSpec Members

The TaskSpec is the content committed by task.spec_hash (Section 5.2). 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. This document evaluates nothing in it, and a PASS speaks to acceptance only; whether a verification profile reads any of it is a statement that profile makes (Section 9).¶

3.4. Delivery Members

Carried in the Delivery (Section 6), 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 Section 5.1 where the deliverable is a bundle.¶

work_uri:

URI, optional. Where the bytes may be fetched, subject to Section 17.5.¶

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

3.5. Verdict Members

Carried in the Verdict (Section 7.2), 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.¶

3.6. Challenge Members

Carried in the Challenge (Section 7.3), 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 only the form of its amount (Section 14.2); its meaning is the named terms profile's.¶

3.7. Contract Status Members

Carried in the Contract Status (Section 11), 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 Figure 2.¶

trace:

array of objects, required. The event trace so far, in the order recorded (Section 4.2). Each entry carries event (string, required), at (timestamp, required), object (digest, required on the events for which Table 2 names it), and the event-specific members listed in Section 4.2.¶

issued_at:

timestamp, required. When this status was signed.¶

3.8. Outcome Record Members

Carried in the Outcome Record (Section 12), 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.¶

task:

object, required. spec_hash (digest, required): the contract's task.spec_hash, copied. No other member of the contract's task is copied.¶

verification:

object, required. The contract's verification object, copied, so that the record says what judged the work and against what.¶

flow:

string, required. The contract's flow, copied.¶

outcome:

object, required. state (string, required; FINAL, SETTLED or ABANDONED), challenge_upheld (boolean, required) and verdict (string, required): the digest of the Verdict standing at the terminal entry, or verdict-lapsed, or none (Section 12).¶

work_hash:

digest, present exactly where the trace has a delivered entry: the work_hash of the Delivery that entry names. 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 (Section 12.1). 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 (Section 12.2).¶

3.9. Capability Document Members

Carried in the Facilitator capability document (Section 8), 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; Section 8 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 Section 7.1 the Facilitator implements; Section 7.1 requires verdict-first among them.¶

verification_profiles:

array of strings, required. A contract naming a profile not listed is refused (Section 13.1).¶

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

challenge_deposit:

object, optional. amount and currency; see Section 7.3.¶

retrieval:

string, optional. parties, the default of Section 17.12, or open.¶

endpoints:

object, required. Maps each endpoint name in Section 13 to an absolute URI.¶

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

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

4.1. States

 ACCEPTED -funded-> 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 (Section 4.2), 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.¶

4.2. 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 table names one (the digest, Section 2, of the record the table names), and the members listed for the event, each required unless the table marks it optional or states when it is present. 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 (Section 17.1 says what that rule does and does not prove).¶

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 Section 1.4 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 issuing a Status or acting on a posted record a Facilitator MUST first record every clock-driven entry that is due, so that the Status is issued and the record 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.¶

5.1. Hash Commitments and Content Conveyance

Every URI carried inside hash-committed content MUST be accompanied by a sibling hash over the dereferenced bytes. The -00 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 Section 2, 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 (Section 5.3).¶

5.2. The Task Specification

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

5.3. 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 Section 5.1 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 [I-D.bhutton-json-schema] for the parameters object, and vectors.json, whose form Section 12.1 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 (Section 8; 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 Section 2 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 (Section 4.2) to the list of entries the profile emits at the last event of that prefix, in the form of Section 12.1. Total means every event in Table 2 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 (Section 13.3). This document does not register profiles and defines none normatively; Appendix A 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 Appendix A.¶

7.1. Flows

The flow member selects one of three shapes for the state machine of Section 4.1. A conformant Facilitator MUST implement verdict-first and MUST list it in the flows member of its capability document (Section 3.9); 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 Appendix A.2.¶

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

7.2. 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 Section 3.5, signed once.¶

========== NOTE: '\' line wrapping per RFC 8792 ===========

{
  "pact": "0.3",
  "type": "Verdict",
  "vtc_id": "vtc_9f2c11",
  "delivery_hash": "sha256:dfabe6a5d1aaf23868dec65e1517dc0dfa911b\
   41054ea10d641bb919aed34c95",
  "outcome": "PASS",
  "profile": "acceptance",
  "instrument_hash": "sha256:0bdde1ab6b081d2b4bda580c5393756ae95c\
   10b8351c9c55eb9316416265fc1b",
  "results_hash": "sha256:28d334e0e0e0771eb5708452612ebcc6fbf848e\
   baca540214b4f6d2165688a51",
  "evaluated_at": "2026-11-10T09:14:22Z",
  "signature": {
    "protected": "...",
    "signature": "..."
  }
}

The Verifier is the party identified by the kid of the Verdict's signature. Where the contract names parties.verifier, a Facilitator MUST refuse a Verdict signed by any other party; otherwise it MUST refuse a Verdict whose signer does not satisfy Section 9.1 (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 Section 4.2 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 Section 17.4, arriving from the verification side. A Verdict reaches the delivered bytes through the Delivery: its delivery_hash commits to the Delivery, signature included, and the Delivery's work_hash commits to the bytes, or to their manifest where the deliverable is a bundle (Section 5.1), so a reader who holds both records can tell which bytes were judged.¶

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

7.3. Challenges

A Challenge is a JSON object, media type application/vnd.pact.challenge+json, with the members in Section 3.6, 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 Section 9.1, 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. Section 17.14 discusses what a deposit does and does not prevent.¶

========== NOTE: '\' line wrapping per RFC 8792 ===========

{
  "pact": "0.3",
  "type": "Challenge",
  "vtc_id": "vtc_9f2c11",
  "delivery_hash": "sha256:dfabe6a5d1aaf23868dec65e1517dc0dfa911b\
   41054ea10d641bb919aed34c95",
  "proof": {
    "profile": "acceptance",
    "instrument_hash": "sha256:0bdde1ab6b081d2b4bda580c5393756ae9\
   5c10b8351c9c55eb9316416265fc1b",
    "results_hash": "sha256:7f05a60223e24ca9393e0c241d0448cb5f39e\
   5edb71c117fb7d3d593d5861b40",
    "results_uri": "https://watch.example/o/a91e",
    "failing_checks": ["schema_valid_rate", "row_count_min"]
  },
  "costs": {
    "amount": "1.20",
    "currency": "USDC"
  },
  "signature": {
    "protected": "...",
    "signature": "..."
  }
}

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

  Buyer        Facilitator       Verifier      Challenger
    |              |                 |               |
    |              |<-- POST Verdict |               |
    |              |   [ verdict PASS ]              |
    |              |   [ window-opened ]             |
    |              |<------------- POST Challenge ---|
    |              |-- Status ---------------------->|
    |              |   [ 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.¶

9.1. Verifier Independence and Identifier Normalization

Independence is a relation between the identifier that signs a Verdict and three identifiers of the contract: the Buyer's, the Seller's and the Facilitator's. 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 [X402COMPLIANCE]; 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. Normalization decides whether two identifiers are equivalent under the rules below, and nothing more. Whether two identifiers that are not equivalent belong to one controller is outside what this protocol can see, which is why Table 4 says only that a Seller is refused as Verifier when it signs under an identifier equivalent to the Buyer's, the Seller's or the Facilitator's.¶

A party identifier, or a kid, is normalized by the following steps, in this order. An identifier that a step finds not evaluable is not normalized further.¶

1. Every character, including those of the fragment, MUST be in the range %x21 to %x7E. An identifier with any other character, such as whitespace or a character outside ASCII, is not evaluable. Nothing is stripped.¶
2. The fragment, the first "#" and everything after it, is removed.¶
3. The identifier is read once, from left to right. Every "%" MUST begin an escape of two hexadecimal digits. A "%" that does not, or an escape of an unreserved character (ALPHA, DIGIT, "-", ".", "_" or "~", [RFC3986] Section 2.3), makes the identifier not evaluable. Nothing is decoded, so "%2541" is the escape "%25" followed by "41".¶
4. Every "/" at the end of the identifier is removed. A "." is not: one at the end of the host is removed by step 9, and one at the end of a path segment is part of that segment.¶
5. The scheme is lower-cased. It MUST be did or https, the two forms of Section 14.1.1; any other scheme makes the identifier not evaluable.¶
6. A did identifier MUST match the did rule of [DID-CORE], which allows only lower-case letters and digits in the method name and no path or query, so did:WEB: does not parse. An https identifier MUST match the URI rule of [RFC3986] with an authority, so a character that rule does not admit, such as "\", does not parse; it MUST NOT carry userinfo ([RFC9110], Section 4.2.4). The host of a did:web identifier is its method-specific identifier up to the first ":", less any port, which [DID-WEB] writes as "%3A" and digits ("%3a" is the same escape); the host of an https identifier is that of its authority. A port is digits and MUST NOT begin with "0". A host MUST NOT contain "%", MUST NOT be an IP literal, and the last of its labels that is not empty MUST NOT begin with a digit. A segment of an https path, or of a did:web method-specific identifier between its ":" separators, MUST NOT be "." or "..". An https path MUST NOT contain "//", a did:web method-specific identifier MUST NOT contain "::", and an https query MUST NOT be empty. An identifier that fails any of these is not evaluable.¶
7. The host of a did:web or https identifier is lower-cased. Nothing else is: the segments of a did:web identifier after its host, and the path and query of an https identifier, are case sensitive.¶
8. The hexadecimal digits of every escape are upper-cased ([RFC3986] Section 6.2.2.1). This step comes before step 10, so that a port written "%3a443" is matched there as "%3A443".¶
9. Every "." at the end of the host is removed. A host that is then empty is not evaluable.¶
10. A port that is empty or 443 is removed: ":" or ":443" after an https host, "%3A" or "%3A443" after a did:web host, each matched as a fixed string ([RFC3986] Section 6.2.3). An https path that is exactly "/" is removed.¶

Two identifiers are equivalent when their normalized forms are equal, character for character. Hosts are therefore compared as A-labels [RFC5890]: a U-label fails step 1, and a host written with escapes fails step 6.¶

Step 3 is stricter than [RFC3986], whose Section 6.2.2.2 normalizes an escaped unreserved character by decoding it. This document refuses that form instead, as its own choice, so that no decoder sits on the comparison path. Step 6 refuses seven more forms rather than rewrite them: userinfo; a port with a leading zero; a "." or ".." segment, which [RFC3986] Section 6.2.2.3 would remove; a host with an escape in it, which the reg-name rule of [RFC3986] admits; a host that is an IP literal, since one IPv6 address has several spellings, or whose last label that is not empty begins with a digit; an empty query; and an empty segment between two separators, "//" or "::". The rule on a host's last label is this document's own choice, as step 3's is: it refuses every host written as an IPv4 address in the decimal, octal or hexadecimal forms some URL parsers accept, and some host names besides. The refusals cover those forms and say nothing more about aliasing. Two steps fold further than [RFC3986] instead. Step 4 removes every "/" at the end of the identifier, so "https://h.example/a/" and "https://h.example/a" are equivalent here, though a server may answer them as two resources. A "/" it removes may also end a query or a did: identifier. Step 9 removes a "." at the end of a host.¶

An identifier that is not evaluable is never compared and MUST NOT be treated as outside the parties. A Facilitator MUST refuse a contract that carries one in parties or parent.facilitator, and any record signed under a kid that is one (identifier-not-evaluable). The refusal of a contract comes before the schema check of Section 14.2, so a party identifier that the published schema also rejects is refused as identifier-not-evaluable. An independence claim reaches exactly as far as the record's own commitments.¶

10.1. 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 (Section 17.12). 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.¶

10.2. 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 (Section 13). 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 (Section 14.2, the rules on members and signatures; its terms and deadline are its own Facilitator's to check, and this Facilitator reads the deadline only to compute the child's latest finality instant, Section 10.3); 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 (Section 10.3, finality-ordering-violation); or the parent is terminal (wrong-state). An accepted registration is recorded as child-registered.¶

   child.parties.buyer  ==  parent.parties.seller
   child.parent.vtc_hash  ==  digest(parent)

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 (Section 13). 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. The Facilitator MUST also refuse, as child-outcome-invalid, a record whose parties, task.spec_hash, verification or flow is not the registered child contract's, or whose outcome.verdict is not the value its own trace gives (Section 12). The parent's Facilitator does not hold the child's Delivery, so it cannot check that a record's work_hash is that Delivery's. The Facilitator MUST refuse a record that differs from one it already holds for that child (object-conflict), and, once the parent has its terminal entry, a record for any child whose record the Facilitator does not hold (wrong-state). 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 a child-final or a child-unresolved entry, or both, 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 Section 17.6 says what that means.¶

10.3. Finality Is Bottom-Up

A parent's Outcome Record MUST carry children_merkle_root over the Outcome Records of its registered children (Section 12.2), 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:¶

   verdict-first:  L = task.deadline
                       + verification.max_verdict_seconds
                       + challenge.window_seconds
                       + challenge.max_dispute_seconds
   delivery-first: L = task.deadline
                       + challenge.window_seconds
                       + challenge.max_dispute_seconds
   no-window:      L = task.deadline

Every wait in Table 2 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, and a verdict-lapsed entry recorded after the instant it fell due, whose window then closes that much later. 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.¶

 parent |== work ==|= verdict =|= window =|= dispute =|
                                                      ^ L(parent)
 child  |== work ==|= vrd =|= win =|= dsp =|
                                           ^ L(child)

        a child is registered only where L(child) < L(parent)

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

12.1. 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 (an amount of Section 2, written with the fewest decimal places that keep its value and never fewer than two, so that two Facilitators that produce one list sign the same bytes), 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 (Section 5.3), 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 (Section 8); 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. A Facilitator that finds a list breaking either records nothing of the request that produced it and answers internal-error. Any party holding the contract, the trace and the profile's bundle can recompute the list; that is the property the experiment in Section 1.4 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 (Section 8), which is the only conformance requirement this document places on a profile implementation.¶

12.2. 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 [RFC9162] Section 2.1.1, with SHA-256 as the hash: a leaf is SHA-256(0x00 || d), an interior node is SHA-256(0x01 || left || right), and for n greater than one the list is split at k, the largest power of two smaller than n. The shape is therefore fixed by n alone, and two implementations that agree on D agree on the root.¶

The domain separation is not optional, because the prefixes are what make MTH the function [RFC9162] 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 the Facilitator holds no child's record D is empty and the root is MTH of the empty list, SHA-256 of the empty string. A child whose child-unresolved entry no child-final entry follows is one whose record 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.¶

13.1. 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 Section 14, Section 5.3 and Section 9.1 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.¶

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

{ "pact": "0.3", "type": "VerifiableTaskContract",
  "id": "vtc_9f2c11", ... }

HTTP/1.1 201 Created
Location: /pact/v2/contracts/vtc_9f2c11
Content-Type: application/vnd.pact.status+json

{ "pact": "0.3", "type": "ContractStatus",
  "vtc_id": "vtc_9f2c11", "state": "ACCEPTED",
  "trace": [ { "event": "accepted", ... } ], ... }

13.2. 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 [I-D.ietf-httpapi-idempotency-key-header] 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 [RFC6979] describes, so a client signing with ES256 or ES384 SHOULD sign deterministically or keep the bytes it sent and resend those.¶

13.3. Error Responses

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

========== NOTE: '\' line wrapping per RFC 8792 ===========

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

{
  "type":   "tag:laxsharma79@gmail.com,2026:pact:problem:signatur\
   es-unordered",
  "title":  "Signature set not sorted",
  "status": 422,
  "detail": "the second entry's kid sorts before the first's afte\
   r normalization.",
  "section": "14.1"
}

13.4. Exchange

 Buyer/Seller            Facilitator             Verifier
      |                       |                      |
      |-- POST {contract} --->|                      |
      |<-- 201 Status --------|                      |
      |                       |                      |
      |-- POST {delivery} --->|                      |
      |<-- 202 Status --------|                      |
      |                       |                      |
      |                       |-- GET work_uri ----->|
      |                       |<-- POST {verdict} ---|
      |                       |-- 201 Status ------->|
      |                       |                      |
      |-- GET {contract}/id ->|                      |
      |<-- 200 Status --------|                      |
      |                       |                      |
      |-- GET {outcome}/id -->|                      |
      |<-- 200 Outcome -------|                      |

14.1. 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 [RFC7515] 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 [RFC7515] 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 [RFC9864] with an Ed25519 key, or ES256 or ES384 [RFC7518] with a P-256 or P-384 key. A verifier MUST reject any other value, including the polymorphic EdDSA identifier of [RFC8037] that [RFC9864] 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 [RFC7515] recommends omitting the prefix; this document requires the full form so that typ equals the registered media type character for character. Explicit typing follows Section 3.11 of [RFC8725].¶
• A signatures array MUST be sorted by the normalized kid of its entries (Section 9.1), 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 [SP800-186], and a verifier MUST reject one that does not. [RFC7518] 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 [RFC8032] already rejects a non-canonical S, so the rule is stated for ECDSA only.¶

14.2. Rules Not Expressible in a Schema

• parties.buyer and parties.seller MUST be distinct after the normalization in Section 9.1 (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). A contract whose latest finality instant (Section 10.3) falls after the year 9999 MUST be refused at acceptance the same way, since a closes_at its trace could carry would then have no timestamp form (Section 2).¶
• 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 (Section 2). An amount in a posted contract or Challenge, price.amount or costs.amount, carrying more decimal places than the settlement binding named in price.settlement supports is refused (amount-invalid).¶

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

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 Section 9.1 allows, and the -01 reference validator made it. V-25 is the number half of the V-18 mistake: [RFC8785] 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 Section 15 changed when it was fixed.¶

A vector whose expected result reads "not evaluable" passes only with the problem type identifier-not-evaluable (Section 9.1). Most of those identifiers are also rejected by an implementation that rewrites them where Section 9.1 refuses them, but as verifier-not-independent, and that implementation fails the vector.¶

V-31 and V-32 are a pair. An implementation that compares an escaped unreserved character as written fails V-31, and so does one that decodes it once, as [RFC3986] Section 6.2.2.2 would. One that decodes more than once fails V-32. V-34 fails wherever whitespace is stripped before the fragment is removed, which is the order the -02 revision gave. V-41 fails wherever a "." is removed from the end of a path segment, which the -02 text did. V-42 fails wherever a "%" that begins no escape is compared as written, which the -02 reference implementation did, and V-43 wherever a path of "/" is kept before a query, which the -02 text did.¶

V-44 to V-47 and V-62 are checks any holder of an Outcome Record can make: V-45 to V-47 and V-62 against the record's own trace, V-44 against the Delivery as well. V-45 to V-47 are the three contracts that the -02 revision ended in the same FINAL. V-62 is a fourth FINAL, a delivery-first contract with no Verdict recorded, whose record carries none as a no-window record does and differs from it in flow.¶

17.1. 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 [RFC9943] and hand the receipt [RFC9942] 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 [RFC9162] Section 11.3 mentions and leaves undefined, and this document specifies none. A caller that relies on a performer's own word that a contract is complete, before the terminal entry is recorded, relies on something no record here carries, and the refusal of an early Outcome Record (Section 13) does nothing for it; what a party can ask for instead is the Facilitator's signed Status (Section 11).¶

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

17.2. Verifier Capture

A verification tier states how strongly work is checked. It does not state who checked it, and those fail separately. A re-execution transcript produced by the Seller and the same transcript produced by an independent Challenger are the same method and different evidence. Where a proof is generated and verified entirely inside one party, the tier is satisfied and the contract is unprotected. Section 9.1 requires that independence be derived by the evaluator from the party identifiers the contract names, and forbids satisfying it with a self-asserted field.¶

17.3. 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. Section 14.1 fixes the permitted set.¶

A kid carried as a sibling of the protected header rather than inside it is outside the signed bytes and is rewritable in transit. An attacker who can publish a key document can then re-attribute a victim's genuine signature to an identifier it controls, without breaking any cryptography. Section 14.1 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 Section 14.1 does. The order of a signature set is a second source of the same problem, and the sorting rule closes it.¶

17.4. 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. Section 5.1 requires a sibling hash over the dereferenced bytes for every URI inside committed content, and Section 7.2 requires a Verdict to commit to the instrument it actually ran, which closes the same attack from the verification side.¶

17.5. 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 [RFC1918], [RFC4193] 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.¶

17.6. Children: Attachment and Omission

Naming a parent contract cost one signature in the -00 revision and was checked against nothing. Section 10.2 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.¶

17.7. 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 (Section 7.3), so that the party with the most to recover is always admissible.¶

17.8. 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. Section 4.2 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.¶

17.9. Cross-Venue Replay

A VTC that does not name its Facilitator, network and asset is a signed instrument replayable against any of them; Section 5 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; Section 2 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 Section 14.1 stops a signature over one object type standing for another.¶

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

17.11. 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. Section 12 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.¶

17.12. 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, Section 3.9). 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.¶

17.13. Key Compromise and Rotation

A signature here is a long-lived commitment, and a compromised key signs contracts the party never agreed to. Rotation and revocation belong to the identity method behind the kid (Section 14.1.1), 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.¶

17.14. 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 (Section 7.3), 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.¶

18.1. Input Disclosure Before Contract Formation

Publishing a representative input sample so that a counterparty can price the work discloses production data to parties with whom no contract exists and who may be in unknown jurisdictions. Samples SHOULD be synthetic or de-identified. Where a real sample is necessary, it SHOULD be disclosed only after a confidentiality undertaking. Retention and deletion terms can be written into constraints, where spec_hash commits to them, but nothing in this document evaluates them and a PASS says nothing about them (Section 3.3); a verification profile that reads them says so (Section 9). This document cannot enforce any of that and does not pretend to.¶

18.2. 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 (Section 17.12), 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.¶

18.3. Challenger Access

An open challenge model requires that some party outside the contract can obtain the deliverable and the input in order to build a 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.¶

18.4. Retention

Retention periods stated for dispute purposes can conflict with erasure requests from a data subject. A retention period can be stated in constraints, with the limits Section 18.1 describes, 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.¶

19.1. Media Types

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

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

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

Security considerations:

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

Interoperability considerations:

Objects MUST be canonicalized per [RFC8785] before hashing or signing. Implementations that canonicalize by sorting object keys on Unicode code point rather than UTF-16 code unit 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¶

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 ([RFC6838], Section 3.1), and [RFC6838] Section 3.2 opens the vendor tree to anyone who interchanges files associated with a publicly available product.¶

19.2. Well-Known URI

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

URI suffix:

pact-facilitator¶

Change controller:

Laxmikant Sharma¶

Specification document(s):

This document, Section 8¶

Status:

provisional¶

Related information:

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

19.3. Problem Types

This document creates no registry for its problem types. [RFC9457] Section 4.2 establishes the "HTTP Problem Types" registry for types intended for reuse across applications; the types below are specific to this protocol and are identified by URIs in a namespace this document defines, which that specification permits without registration. Each is the identifier in the table appended to the prefix tag:laxsharma79@gmail.com,2026:pact:problem:, a tag URI [RFC4151] under the author's control. A tag URI is an identifier and does not dereference. [RFC9457] 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 sections named for each type are its documentation. Each row of the table carries the identifier, the HTTP status it accompanies, and every section a problem of that type names in its section member (Section 13.3); for internal-error, which reports no rule, that is the section defining it. A rule that another section restates, as Section 10.2 restates a rule of Section 10.3 and Section 14.2 the rules of Section 5.3, is listed under the section a refusal names, which is the one stating it. Where a row lists more than one section, the section member of a problem names the one stating the rule the request broke. A terms profile that refuses a request defines its own types under its own prefix and reports them as Section 13.3 says.¶

The table is generated from the list the reference implementation in the repository named in Section 16 prints, 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.¶

A.1. Identity and Bundle

Identifier: tag:laxsharma79@gmail.com,2026:pact:bonded-restitution. The bundle in the reference repository, under profiles/bonded-restitution/, contains README.md (the prose of this appendix, in Markdown), parameters.schema.json and vectors.json; profile_hash is the manifest digest over those three files and Section 15 prints it. Problem types this profile reports are under the prefix tag:laxsharma79@gmail.com,2026:pact:bonded-restitution:problem:.¶

A.2. Parameters

seller_bond:

amount, required. What the Seller posts before performance.¶

verification_fund:

amount, required. What the Seller posts to pay for checking; the -01 prose never said who posts it and its figure drew it from the Seller, which this profile follows.¶

cap:

amount, required. The most that leaves the bond under this contract; it bounds ranks 3 to 5 together, and what the bond holds beyond it returns to the Seller.¶

restitution_basis:

string, required. released or price.¶

remainder_to:

string, optional. buyer or sink; sink when absent.¶

verifier_fee:

amount, optional. Paid from the fund at each Verdict; 0.00 when absent.¶

principal_on:

string, required. The event at which the price moves to the Seller: verdict (a PASS Verdict), delivered, or window-closed.¶

assurance:

object, required. mode (certain, committed-sample or open), q_min (a number greater than zero and at most one) and, under committed-sample, sample_rate (a number greater than zero and at most one: the declared fraction of deliveries verified; the draw MUST derive from a seed the Buyer committed before the Delivery was submitted, combined with the Delivery's digest; how the seed is committed is outside the profile).¶

This profile defines no Challenge deposit; a Facilitator that advertises challenge_deposit does not do so under this profile.¶

The -01 revision's four release modes map onto flow and principal_on: on-verification is verdict-first with principal_on verdict; on-window is delivery-first with window-closed; optimistic is delivery-first with delivered; unsecured is no-window with delivered.¶

A.3. Accounts

Three internal accounts, opened empty: escrow, bond, fund. External accounts, unbounded as sources and sinks: buyer, seller, verifier, challenger:<kid> for each Challenger, and sink. Closure requires the three internal accounts to hold zero after the last entry.¶

A.4. Admission

At accepted the profile evaluates, exactly and in the contract's currency, with P the price, B seller_bond, q assurance.q_min, and E equal to P when principal_on is delivered and zero otherwise:¶

        B  >=  P * (1 - q) / q  +  E

and reports assurance-constraint-unsatisfied when it does not hold, or when assurance.mode is open alone. The inequality is the classical deterrence bound ([POLINSKY99]; [BELENKIY08] Theorem 1 for outsourced computation), with E the one term the -01 revision added: principal that moves before any Verdict is outside what the Verifier's check can withhold, so it raises what the Seller must post one for one. The bound deters nonconformance against that check and says nothing about what a later Challenge recovers; after a PASS is overturned the restitution of the schedule is bounded by the bond and the cap, whatever principal_on was. A contract whose seller_bond or verification_fund exceeds cap is reported as parameters-inconsistent.¶

The rule is falsified, and this profile with it, if the constraint proves unworkable at the prices and verification costs real deployments exhibit. That was the -01 revision's own failure condition, restated here where the rule now lives.¶

A.5. Schedule

For each event the schedule emits the entries below, in the order listed, omitting any entry whose amount is zero. Every event of Table 2 not named here emits nothing. Amounts are computed from the contract and the trace prefix; "released" is the sum of principal entries emitted so far. Every amount is computed exactly and emitted exactly: the schedule never rounds. Each is a sum, a difference or the lesser of amounts in the contract, the trace or the entries before it, so it has no more decimal places than they have, and it is written with the fewest decimal places that keep its value, never fewer than two. Section 14.2 refuses a price, or a Challenge's costs, with more decimal places than the binding supports; this profile does not hold its own amount parameters to that limit, so an entry has up to as many decimal places as the amounts that produced it, which can be more than the binding supports.¶

funded:

buyer to escrow, P, lock; seller to bond, B, bond; seller to fund, verification_fund, fund.¶

delivered:

if principal_on is delivered: escrow to seller, the escrow balance, principal.¶

verdict:

fund to verifier, the lesser of verifier_fee and the fund balance, verification; then if the outcome is PASS, no Challenge is answered, and principal_on is verdict: escrow to seller, the escrow balance, principal.¶

window-closed:

if principal_on is window-closed and the standing Verdict is not FAIL: escrow to seller, the escrow balance, principal.¶

terminal, FINAL:

escrow to seller, the escrow balance, principal; bond to seller, the bond balance, return; fund to seller, the fund balance, fund-return.¶

terminal, ABANDONED:

escrow to buyer, the escrow balance, reverse; bond to seller, the bond balance, return; fund to seller, the fund balance, fund-return. The -01 revision said the bond was slashed "to the extent of" the basis here, and its Section 5.3 defined the basis as an amount, the value already released or the full price, without relating either to a loss; with the price reversed the Buyer's loss is zero under either basis, so this profile slashes nothing here, which under basis price is a departure.¶

terminal, SETTLED:

in five ranks, each drawing only what remains. (1) escrow to buyer, the escrow balance, reverse. (2) if challenge_upheld: fund to the Challenger whose Challenge the standing Verdict answers, the lesser of that Challenge's costs when stated in the contract's currency (otherwise nothing) and the fund balance, costs. (3) bond to buyer, the lesser of the bond balance, the cap room and the Buyer's loss, restitution; the loss is "released" under basis released and P minus the rank-1 entry under basis price, which coincide under this schedule, since every principal entry moves the whole escrow balance; the parameter is kept for a profile that adds partial release. (4) if challenge_upheld: bond to that Challenger, the lesser of the bond balance and the cap room, bounty. (5) bond to buyer or sink per remainder_to, the lesser of the bond balance and the cap room, remainder. Then bond to seller, the bond balance, return, which is what the cap kept; then fund to seller, the fund balance, fund-return. The cap room at each rank is cap less what the entries so far have moved out of the bond.¶

Ranks 2 and 4 pay one Challenger, the one whose Challenge the standing Verdict answers. The -01 revision required the reward to be non-exclusive, paying every independent discoverer in full; one bond cannot fund that for two discoverers, so this profile pays one and records the departure here. A Challenge that was not answered by the standing Verdict, whether lapsed, rejected or superseded, receives nothing. Rank 4 gives the whole remaining bond, because the -01 revision forbade capping it at a fraction chosen for tidiness and fixed no figure; a profile owner who wants a different rule changes this line and the vectors with it.¶

A.6. Vectors

With P 180.00, B 18.00, fund 0.50, cap 180.00, basis released, remainder to sink, no verifier fee, principal_on verdict, assurance certain with q 1.0, under the verdict-first flow, and a Challenge claiming costs of 1.20. Amounts are in USDC. Trace indexes count from zero. The lists below are what vectors.json carries for the two paths in the figures of this document. The repository's file also carries the SETTLED-by-Verifier, ABANDONED, verdict-lapsed and delivery-first paths, the price basis, two FINAL paths with a verifier fee of 0.105 against funds of 0.51 and 0.50, and three admission vectors, one refused and one admitted at the boundary of the constraint. The third is refused: at P 0.01 and q 0.3333333333333333 its bond of 0.020000000000000003 is about 3 x 10^-34 below the bound of Appendix A.4.¶

 trace   0 accepted  1 funded  2 delivered  3 verdict PASS
         4 window-opened  5 window-closed  6 children-final
         7 terminal FINAL

 event  from     to        amount   code
   1    buyer    escrow    180.00   lock
   1    seller   bond       18.00   bond
   1    seller   fund        0.50   fund
   3    escrow   seller    180.00   principal
   7    bond     seller     18.00   return
   7    fund     seller      0.50   fund-return

 trace   0 accepted  1 funded  2 delivered  3 verdict PASS
         4 window-opened  5 challenge  6 verdict FAIL (answers 5,
         supersedes 3)  7 children-final  8 terminal SETTLED,
         challenge_upheld true

 event  from     to               amount   code
   1    buyer    escrow           180.00   lock
   1    seller   bond              18.00   bond
   1    seller   fund               0.50   fund
   3    escrow   seller           180.00   principal
   8    fund     challenger:<kid>   0.50   costs
   8    bond     buyer             18.00   restitution

In the second vector rank 1 emits nothing because the escrow is empty, rank 2 pays the lesser of 1.20 and the fund's 0.50, rank 3 pays the whole bond because the Buyer's loss (180.00 released) exceeds it, and ranks 4 and 5 and the fund return emit nothing because nothing remains. Both lists satisfy closure: after the last entry the three internal accounts hold zero.¶