PACT: Co-Signed Task Contracts, Delivery and Verdict Records, and Outcome Records for Autonomous Agents
draft-laxsharma-pact-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Laxmikant Sharma | ||
| Last updated | 2026-09-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Schemas, examples, conformance validator
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-laxsharma-pact-02
Network Working Group L. Sharma
Internet-Draft Independent
Intended status: Experimental 16 September 2026
Expires: 20 March 2027
PACT: Co-Signed Task Contracts, Delivery and Verdict Records, and
Outcome Records for Autonomous Agents
draft-laxsharma-pact-02
Abstract
Autonomous agents can already prove who they are, show whose
authority they act under, find and call one another, and pay. What
no existing specification lets them do is agree on a task in a form a
third party can check, deliver against it, have the delivery judged
by someone other than the performer, and carry away a record of the
outcome that a stranger can verify. This document specifies PACT, a
set of signed JSON records that closes that gap.
PACT defines four things: a co-signed task contract whose digest
covers its signature set; a Verdict record bound by digest to the
Delivery it judges; a Facilitator-signed event trace and Outcome
Record for every contract, recorded once, in one order, by a party
other than the performer; and a Merkle commitment from a parent's
Outcome Record to its subcontracts' Outcome Records.
Settlement terms are carried by reference to a profile defined
outside this document. This document specifies no escrow, custody or
release of value, and takes no position on the legal effect of any
record it defines.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 March 2027.
Sharma Expires 20 March 2027 [Page 1]
Internet-Draft PACT September 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. What This Document Specifies, and What It Does Not . . . 4
1.3. Relationship to Existing Work . . . . . . . . . . . . . . 5
1.4. The Experiment . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
3. Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Members Common to Every Record . . . . . . . . . . . . . 10
3.2. Contract Members . . . . . . . . . . . . . . . . . . . . 11
3.3. TaskSpec Members . . . . . . . . . . . . . . . . . . . . 12
3.4. Delivery Members . . . . . . . . . . . . . . . . . . . . 12
3.5. Verdict Members . . . . . . . . . . . . . . . . . . . . . 13
3.6. Challenge Members . . . . . . . . . . . . . . . . . . . . 13
3.7. Contract Status Members . . . . . . . . . . . . . . . . . 14
3.8. Outcome Record Members . . . . . . . . . . . . . . . . . 14
3.9. Capability Document Members . . . . . . . . . . . . . . . 15
3.10. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 17
4.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Events . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. The Verifiable Task Contract . . . . . . . . . . . . . . . . 21
5.1. Hash Commitments and Content Conveyance . . . . . . . . . 23
5.2. The Task Specification . . . . . . . . . . . . . . . . . 24
5.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. The Delivery Record . . . . . . . . . . . . . . . . . . . . . 25
7. Verdicts, Challenges and the Window . . . . . . . . . . . . . 26
7.1. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Verdicts . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Challenges . . . . . . . . . . . . . . . . . . . . . . . 29
7.4. Disputes and Lapses . . . . . . . . . . . . . . . . . . . 30
8. Facilitator Capability Discovery . . . . . . . . . . . . . . 31
Sharma Expires 20 March 2027 [Page 2]
Internet-Draft PACT September 2026
9. Verification Profiles . . . . . . . . . . . . . . . . . . . . 33
9.1. Verifier Independence and Identifier Normalization . . . 34
10. Contract Trees . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Binding a Child to Its Parent . . . . . . . . . . . . . 35
10.2. Registration and Children Final . . . . . . . . . . . . 36
10.3. Finality Is Bottom-Up . . . . . . . . . . . . . . . . . 37
11. The Contract Status . . . . . . . . . . . . . . . . . . . . . 38
12. Outcome Records . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. The Terms Result . . . . . . . . . . . . . . . . . . . . 43
12.2. The Children Merkle Root . . . . . . . . . . . . . . . . 44
13. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . 44
13.1. Proposing a Contract . . . . . . . . . . . . . . . . . . 46
13.2. Idempotency . . . . . . . . . . . . . . . . . . . . . . 46
13.3. Error Responses . . . . . . . . . . . . . . . . . . . . 47
13.4. Exchange . . . . . . . . . . . . . . . . . . . . . . . . 47
14. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Signatures . . . . . . . . . . . . . . . . . . . . . . . 48
14.1.1. Key Resolution . . . . . . . . . . . . . . . . . . . 49
14.2. Rules Not Expressible in a Schema . . . . . . . . . . . 50
14.3. Test Vectors . . . . . . . . . . . . . . . . . . . . . . 50
15. Worked Example . . . . . . . . . . . . . . . . . . . . . . . 52
16. Implementation Status . . . . . . . . . . . . . . . . . . . . 54
17. Security Considerations . . . . . . . . . . . . . . . . . . . 54
17.1. Trust in the Facilitator . . . . . . . . . . . . . . . . 56
17.2. Verifier Capture . . . . . . . . . . . . . . . . . . . . 56
17.3. Algorithm, Key and Encoding Confusion . . . . . . . . . 57
17.4. Substitution of Committed Content . . . . . . . . . . . 57
17.5. Fetching Committed Content . . . . . . . . . . . . . . . 57
17.6. Children: Attachment and Omission . . . . . . . . . . . 58
17.7. Buying Silence from a Challenger . . . . . . . . . . . . 58
17.8. Non-Delivery . . . . . . . . . . . . . . . . . . . . . . 58
17.9. Cross-Venue Replay . . . . . . . . . . . . . . . . . . . 58
17.10. Nondeterminism as Shield and as Weapon . . . . . . . . . 59
17.11. Fabricated History . . . . . . . . . . . . . . . . . . . 59
17.12. Retrieval . . . . . . . . . . . . . . . . . . . . . . . 59
17.13. Key Compromise and Rotation . . . . . . . . . . . . . . 59
17.14. Denial of Service by Challenge . . . . . . . . . . . . . 60
18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60
18.1. Input Disclosure Before Contract Formation . . . . . . . 60
18.2. The Contract Graph . . . . . . . . . . . . . . . . . . . 60
18.3. Challenger Access . . . . . . . . . . . . . . . . . . . 61
18.4. Retention . . . . . . . . . . . . . . . . . . . . . . . 61
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
19.1. Media Types . . . . . . . . . . . . . . . . . . . . . . 61
19.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 63
19.3. Problem Types . . . . . . . . . . . . . . . . . . . . . 64
20. Normative References . . . . . . . . . . . . . . . . . . . . 65
21. Informative References . . . . . . . . . . . . . . . . . . . 68
Sharma Expires 20 March 2027 [Page 3]
Internet-Draft PACT September 2026
Appendix A. An Example Terms Profile: bonded-restitution . . . . 72
A.1. Identity and Bundle . . . . . . . . . . . . . . . . . . . 72
A.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 72
A.3. Accounts . . . . . . . . . . . . . . . . . . . . . . . . 73
A.4. Admission . . . . . . . . . . . . . . . . . . . . . . . . 73
A.5. Schedule . . . . . . . . . . . . . . . . . . . . . . . . 74
A.6. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix B. Changes from -01 . . . . . . . . . . . . . . . . . . 76
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 79
1. Introduction
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).
Sharma Expires 20 March 2027 [Page 4]
Internet-Draft PACT September 2026
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 change from -01 to this revision is listed in
Appendix B.
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.
Sharma Expires 20 March 2027 [Page 5]
Internet-Draft PACT September 2026
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; this revision renames the record and 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
Sharma Expires 20 March 2027 [Page 6]
Internet-Draft PACT September 2026
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. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Canonical form. Every JSON object defined here is canonicalized with
JCS [RFC8785] before hashing or signing. Implementations MUST order
object keys by UTF-16 code unit as [RFC8785] Section 3.2.3 requires.
Sorting by Unicode code point is a common substitution; it agrees
Sharma Expires 20 March 2027 [Page 7]
Internet-Draft PACT September 2026
with the required order until a key outside the Basic Multilingual
Plane is compared with one whose first differing unit lies in U+E000
to U+FFFF, where the two orders disagree. Numbers MUST be serialized
as [RFC8785] Section 3.2.2.3 requires, which is how ECMAScript prints
them: the number one is 1, whatever type held it, and never 1.0.
Figures. A figure line that would exceed the page width is folded
with the single backslash strategy of [RFC8792], and a figure that
contains a fold begins with the header line that RFC requires. The
figure is read after unfolding; the digests it prints are whole once
the fold is removed.
Object digest. The digest of an object is the string sha256:
followed by the lowercase hexadecimal SHA-256 of the canonical form
of the whole object, including every signature member it carries.
Every hash member in this document that names another object
(vtc_hash, delivery_hash, challenge_hash, the object member of a
trace entry) is that object's digest, and an element of the list D in
Section 12.2 is the 32 bytes that digest's hexadecimal encodes. A
digest that excluded signatures would prove what was written and not
who agreed to it; the -00 revision had that defect and the -01
revision fixed it for the contract only. This revision applies one
construction everywhere.
Signing input. A signature over an object is computed over the
canonical form of the object with the signing member (signature or
signatures) removed, as Section 14.1 specifies. The digest of an
object and the signing input of an object are therefore different
byte strings, and the difference is the signature set.
Version. The pact member carries a version of the form major.minor;
this document defines 0.2. Every object defined here is hash-
committed and signed, so a member an implementation does not
recognise is inside the commitment and cannot be ignored safely. An
implementation MUST reject an object whose pact version it does not
implement, and MUST reject an object carrying a member this document
does not define for it, with two exceptions: the contents of
terms.parameters (Section 5.3), which the named profile defines and
this document does not read; and the members of a Delivery's
evidence, a Challenge's proof and a TaskSpec's constraints beyond
those Section 3 names, which the verification profile defines.
Extension is by a new version, not by adding members.
Sharma Expires 20 March 2027 [Page 8]
Internet-Draft PACT September 2026
Time. Every timestamp is an RFC 3339 date-time [RFC3339] in UTC with
the "Z" designator. The Facilitator's clock governs every deadline
and window in this document: the instant at which the Facilitator
records an event is the instant that counts, that instant is what the
trace carries, and parties SHOULD allow for skew when acting near a
boundary. Section 17.1 says what that clock can and cannot prove.
Amounts. An amount is a decimal string with no sign, no exponent and
a fractional part of two to eighteen digits; comparisons are exact
and no rounding is implied. A currency is an asset identifier whose
namespace is defined by the settlement binding named in
price.settlement, and need not be an ISO 4217 code. A network is a
ledger identifier in the form the same binding defines; the examples
use [CAIP-2] chain identifiers. This document carries amounts; it
does not say what any amount is for. Where a record produced under
this document lists amounts, as terms_result does (Section 12.1), the
meaning of every entry is the named profile's.
Identifiers. A party identifier is a URI. Two identifiers name the
same party when they are equal after the normalization in
Section 9.1, and every comparison of identifiers in this document is
made after that normalization.
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.
Sharma Expires 20 March 2027 [Page 9]
Internet-Draft PACT September 2026
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. Data Dictionary
This section lists every member this document defines, by the object
that carries it, with its type, whether it is required in that
object, and what it commits to. It is a dictionary and not a
rulebook: the rule that a record omitting a required member, or
carrying one this document does not define for it, does not conform
is stated once, in Section 14.2; the rules a Facilitator applies when
it accepts or refuses a record are in Section 14 and in the section
that defines the record. No sentence in this section requires
anything of any party. Where a member's meaning is the named terms
profile's, the entry says so and says nothing more.
Types are JSON types. A digest is a string of the form in Section 2.
An amount is a string of the form in Section 2. A URI is a string.
A timestamp is a string of the form in Section 2. Cardinality is
written as required or optional.
3.1. Members Common to Every Record
pact: string, required. The protocol version; 0.2 for objects
defined by this document.
type: string, required. The object's type name:
VerifiableTaskContract, Delivery, Verdict, Challenge,
ContractStatus, OutcomeRecord, or FacilitatorCapabilities.
signature: object, required in Delivery, Verdict, Challenge,
ContractStatus and the capability document. One JWS entry of the
form in 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.
Sharma Expires 20 March 2027 [Page 10]
Internet-Draft PACT September 2026
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.
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,
Sharma Expires 20 March 2027 [Page 11]
Internet-Draft PACT September 2026
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.
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.
Sharma Expires 20 March 2027 [Page 12]
Internet-Draft PACT September 2026
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;
Sharma Expires 20 March 2027 [Page 13]
Internet-Draft PACT September 2026
for the acceptance profile, profile, instrument_hash and
results_hash (required), results_uri and failing_checks (array of
strings; optional).
costs: object, optional. amount and currency: an amount the
Challenger states. This document records it in the trace and
reads it for nothing; its meaning is the named terms profile's.
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
where the event was caused by a posted record, and on dispute-
lapsed, where it names the Challenge that lapsed), and the event-
specific members listed in 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.
outcome: object, required. state (string, required; FINAL, SETTLED
or ABANDONED) and challenge_upheld (boolean, required).
work_hash: digest, required where a Delivery was recorded. Binds
the record to what was produced.
trace: array of objects, required. The complete event trace, ending
with the terminal event.
terms_result: object, required (Section 12.1). profile and
Sharma Expires 20 March 2027 [Page 14]
Internet-Draft PACT September 2026
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.
Sharma Expires 20 March 2027 [Page 15]
Internet-Draft PACT September 2026
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.
+=============+======================+================+============+
| Role | Identifier appears | Signs | Receives |
| | in | | |
+=============+======================+================+============+
| Buyer | parties.buyer | the contract | Contract |
| | | | Status, |
| | | | Outcome |
| | | | Record |
+-------------+----------------------+----------------+------------+
| Seller | parties.seller | the contract; | Contract |
| | | the Delivery; | Status, |
| | | as the Buyer | Outcome |
| | | of a child, | Record |
| | | that child's | |
| | | contract | |
| | | (Section 10.2) | |
+-------------+----------------------+----------------+------------+
| Facilitator | parties.facilitator, | Contract | every |
| | parent.facilitator, | Status, | posted |
| | the capability | Outcome | record |
| | document | Record, the | |
| | | capability | |
| | | document | |
+-------------+----------------------+----------------+------------+
| Verifier | parties.verifier, or | the Verdict | the |
| | the kid of a Verdict | | Delivery |
| | | | and, on a |
| | | | Challenge, |
| | | | the |
| | | | Challenge |
+-------------+----------------------+----------------+------------+
| Challenger | the kid of a | the Challenge | Contract |
| | Challenge | | Status |
+-------------+----------------------+----------------+------------+
Table 1: Roles, by what each signs and receives
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.
Sharma Expires 20 March 2027 [Page 16]
Internet-Draft PACT September 2026
4. Protocol Overview
A contract passes through four phases: Propose establishes the
record, Agree co-signs it and a Facilitator accepts it, Complete
produces a Delivery and a Verdict on it, and Record produces an
Outcome Record. Every step after Agree is an event the Facilitator
records on its own clock, in one order, and the sequence of those
events is the contract's trace. The trace is the protocol's central
object: the state machine is defined over it, every response a
Facilitator gives carries the prefix recorded so far, and the Outcome
Record carries the whole of it.
Buyer Facilitator Seller Verifier
| | | |
|<==== contract negotiated and co-signed ==>| |
| | | |
|-- POST contract ->| | |
|<-- Status --------| [ accepted ] | |
| | [ funded ] | |
| | | |
| | [ Seller performs ] |
| |<-- POST Delivery --| |
| |-- Status --------->| [ delivered ] |
| | | |
| |---- Delivery, criteria_hash ------->|
| |<--- POST Verdict -------------------|
| |---- Status ------------------------>|
| | [ verdict PASS ] [ window-opened ]
| | [ window-closed ] [ children-final ]
| | [ terminal FINAL ] |
| | | |
|<-- Outcome Record-|-- Outcome Record ->| |
Figure 1: Message flow under the verdict-first flow, without a
Challenge
Every accepted POST is answered with a Contract Status (Section 11),
a Facilitator-signed object carrying the state and the trace so far.
Nothing in the figure moves value, and no arrow in it is named for a
movement of value. What a terms profile does at each bracketed event
is the profile's, and it is reported once, in the Outcome Record, as
a list the profile produced and the Facilitator signed.
4.1. States
Sharma Expires 20 March 2027 [Page 17]
Internet-Draft PACT September 2026
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
Figure 2: Contract states
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
entry records a posted record (that record's digest, Section 2), and
the members listed for the event. A Facilitator MUST record the
entries of one contract in the order it recorded them and MUST NOT
reorder, remove or alter an entry once a Status carrying it has been
issued (Section 17.1 says what that rule does and does not prove).
Sharma Expires 20 March 2027 [Page 18]
Internet-Draft PACT September 2026
+==================+===============================================+
| Event | Recorded in; then. Members and condition |
+==================+===============================================+
| accepted | none; then ACCEPTED. object is vtc_hash. The |
| | contract passed Section 13.1. |
+------------------+-----------------------------------------------+
| funded | ACCEPTED; then FUNDED. ref (string, optional, |
| | in the form the settlement binding defines). |
| | Recorded when the settlement binding named in |
| | price.settlement reports that whatever the |
| | named terms profile requires before work |
| | starts is in place; how a Facilitator |
| | observes that is the binding's to say. Where |
| | the profile requires nothing, funded follows |
| | accepted in the same operation. |
+------------------+-----------------------------------------------+
| deadline-passed | ACCEPTED or FUNDED; then AWAITING_CHILDREN. |
| | task.deadline has passed with no delivered |
| | entry. |
+------------------+-----------------------------------------------+
| delivered | FUNDED; then DELIVERED, or under no-window |
| | AWAITING_CHILDREN directly. object is the |
| | Delivery's digest. The Delivery passed |
| | Section 6. |
+------------------+-----------------------------------------------+
| window-opened | DELIVERED; then WINDOW_OPEN. Recorded in the |
| | same operation as the entry it follows, with |
| | the same at: under delivery-first the |
| | delivered entry; under verdict-first a PASS |
| | verdict or verdict-lapsed. closes_at |
| | (timestamp, required) is at plus |
| | challenge.window_seconds. |
+------------------+-----------------------------------------------+
| verdict | DELIVERED (verdict-first, no Verdict |
| | standing), WINDOW_OPEN (delivery-first, no |
| | Verdict standing) or DISPUTED (answering a |
| | pending Challenge); then as the condition |
| | says. object is the Verdict's digest; signer |
| | (the kid of its signature); outcome (PASS or |
| | FAIL); answers (digest of the Challenge, |
| | present exactly when the Verdict carries |
| | challenge_hash); supersedes (digest of the |
| | Verdict that stood, present exactly when one |
| | did). Then: FAIL leads to AWAITING_CHILDREN; |
| | PASS in DELIVERED leads to window-opened; |
| | PASS in WINDOW_OPEN changes the state of |
| | nothing; PASS in DISPUTED leads to |
| | WINDOW_OPEN once no Challenge is pending. |
Sharma Expires 20 March 2027 [Page 19]
Internet-Draft PACT September 2026
+------------------+-----------------------------------------------+
| verdict-lapsed | DELIVERED; unchanged. Under verdict-first, |
| | verification.max_verdict_seconds have passed |
| | since delivered with no verdict. window- |
| | opened follows in the same operation. |
+------------------+-----------------------------------------------+
| challenge | WINDOW_OPEN or DISPUTED; then DISPUTED. |
| | object is the Challenge's digest; signer (the |
| | kid of its signature); costs copied from the |
| | Challenge when present. The Challenge passed |
| | Section 7.3 before closes_at. |
+------------------+-----------------------------------------------+
| dispute-lapsed | DISPUTED; then WINDOW_OPEN. object is the |
| | Challenge's digest. |
| | challenge.max_dispute_seconds have passed |
| | since that challenge entry with no Verdict |
| | answering it. Leads to WINDOW_OPEN once no |
| | Challenge is pending; the earlier Verdict, if |
| | any, stands. |
+------------------+-----------------------------------------------+
| window-closed | WINDOW_OPEN; then AWAITING_CHILDREN. |
| | closes_at has passed and no Challenge is |
| | pending. The window is never extended: a |
| | dispute that outlasts it delays this entry |
| | and does not move closes_at. |
+------------------+-----------------------------------------------+
| child-registered | any non-terminal; unchanged. object is the |
| | child contract's digest; facilitator (URI). |
| | Section 10.2. |
+------------------+-----------------------------------------------+
| child-final | any non-terminal; unchanged. object is the |
| | child's Outcome Record digest; child (the |
| | child contract's digest). |
+------------------+-----------------------------------------------+
| child-unresolved | any non-terminal; unchanged. child (the child |
| | contract's digest). The child's latest |
| | finality instant (Section 10.3) has passed |
| | and no Outcome Record for it is held. |
+------------------+-----------------------------------------------+
| children-final | AWAITING_CHILDREN; then terminal follows. |
| | Every registered child has a child-final or |
| | child-unresolved entry. A contract with no |
| | registered children records this entry on |
| | entering AWAITING_CHILDREN. |
+------------------+-----------------------------------------------+
| terminal | AWAITING_CHILDREN; then FINAL, SETTLED or |
| | ABANDONED. state (the terminal state) and |
| | challenge_upheld (boolean). ABANDONED where |
Sharma Expires 20 March 2027 [Page 20]
Internet-Draft PACT September 2026
| | deadline-passed was recorded; SETTLED where |
| | the standing Verdict is FAIL, with |
| | challenge_upheld true when that Verdict |
| | answers a Challenge; FINAL otherwise. |
+------------------+-----------------------------------------------+
Table 2: Events: the state each is recorded in, the state that
follows, and what the entry carries
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 acting on a posted record a
Facilitator MUST first record every clock-driven entry that is due,
so that the record is judged in the state the clock produced; entries
due at the same instant are recorded in the order of the table. The
at of an entry MUST be no earlier than that of the entry before it,
and a Status's issued_at MUST be no earlier than the at of its last
entry.
5. The Verifiable Task Contract
A VTC is a JSON object, media type application/
vnd.pact.contract+json, with the members in Section 3.2. A VTC is
valid only if every required member is present, the Buyer and the
Seller are distinct after normalization (Section 14.2), any named
Verifier satisfies Section 9.1, and both the Buyer and the Seller
have contributed exactly one signature that verifies against a key
bound to its identifier (Section 14.2). The Facilitator and any
Verifier do not sign the VTC; their assent is expressed by acting on
it, and a Facilitator that will not act on a contract refuses it at
Section 13.1.
Sharma Expires 20 March 2027 [Page 21]
Internet-Draft PACT September 2026
The settlement identifier, the network and the asset are all carried
inside price so that a co-signed VTC is bound to one venue. The -00
revision omitted them, which made a signed contract replayable
against any facilitator, chain or token contract.
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "VerifiableTaskContract",
"id": "vtc_9f2c11",
"parties": {
"buyer": "did:web:buyer.example:agents:procure-1",
"seller": "did:web:dataforge.example:agents:etl-3",
"facilitator": "did:web:settle.example",
"verifier": "did:web:audit.example"
},
"task": {
"spec_hash": "sha256:9491d28ac7a3fcd3f0bf279f78e793547cd4ef11\
1d27ff6bee37f05531823b72",
"spec_uri": "https://buyer.example/specs/taskspec.json",
"deadline": "2026-11-14T00:00:00Z"
},
"price": {
"amount": "180.00",
"currency": "USDC",
"settlement": "https://settle.example/bindings/ledger-1",
"network": "eip155:8453"
},
"verification": {
"tier": "T0-reexec",
"profile": "acceptance",
"criteria_hash": "sha256:0bdde1ab6b081d2b4bda580c5393756ae95c\
10b8351c9c55eb9316416265fc1b",
"max_verdict_seconds": 86400
},
"flow": "verdict-first",
"terms": {
"profile": "tag:laxsharma79@gmail.com,2026:pact:bonded-restit\
ution",
"profile_hash": "sha256:9fff6e3f3d99b26eb437a84b9de5b35124ccf\
6956e835df2653b99d71d363a68",
"parameters": {
"...": "the profile's; not read here"
}
},
"challenge": {
"window_seconds": 3600,
Sharma Expires 20 March 2027 [Page 22]
Internet-Draft PACT September 2026
"max_dispute_seconds": 86400
},
"signatures": [
{
"protected": "...",
"signature": "..."
},
{
"protected": "...",
"signature": "..."
}
]
}
Figure 3: A Verifiable Task Contract, signatures and parameters
abbreviated
The values are the reference repository's (Section 15), with the
signatures abbreviated. The parameters object is shown elided on
purpose: nothing in this document depends on what is in it.
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).
Sharma Expires 20 March 2027 [Page 23]
Internet-Draft PACT September 2026
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
Sharma Expires 20 March 2027 [Page 24]
Internet-Draft PACT September 2026
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.
6. The Delivery Record
The Delivery is the record a contract is judged against. It is a
JSON object, media type application/vnd.pact.delivery+json, with the
members in Section 3.4, signed once by the Seller.
A Facilitator MUST refuse a Delivery, with the problem type named,
when: its vtc_hash does not match the contract (object-conflict); the
contract is not in FUNDED (wrong-state); its signature does not
verify against a key bound to parties.seller (signature-invalid,
unexpected-signer); its evidence member is absent or does not conform
to the verification profile named in the contract (evidence-
nonconformant); or input_hash is absent where the tier re-executes
(evidence-nonconformant). A refused Delivery is recorded in no
trace; the contract stays in FUNDED and a conformant Delivery may
follow before the deadline. The -01 revision treated a nonconformant
Delivery as a FAIL Verdict, which decided a question about value
inside a rule about shape; the consequence of a Seller reaching the
deadline with nothing conformant recorded is now the deadline-passed
event, and what that event costs anyone is the profile's.
Sharma Expires 20 March 2027 [Page 25]
Internet-Draft PACT September 2026
Conformance of evidence is a check on shape, not on substance: the
Facilitator confirms that the members the profile requires are
present and well formed, and nothing about whether the work is any
good. That is why the check stays on the right side of the line
drawn in Section 2.1. Where task.deadline passes with no delivered
entry, the Facilitator records deadline-passed (Section 4.2). No
window opens, because there is nothing to challenge.
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "Delivery",
"vtc_id": "vtc_9f2c11",
"vtc_hash": "sha256:7af52ecee9592740ca9a8b3e0bbd097cf765ff49493\
04c2c855ca1d746ba6459",
"work_hash": "sha256:a26dc519a79ac70835a71ea58c9e34f0625778aee2\
80a3170b6b9a5037036ef0",
"work_uri": "https://cdn.dataforge.example/o/a26d",
"input_hash": "sha256:d7f43b3a51c28274adc4ebe535cc9de80f0b6d6c9\
75a1d1ce519d582306338b1",
"evidence": {
"profile": "acceptance",
"instrument_hash": "sha256:0bdde1ab6b081d2b4bda580c5393756ae9\
5c10b8351c9c55eb9316416265fc1b",
"results_hash": "sha256:28d334e0e0e0771eb5708452612ebcc6fbf84\
8ebaca540214b4f6d2165688a51",
"results_uri": "https://cdn.dataforge.example/o/28d3"
},
"signature": {
"protected": "...",
"signature": "..."
}
}
Figure 4: A Delivery for a T0-reexec contract, acceptance profile
The -01 revision said that a Buyer countersignature over the Delivery
constituted a receipt. The Delivery's signing member is a single
object, so no second signature could be carried, and the sentence is
withdrawn. A Buyer that wants a record of receipt has one: the
Status the Facilitator returns for the Delivery carries the delivered
entry and the Facilitator's signature over it.
7. Verdicts, Challenges and the Window
Sharma Expires 20 March 2027 [Page 26]
Internet-Draft PACT September 2026
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 B.
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.
Sharma Expires 20 March 2027 [Page 27]
Internet-Draft PACT September 2026
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "Verdict",
"vtc_id": "vtc_9f2c11",
"delivery_hash": "sha256:6bcbb831ea27a8754a0df9b44361be12411e45\
370cb3023331bc8bfbd924fcbe",
"outcome": "PASS",
"profile": "acceptance",
"instrument_hash": "sha256:0bdde1ab6b081d2b4bda580c5393756ae95c\
10b8351c9c55eb9316416265fc1b",
"results_hash": "sha256:28d334e0e0e0771eb5708452612ebcc6fbf848e\
baca540214b4f6d2165688a51",
"evaluated_at": "2026-11-10T09:14:22Z",
"signature": {
"protected": "...",
"signature": "..."
}
}
Figure 5: A Verdict
The Verifier is the party identified by the kid of the Verdict's
signature. Where the contract names parties.verifier, a Facilitator
MUST refuse a Verdict signed by any other party; otherwise it MUST
refuse a Verdict whose signer does not satisfy 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.
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
Sharma Expires 20 March 2027 [Page 28]
Internet-Draft PACT September 2026
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.
Sharma Expires 20 March 2027 [Page 29]
Internet-Draft PACT September 2026
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "Challenge",
"vtc_id": "vtc_9f2c11",
"delivery_hash": "sha256:6bcbb831ea27a8754a0df9b44361be12411e45\
370cb3023331bc8bfbd924fcbe",
"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": "..."
}
}
Figure 6: A Challenge under the acceptance profile
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.
Sharma Expires 20 March 2027 [Page 30]
Internet-Draft PACT September 2026
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 ---| |
Figure 7: The dispute path: a Challenge answered by a FAIL Verdict
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.
8. Facilitator Capability Discovery
Before a Buyer and Seller can co-sign a VTC they must agree on a
Facilitator and know what it implements. This document registers one
well-known URI for that purpose, per [RFC8615]. A client SHOULD
fetch the document again before it proposes, since nothing in it
survives the Facilitator withdrawing a profile.
This is deliberately narrower than agent discovery, which is the
subject of separate work and is not restated here. What is
discovered is one service's capabilities, not an agent's identity,
skills or endpoints.
A Facilitator SHOULD publish a JSON document, media type application/
vnd.pact.facilitator+json, with the members in Section 3.9, at the
path /.well-known/pact-facilitator of its origin: for an https:
identifier that origin, and for a did:web identifier https://
followed by the host the method encodes. The document MUST be served
over HTTPS. It MUST be signed, and the signature MUST verify against
a key bound to the identifier in facilitator. An unsigned capability
document is not usable for contract formation, because terms_profiles
determines which terms a party can name and expect to be evaluated.
Sharma Expires 20 March 2027 [Page 31]
Internet-Draft PACT September 2026
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "FacilitatorCapabilities",
"facilitator": "did:web:settle.example",
"issued_at": "2026-11-01T09:00:00Z",
"settlement_bindings": [
{
"id": "https://settle.example/bindings/ledger-1",
"networks": ["eip155:8453"],
"assets": ["USDC"]
}
],
"flows": ["verdict-first", "delivery-first"],
"verification_profiles": ["acceptance"],
"terms_profiles": [
{
"id": "tag:laxsharma79@gmail.com,2026:pact:bonded-restituti\
on",
"profile_hash": "sha256:9fff6e3f3d99b26eb437a84b9de5b35124c\
cf6956e835df2653b99d71d363a68"
}
],
"max_contract_value": {
"amount": "50000.00",
"currency": "USDC"
},
"endpoints": {
"contract": "https://settle.example/pact/v2/contracts",
"delivery": "https://settle.example/pact/v2/deliveries",
"verdict": "https://settle.example/pact/v2/verdicts",
"challenge": "https://settle.example/pact/v2/challenges",
"outcome": "https://settle.example/pact/v2/outcomes"
},
"signature": {
"protected": "...",
"signature": "..."
}
}
Figure 8: https://settle.example/.well-known/pact-facilitator
Sharma Expires 20 March 2027 [Page 32]
Internet-Draft PACT September 2026
A client MUST NOT infer any capability from the absence of a member.
A client may hold a Facilitator\'s capability document by prior
arrangement rather than fetch it from the well-known path; the path
is a convenience, the document is not, since a Facilitator refuses
what its document does not advertise (Section 5.3, Section 13.1). A
Facilitator lists only the terms profiles whose vectors
(Section 12.1) its own implementation reproduces.
9. Verification Profiles
A contract names both a tier, which says what class of evidence is
produced, and a profile, which says what is actually done to check
it. Four tier labels are used in this document: T0-reexec,
deterministic re-execution; T1-tee, hardware attestation per
[RFC9334]; T2-zkml, a proof of inference; and T3-jury, staked
arbitration. Tiers are a vocabulary. Three profiles are defined
below by name; any other is identified by a URI under its definer's
control, and this document creates no registry for them. The
distinction matters because the tier name does not determine how much
checking a contract gets and the profile largely does.
Consider one task, a bulk data transformation, under two profiles at
the same nominal tier. Re-executing the whole computation and
comparing outputs costs about what performing it cost; running a
committed acceptance instrument against the delivered artifact costs
a small fraction of that. Those are the author's estimates, not
measurements (the measurements Section 16 mentions are of the
protocol, not the work), and the two can differ by orders of
magnitude in what checking costs relative to the price. A terms
profile may make that ratio matter; this document requires of a
verification profile the five statements listed after the profiles
below, one of which is an order-of-magnitude estimate of its cost
relative to the work, since a figure nobody can estimate is a figure
nobody can use.
Implementations SHOULD select the cheapest profile that detects the
failures they actually care about, rather than the strongest-sounding
one. A committed acceptance instrument that is adequate is worth
more than a re-execution profile that nobody can afford to run.
acceptance: Run the instrument committed by criteria_hash against
the Delivery. The proof of nonconformance is a failing
evaluation. Deterministic by construction, since the instrument
is fixed before work begins. Cost: a small fraction of the work
for a data transformation, by estimate.
bisection: Interactive narrowing to a single disputed step, which is
Sharma Expires 20 March 2027 [Page 33]
Internet-Draft PACT September 2026
then checked directly. Cost grows logarithmically in the size of
the computation rather than linearly.
full-reexec: Re-execute and compare byte for byte. Sound only where
the computation is deterministic and the environment is pinned;
see Section 17.10. Cost: approximately the work.
A verification profile usable with this document states five things:
what artefact is evaluated and against what; what constitutes a valid
proof of nonconformance, including whether absence of evidence is
one; that its proof can be evaluated by a party other than the
Seller; its cost relative to the work, to order of magnitude; and
whether it is deterministic and with what tolerance (Section 17.10).
acceptance states these below; the other two are sketches that a full
profile document completes; a profile defined elsewhere states them
in its own document.
9.1. Verifier Independence and Identifier Normalization
Independence is a relation between the party that signs a Verdict and
the parties to the contract. It MUST be derived by the Facilitator
and MUST NOT be satisfied by a field in which a record declares
itself independent. Rules of this kind are stated for evaluation
after the fact in [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, and the
normalization MUST fold toward identifying the same party: strip
leading and trailing whitespace; lower-case the scheme and, for
did:web and https identifiers, the host; remove any fragment (a "#"
and everything after it) and any trailing "/" or ".". The path of a
did:web identifier is case sensitive and MUST NOT be folded.
Percent-encoding MUST NOT be decoded, since an open-ended decoder is
its own attack surface. An identifier that does not parse after
normalization is not evaluable and MUST NOT be treated as outside the
parties. An independence claim reaches exactly as far as the
record's own commitments.
Sharma Expires 20 March 2027 [Page 34]
Internet-Draft PACT September 2026
10. Contract Trees
An agent that accepts work may subcontract part of it. The
subcontract is an ordinary PACT contract whose Buyer is the parent's
Seller. What this section adds is the binding between the two, in
both directions and across Facilitators, so that a parent's Outcome
Record can commit to its children's and a reader of the parent's
record can find and check them.
A (Buyer)
|
vtc_9f2c11 at did:web:settle.example
|
B (Seller)
|
+-----------+-----------+
| |
vtc_c1a2 vtc_c2b7 at did:web:other.example
| |
C (Seller) D (Seller)
Figure 9: A contract tree. B is Seller above and Buyer below.
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.
Sharma Expires 20 March 2027 [Page 35]
Internet-Draft PACT September 2026
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); 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. Where the child's latest finality
instant passes with no record held, the Facilitator records child-
unresolved. children-final follows when every registered child has
one entry or the other, and the parent's terminal entry follows that.
A child that is never registered does not exist for the parent.
Nothing in this document compels a parent's Seller to register a
child, and Section 17.6 says what that means.
Sharma Expires 20 March 2027 [Page 36]
Internet-Draft PACT September 2026
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. 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)
Figure 10: Bottom-up finality
What a child's outcome means for its parent is not stated here. No
entry in a parent's schedule depends on any child's outcome unless
the named terms profile says so; what this document guarantees is
Sharma Expires 20 March 2027 [Page 37]
Internet-Draft PACT September 2026
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.
11. The Contract Status
A Contract Status is a JSON object, media type application/
vnd.pact.status+json, with the members in Section 3.7, signed once by
the Facilitator. It is the body of every successful response to a
POST in Section 13 and of a GET on a contract resource. It carries
the contract's state and the trace recorded so far.
Sharma Expires 20 March 2027 [Page 38]
Internet-Draft PACT September 2026
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "ContractStatus",
"vtc_id": "vtc_9f2c11",
"vtc_hash": "sha256:7af52ecee9592740ca9a8b3e0bbd097cf765ff49493\
04c2c855ca1d746ba6459",
"state": "WINDOW_OPEN",
"trace": [
{
"event": "accepted",
"at": "2026-11-01T10:00:00Z",
"object": "sha256:7af52ecee9592740ca9a8b3e0bbd097cf765ff494\
9304c2c855ca1d746ba6459"
},
{
"event": "funded",
"at": "2026-11-01T10:00:00Z"
},
{
"event": "delivered",
"at": "2026-11-10T08:30:12Z",
"object": "sha256:6bcbb831ea27a8754a0df9b44361be12411e45370\
cb3023331bc8bfbd924fcbe"
},
{
"event": "verdict",
"at": "2026-11-10T09:14:30Z",
"object": "sha256:1ac94d72dbdd1f51e523ecddb3a3b360703976215\
b13324485db355c948adfc0",
"signer": "did:web:audit.example#k1",
"outcome": "PASS"
},
{
"event": "window-opened",
"at": "2026-11-10T09:14:30Z",
"closes_at": "2026-11-10T10:14:30Z"
}
],
"issued_at": "2026-11-10T09:14:30Z",
"signature": {
"protected": "...",
"signature": "..."
}
}
Figure 11: A Contract Status after the Verdict of Figure 5
Sharma Expires 20 March 2027 [Page 39]
Internet-Draft PACT September 2026
Two rules make a Status worth keeping. A Facilitator MUST issue a
Status for every POST it accepts, carrying the entry that request
caused, so that the requester holds a signed receipt of what was
recorded and when. And the trace in every Status a Facilitator
issues for a contract MUST be a prefix of the trace in every later
one; two Statuses for one contract that violate that are evidence of
equivocation, and Section 17.1 says what a holder can do with it.
The Outcome Record's trace is the last such sequence.
The -01 revision returned the posted object with a state member added
to it, which no schema admitted and no signature covered. The Status
replaces that: the posted object is not echoed, and everything in the
response is inside the Facilitator's signature.
12. Outcome Records
An Outcome Record records what a contract did. It is a JSON object,
media type application/vnd.pact.outcome+json, with the members in
Section 3.8. It is the input to any reputation system built on PACT,
though this document defines no such system and takes no position on
how the records should be weighed.
A Facilitator MUST issue exactly one Outcome Record for every
contract that reaches a terminal state, including SETTLED and
ABANDONED, MUST sign it, and MUST NOT require the signature of any
other party on it. A Facilitator MUST serve the bytes of the record
it signed rather than sign it again on retrieval; under a randomized
signature scheme a second signing would produce a second record with
a different digest. The -00 revision's record needed the signature
of the party it recorded against, which made a reputation layer built
on it structurally incapable of recording a loss. The Facilitator
signature is what makes the record evidence: without it the record is
a claim by interested parties about themselves, and with it a
fabricated history requires a Facilitator's key rather than two
identities.
========== NOTE: '\' line wrapping per RFC 8792 ===========
{
"pact": "0.2",
"type": "OutcomeRecord",
"vtc_id": "vtc_9f2c11",
"vtc_hash": "sha256:7af52ecee9592740ca9a8b3e0bbd097cf765ff49493\
04c2c855ca1d746ba6459",
"parties": {
"buyer": "did:web:buyer.example:agents:procure-1",
"seller": "did:web:dataforge.example:agents:etl-3",
"facilitator": "did:web:settle.example",
Sharma Expires 20 March 2027 [Page 40]
Internet-Draft PACT September 2026
"verifier": "did:web:audit.example"
},
"outcome": {
"state": "SETTLED",
"challenge_upheld": true
},
"work_hash": "sha256:a26dc519a79ac70835a71ea58c9e34f0625778aee2\
80a3170b6b9a5037036ef0",
"trace": [
{
"event": "accepted",
"at": "2026-11-01T10:00:00Z",
"object": "sha256:7af52ecee9592740ca9a8b3e0bbd097cf765ff494\
9304c2c855ca1d746ba6459"
},
{
"event": "funded",
"at": "2026-11-01T10:00:00Z"
},
{
"event": "delivered",
"at": "2026-11-10T08:30:12Z",
"object": "sha256:6bcbb831ea27a8754a0df9b44361be12411e45370\
cb3023331bc8bfbd924fcbe"
},
{
"event": "verdict",
"at": "2026-11-10T09:14:30Z",
"object": "sha256:1ac94d72dbdd1f51e523ecddb3a3b360703976215\
b13324485db355c948adfc0",
"signer": "did:web:audit.example#k1",
"outcome": "PASS"
},
{
"event": "window-opened",
"at": "2026-11-10T09:14:30Z",
"closes_at": "2026-11-10T10:14:30Z"
},
{
"event": "challenge",
"at": "2026-11-10T09:40:00Z",
"object": "sha256:2ac4e296e79f681446a43e55aef572ff0bfd2093e\
c2c6795962e67a6e2ff55ff",
"signer": "did:web:watch.example#k1",
"costs": {
"amount": "1.20",
"currency": "USDC"
}
Sharma Expires 20 March 2027 [Page 41]
Internet-Draft PACT September 2026
},
{
"event": "verdict",
"at": "2026-11-10T09:58:05Z",
"object": "sha256:10d537e7b8face8bd7695541d36d32568394a5319\
7653280c404e2d84a63d46d",
"signer": "did:web:audit.example#k1",
"outcome": "FAIL",
"answers": "sha256:2ac4e296e79f681446a43e55aef572ff0bfd2093\
ec2c6795962e67a6e2ff55ff",
"supersedes": "sha256:1ac94d72dbdd1f51e523ecddb3a3b36070397\
6215b13324485db355c948adfc0"
},
{
"event": "children-final",
"at": "2026-11-10T09:58:05Z"
},
{
"event": "terminal",
"at": "2026-11-10T09:58:05Z",
"state": "SETTLED",
"challenge_upheld": true
}
],
"terms_result": {
"profile": "tag:laxsharma79@gmail.com,2026:pact:bonded-restit\
ution",
"profile_hash": "sha256:9fff6e3f3d99b26eb437a84b9de5b35124ccf\
6956e835df2653b99d71d363a68",
"currency": "USDC",
"transfers": [
{
"event": 8,
"from": "...",
"to": "...",
"amount": "...",
"code": "..."
}
]
},
"signatures": [
{
"protected": "...",
"signature": "..."
}
]
}
Sharma Expires 20 March 2027 [Page 42]
Internet-Draft PACT September 2026
Figure 12: An Outcome Record for a contract that reached SETTLED
on an upheld Challenge
The record carries one signature, the Facilitator's. The Seller did
not consent to this record and its consent is not required. The
transfers entries are elided here because their content is the
profile's; Appendix A shows them filled in for its own profile.
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, 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. 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.
Sharma Expires 20 March 2027 [Page 43]
Internet-Draft PACT September 2026
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 every registered child is unresolved D is empty and
the root is MTH of the empty list, SHA-256 of the empty string; the
child-unresolved entries in the trace say which records the root does
not cover. The -01 revision did not say whether a leaf covered the
record's signatures; this revision says it does, so a record cannot
be re-signed without changing the root.
13. Protocol Endpoints
This section specifies the operations a Facilitator exposes. This
document fixes no base URI; each is discovered from the endpoints
member of the capability document (Section 8), so a Facilitator may
mount them anywhere on its origin.
Propose a contract: POST {contract}; body, a contract; 201 with a
Status.
Retrieve a contract's status: GET {contract}/{id}; 200 with a
Status.
Register a child: POST {contract}/{id}/children; body, the child's
contract; 201 with a Status.
Supply a child's outcome: POST
Sharma Expires 20 March 2027 [Page 44]
Internet-Draft PACT September 2026
{contract}/{id}/children/{child_hash}, where child_hash is the
digest by which the registration identifies the child; body, the
child's Outcome Record; 200 with a Status. This resource is keyed
by digest, so the id rule of Section 13.2 does not apply to it.
Submit a Delivery: POST {delivery}; body, a Delivery; 202 with a
Status.
Record a Verdict: POST {verdict}; body, a Verdict; 201 with a
Status.
Open a Challenge: POST {challenge}; body, a Challenge; 202 with a
Status.
Retrieve an Outcome Record: GET {outcome}/{id}; 200 with the Outcome
Record.
A request naming a contract the Facilitator does not hold is refused
as unknown-contract (404). A body larger than the Facilitator
accepts is refused as payload-too-large (413). A failure inside the
Facilitator is reported as internal-error (500), the one problem type
that names no rule. A GET of an Outcome Record before the terminal
entry is refused as wrong-state.
All requests and responses use the media types defined in Section 19.
All requests MUST be made over HTTPS, following the recommendations
of [RFC9325]. Status codes are as defined in [RFC9110]. A Delivery
and a Challenge are answered 202 (Accepted) because, in the sense of
[RFC9110] Section 15.3.3, their processing is not complete when the
response is sent: what either record leads to may depend on a Verdict
the Facilitator does not itself produce. A contract and a Verdict
are answered 201 (Created); the contract is the resource the Location
header names, and a Verdict, to which this document gives no resource
of its own, is identified by the digest the Status in the response
carries.
A Facilitator authenticates the sender of a POST by the signature on
the body, and by nothing else in this document: it MUST reject a
Delivery not signed by the contract's Seller, a Verdict not signed by
a party admissible under Section 7.2, a Challenge whose signer it
cannot resolve, and a child registration or child outcome whose body
does not verify as Section 10.2 requires. A Facilitator MAY require
an HTTP-layer authentication in addition. Retrieval is discussed in
Section 17.12.
Sharma Expires 20 March 2027 [Page 45]
Internet-Draft PACT September 2026
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.2", "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.2", "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.
Sharma Expires 20 March 2027 [Page 46]
Internet-Draft PACT September 2026
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 -------| |
Sharma Expires 20 March 2027 [Page 47]
Internet-Draft PACT September 2026
Figure 13: HTTP exchange for the flow in Figure 1
14. Conformance
Every rule a PACT conformance checker enforces is stated in this
document as normative text. This section collects the rules that a
schema language cannot express, so that an implementation built from
this document alone passes a conformance suite built from it. A rule
that lives only in a test suite is not a requirement, and an
implementer who cannot find it in the specification will not
implement it.
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.
Sharma Expires 20 March 2027 [Page 48]
Internet-Draft PACT September 2026
* 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.1.1. Key Resolution
A kid is a URI naming a public key. A verifier MUST resolve it as
follows, and MUST reject a signature whose kid it cannot resolve.
* A did: identifier is a DID URL [DID-CORE]. The verifier resolves
the DID document by the method the identifier names and selects
the verification method its fragment identifies. Examples in this
document use did:web [DID-WEB]; no method is required or excluded.
* An https: identifier dereferences, over TLS, to a JWK Set
[RFC7517]; the verifier selects the key whose kid member equals
the fragment.
The part of a kid before its fragment MUST equal, after the
normalization in Section 9.1, the party identifier the signature is
attributed to. Verifying a signature establishes that the holder of
that key signed; that the key belongs to the party is a property of
Sharma Expires 20 March 2027 [Page 49]
Internet-Draft PACT September 2026
the identity method, and this document does not add to it. An
identity system for agents defined elsewhere, such as
[I-D.ietf-wimse-aims], is used by naming its identifiers here in one
of these two forms; a further form needs a resolution rule added to
this list, which is the one change it would take.
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).
* 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 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.
Sharma Expires 20 March 2027 [Page 50]
Internet-Draft PACT September 2026
+======+==========================================+==========+
| ID | Mutation from a valid object | Expect |
+======+==========================================+==========+
| V-01 | unmodified valid VTC | accept |
+------+------------------------------------------+----------+
| V-02 | alg set to none | reject |
+------+------------------------------------------+----------+
| V-03 | alg set to HS256 | reject |
+------+------------------------------------------+----------+
| V-04 | kid moved outside the protected header | reject |
+------+------------------------------------------+----------+
| V-05 | typ of a Delivery on a VTC signature | reject |
+------+------------------------------------------+----------+
| V-06 | buyer and seller set to the same | reject |
| | identifier | |
+------+------------------------------------------+----------+
| V-07 | buyer and seller differing only by | reject |
| | trailing "/" | |
+------+------------------------------------------+----------+
| V-08 | two signatures, both from the buyer | reject |
+------+------------------------------------------+----------+
| V-09 | window_seconds of 0 | reject |
+------+------------------------------------------+----------+
| V-10 | acceptance as an empty object | reject |
+------+------------------------------------------+----------+
| V-11 | harness_uri with harness_hash removed | reject |
+------+------------------------------------------+----------+
| V-12 | terms.profile_hash not advertised by the | reject |
| | Facilitator | |
+------+------------------------------------------+----------+
| V-13 | terms.parameters failing the profile's | reject |
| | schema | |
+------+------------------------------------------+----------+
| V-14 | Delivery with evidence absent | reject, |
| | | no entry |
+------+------------------------------------------+----------+
| V-15 | child whose buyer is not the parent's | reject |
| | seller | |
+------+------------------------------------------+----------+
| V-16 | child with L(child) not earlier than | reject |
| | L(parent) | |
+------+------------------------------------------+----------+
| V-17 | Verdict signed by the seller | reject |
+------+------------------------------------------+----------+
| V-18 | object keys ordered by code point rather | digest |
| | than UTF-16 unit, a supplementary-plane | mismatch |
| | key beside one in U+E000 to U+FFFF | |
+------+------------------------------------------+----------+
Sharma Expires 20 March 2027 [Page 51]
Internet-Draft PACT September 2026
| V-19 | buyer and seller differing only in the | accept |
| | case of a did:web path | |
+------+------------------------------------------+----------+
| V-20 | object carrying a member this document | reject |
| | does not define for it | |
+------+------------------------------------------+----------+
| V-21 | signatures not sorted by normalized kid | reject |
+------+------------------------------------------+----------+
| V-22 | ECDSA signature with s above n/2 | reject |
+------+------------------------------------------+----------+
| V-23 | Verdict with delivery_hash computed over | reject |
| | the Delivery without its signature | |
+------+------------------------------------------+----------+
| V-24 | Outcome Record whose transfers overdraw | reject |
| | an account of the profile | |
+------+------------------------------------------+----------+
| V-25 | a number serialized by the host | digest |
| | language's default formatter, such as | mismatch |
| | 1.0 for the float one | |
+------+------------------------------------------+----------+
| V-26 | a protected header carrying a member | reject |
| | Section 14.1 forbids: jwk, jku, x5c, | |
| | x5u, x5t, x5t#S256 or crit | |
+------+------------------------------------------+----------+
Table 3: Conformance vectors
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.
15. Worked Example
The digests below are the reference repository's, at the tag named in
Section 16. The object figures in earlier sections are the
repository's objects with their signatures abbreviated and the
contract's parameters elided; the digests here are computed over the
full objects. The figures that the -01 revision printed here about a
bond and a required detection rate are now the profile's; Appendix A
carries the rule and the parameters.
Sharma Expires 20 March 2027 [Page 52]
Internet-Draft PACT September 2026
A buyer commissions a data transformation at a price of 180.00 USDC
under the verdict-first flow, the acceptance verification profile,
and the terms profile of Appendix A with the parameters shown there.
The digests carried by the reference TaskSpec, contract and profile
are:
========== NOTE: '\' line wrapping per RFC 8792 ===========
spec_hash sha256:9491d28ac7a3fcd3f0bf279f78e793547cd4ef111\
d27ff6bee37f05531823b72
criteria_hash sha256:0bdde1ab6b081d2b4bda580c5393756ae95c10b83\
51c9c55eb9316416265fc1b
profile_hash sha256:9fff6e3f3d99b26eb437a84b9de5b35124ccf6956\
e835df2653b99d71d363a68
vtc_hash sha256:7af52ecee9592740ca9a8b3e0bbd097cf765ff494\
9304c2c855ca1d746ba6459
delivery_hash sha256:6bcbb831ea27a8754a0df9b44361be12411e45370\
cb3023331bc8bfbd924fcbe
criteria_hash is the manifest digest of Section 5.1 over the
acceptance instrument bundle, and the same value appears as
acceptance.harness_hash inside the TaskSpec, so the instrument is
committed both by the contract and from within the specification it
belongs to. profile_hash is the same construction over the profile
bundle. vtc_hash is the digest of the signed contract, and
delivery_hash of the signed Delivery, both per Section 2.
The -01 revision printed three of the values above, spec_hash,
criteria_hash and vtc_hash, and each differs from what it printed,
for reasons recorded so that a reader comparing the two documents can
account for the difference. spec_hash and vtc_hash differ because the
-01 canonicalizer serialized numbers as the host language printed
them (Section 14.3, V-25); spec_hash also because the TaskSpec now
carries the sibling hashes Section 5.1 always required, and vtc_hash
also because the contract's members changed (Appendix B).
criteria_hash carries no number; it differs because the two files of
the instrument bundle were edited to drop their mention of the
withdrawn call-for-bids example. profile_hash is new, and
delivery_hash, which the -01 figures showed only as a placeholder,
now covers the Delivery's signature.
The traces the reference implementation records for this contract on
the path of Figure 1 and on the dispute path of Figure 7 carry the
event sequences of the first two vectors in the profile's bundle, and
the transfer lists the profile produces for them are those vectors'
lists; the vectors name their objects by placeholder digests, so the
match is of sequence and lists, not of bytes. Appendix A prints both
lists.
Sharma Expires 20 March 2027 [Page 53]
Internet-Draft PACT September 2026
16. Implementation Status
This section records the status of known implementations of this
document per [RFC7942]. The section and the reference to [RFC7942]
are to be removed before publication as an RFC, and the listing of an
implementation here implies no endorsement by the IETF.
One implementation is known to the author, and the author wrote it:
https://github.com/pact-spec/spec, under the Apache License 2.0. At
tag v0.2.0 it comprises the object schemas, the examples whose
digests Section 15 prints, a conformance validator that runs 107
checks including every vector of Section 14.3, a Facilitator serving
the endpoints of Section 13 with the profile of Appendix A, and
clients for the other roles. Its previous tag, v0.1.0, implemented
the -01 revision and is the source of the measurements the author has
published about it. No second implementation exists, so nothing in
Section 1.4 has been tested, and this document claims no
interoperability. It is an individual submission and the product of
no working group; the implementation is a prototype, the information
is current as of the tag named above, and the contact is the author.
17. Security Considerations
Most of what follows was found by adversarial review of earlier
revisions rather than anticipated when they were written. Each
subsection states the attack, why it worked, and the requirement in
this document that closes it. Where a threat is only mitigated
rather than closed, that is said. The table first: for each party,
what the protocol enforces against it, what it records about it, and
who can check the record without trusting the Facilitator.
Sharma Expires 20 March 2027 [Page 54]
Internet-Draft PACT September 2026
+=============+======================+==============+===============+
| Party | Enforced against it | Recorded | Checkable by |
| | | about it | |
+=============+======================+==============+===============+
| Buyer | cannot alter the | its | anyone |
| | task, instrument or | signature | holding the |
| | terms after signing; | on the | contract |
| | cannot attach a | contract; | |
| | child to a contract | any | |
| | it is not party to | Challenge | |
| | | it signs | |
+-------------+----------------------+--------------+---------------+
| Seller | cannot deliver | its | anyone |
| | against a | signature | holding the |
| | substituted | on the | contract and |
| | instrument or input; | contract | the Delivery |
| | is refused as | and the | |
| | Verifier when it | Delivery; | |
| | signs under a party | the | |
| | identifier; cannot | Verdicts | |
| | re-sign a record | and | |
| | without changing | Challenges | |
| | every digest over it | on its | |
| | | Delivery | |
+-------------+----------------------+--------------+---------------+
| Verifier | cannot be a party to | its | anyone |
| | the contract; must | Verdicts, | holding the |
| | commit to the | superseded | Delivery and |
| | instrument it ran | ones | the |
| | and its results | included | instrument |
+-------------+----------------------+--------------+---------------+
| Facilitator | nothing | what it | any holder of |
| | | chose to | two of its |
| | | sign, in | Statuses, for |
| | | the order | equivocation; |
| | | it chose, | nobody, for |
| | | on a clock | omission or |
| | | that is | for time, |
| | | its own | without a |
| | | | witness |
| | | | outside this |
| | | | document |
+-------------+----------------------+--------------+---------------+
Table 4: What the protocol enforces, records and lets others
check, by party
Sharma Expires 20 March 2027 [Page 55]
Internet-Draft PACT September 2026
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.
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
parties named in the contract, and forbids satisfying it with a self-
asserted field.
Sharma Expires 20 March 2027 [Page 56]
Internet-Draft PACT September 2026
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.
Sharma Expires 20 March 2027 [Page 57]
Internet-Draft PACT September 2026
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
Sharma Expires 20 March 2027 [Page 58]
Internet-Draft PACT September 2026
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
Sharma Expires 20 March 2027 [Page 59]
Internet-Draft PACT September 2026
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. Privacy Considerations
PACT moves contracts and evidence about work, and both leak.
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, and the constraints member SHOULD carry the retention
and deletion terms. 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.
Sharma Expires 20 March 2027 [Page 60]
Internet-Draft PACT September 2026
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. Contracts SHOULD state a
retention period, and implementers should be aware that a hash
commitment survives deletion of the content it commits to, which is
usually the property they want and occasionally the one they must
explain.
19. IANA Considerations
This document asks IANA to register seven media types in the vendor
tree and one well-known URI. It creates no registry. It defines
problem types but does not ask for a registry of them (Section 19.3).
The -01 revision asked for two registries, one of verification
profiles and one of settlement bindings, and listed under the second
an identifier in another project's namespace that nobody had defined;
both requests are withdrawn. A profile of either kind is identified
by a URI under its definer's control and needs no registration.
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
Sharma Expires 20 March 2027 [Page 61]
Internet-Draft PACT September 2026
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
Sharma Expires 20 March 2027 [Page 62]
Internet-Draft PACT September 2026
+===========================+==========================+============+
| Subtype name | Object | Defined in |
+===========================+==========================+============+
| vnd.pact.contract+json | Verifiable | Section 5 |
| | Task Contract | |
+---------------------------+--------------------------+------------+
| vnd.pact.delivery+json | Delivery | Section 6 |
+---------------------------+--------------------------+------------+
| vnd.pact.verdict+json | Verdict | Section |
| | | 7.2 |
+---------------------------+--------------------------+------------+
| vnd.pact.challenge+json | Challenge | Section |
| | | 7.3 |
+---------------------------+--------------------------+------------+
| vnd.pact.status+json | Contract | Section 11 |
| | Status | |
+---------------------------+--------------------------+------------+
| vnd.pact.outcome+json | Outcome | Section 12 |
| | Record | |
+---------------------------+--------------------------+------------+
| vnd.pact.facilitator+json | Capability | Section 8 |
| | document | |
+---------------------------+--------------------------+------------+
Table 5: Media types registered by this document
The -01 revision asked for these in the standards tree under the
names pact-contract+json and so on. Registration in that tree from
outside the IETF stream needs approval this document does not have
([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.
Sharma Expires 20 March 2027 [Page 63]
Internet-Draft PACT September 2026
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 section named for each type is its documentation. The list of
types, each with its status and the section that defines it, is
printed by the reference implementation in the repository named in
Section 16, and the section named for each type says what it means.
Each entry carries the identifier, the HTTP status it accompanies,
and the section stating the rule it reports. A terms profile that
refuses a request defines its own types under its own prefix and
reports them as Section 13.3 says.
+=============================+========+===============+
| Identifier | Status | Defined in |
+=============================+========+===============+
| algorithm-not-permitted | 400 | Section 14.1 |
+-----------------------------+--------+---------------+
| amount-invalid | 422 | Section 14.2 |
+-----------------------------+--------+---------------+
| challenge-window-closed | 409 | Section 7.3 |
+-----------------------------+--------+---------------+
| child-outcome-invalid | 422 | Section 10.2 |
+-----------------------------+--------+---------------+
| deadline-invalid | 422 | Section 14.2 |
+-----------------------------+--------+---------------+
| evidence-nonconformant | 422 | Section 6 |
+-----------------------------+--------+---------------+
| facilitator-mismatch | 422 | Section 13.1 |
+-----------------------------+--------+---------------+
| finality-ordering-violation | 422 | Section 10.3 |
+-----------------------------+--------+---------------+
| flow-unsupported | 422 | Section 7.1 |
+-----------------------------+--------+---------------+
| internal-error | 500 | Section 13 |
+-----------------------------+--------+---------------+
| no-recorded-delivery | 409 | Section 7.2 |
+-----------------------------+--------+---------------+
Sharma Expires 20 March 2027 [Page 64]
Internet-Draft PACT September 2026
| object-conflict | 409 | Section 13.2 |
+-----------------------------+--------+---------------+
| parent-unresolvable | 422 | Section 10.2 |
+-----------------------------+--------+---------------+
| parties-not-distinct | 422 | Section 14.2 |
+-----------------------------+--------+---------------+
| payload-too-large | 413 | Section 13 |
+-----------------------------+--------+---------------+
| proof-nonconformant | 422 | Section 7.3 |
+-----------------------------+--------+---------------+
| retrieval-restricted | 403 | Section 17.12 |
+-----------------------------+--------+---------------+
| schema-invalid | 422 | Section 14.2 |
+-----------------------------+--------+---------------+
| settlement-unsupported | 422 | Section 13.1 |
+-----------------------------+--------+---------------+
| signature-invalid | 400 | Section 14.1 |
+-----------------------------+--------+---------------+
| signature-missing | 400 | Section 14.2 |
+-----------------------------+--------+---------------+
| signatures-unordered | 422 | Section 14.1 |
+-----------------------------+--------+---------------+
| terms-parameters-invalid | 422 | Section 5.3 |
+-----------------------------+--------+---------------+
| terms-unsupported | 422 | Section 5.3 |
+-----------------------------+--------+---------------+
| unexpected-signer | 422 | Section 14.2 |
+-----------------------------+--------+---------------+
| unknown-contract | 404 | Section 13 |
+-----------------------------+--------+---------------+
| verdict-nonconformant | 422 | Section 7.2 |
+-----------------------------+--------+---------------+
| verifier-not-independent | 422 | Section 9.1 |
+-----------------------------+--------+---------------+
| wrong-state | 409 | Section 4.2 |
+-----------------------------+--------+---------------+
Table 6: Problem types defined by this document
The table is generated from the reference implementation's own list,
so that every type an implementation of this document emits has a
line here. The -01 revision listed eight of the twenty-nine its
implementation used.
20. Normative References
Sharma Expires 20 March 2027 [Page 65]
Internet-Draft PACT September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/info/rfc9457>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
and Signatures in JSON Object Signing and Encryption
(JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
<https://www.rfc-editor.org/info/rfc8037>.
[RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
JSON Object Signing and Encryption (JOSE) and CBOR Object
Signing and Encryption (COSE)", RFC 9864,
DOI 10.17487/RFC9864, October 2025,
<https://www.rfc-editor.org/info/rfc9864>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
Sharma Expires 20 March 2027 [Page 66]
Internet-Draft PACT September 2026
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/info/rfc4151>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
Sharma Expires 20 March 2027 [Page 67]
Internet-Draft PACT September 2026
[DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", W3C
Recommendation, 19 July 2022,
<https://www.w3.org/TR/2022/REC-did-core-20220719/>.
[DID-WEB] W3C Credentials Community Group, "did:web Method
Specification", Unofficial draft, undated; accessed 16
September 2026,
<https://w3c-ccg.github.io/did-method-web/>.
[I-D.bhutton-json-schema]
Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
Schema: A Media Type for Describing JSON Documents", Work
in Progress, Internet-Draft, draft-bhutton-json-schema-01,
10 June 2022, <https://datatracker.ietf.org/doc/html/
draft-bhutton-json-schema-01>.
21. Informative References
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026,
<https://www.rfc-editor.org/info/rfc9942>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
Sharma Expires 20 March 2027 [Page 68]
Internet-Draft PACT September 2026
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[CAIP-2] Chain Agnostic Standards Alliance, "CAIP-2: Blockchain ID
Specification", Status: Final, 5 December 2019,
<https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/
caip-2.md>.
[X402COMPLIANCE]
wowlegend (Tersign), pull request author, "Extension:
compliance-fields", Open pull request 2853 to x402-
foundation/x402, specs/extensions/compliance_fields.md,
unmerged as of September 2026, July 2026,
<https://github.com/x402-foundation/x402/pull/2853>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, DOI 10.17487/RFC2801, April 2000,
<https://www.rfc-editor.org/info/rfc2801>.
Sharma Expires 20 March 2027 [Page 69]
Internet-Draft PACT September 2026
[I-D.ietf-httpapi-idempotency-key-header]
Jena, J. and S. Dalal, "The Idempotency-Key HTTP Header
Field", Work in Progress, Internet-Draft, draft-ietf-
httpapi-idempotency-key-header-07, 15 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
idempotency-key-header-07>.
[I-D.ietf-satp-core]
Hargreaves, M., Hardjono, T., Belchior, R., Ramakrishna,
V., and A. Chiriac, "Secure Asset Transfer Protocol (SATP)
Core", Work in Progress, Internet-Draft, draft-ietf-satp-
core-16, 13 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-satp-
core-16>.
[I-D.hood-agtp-commerce]
Hood, C., "AGTP-Commerce: Open Commerce Specification for
Agent-to-Agent Transactions", Work in Progress, Internet-
Draft, draft-hood-agtp-commerce-00, 28 June 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
commerce-00>.
[I-D.ietf-wimse-aims]
Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Identity Management
System", Work in Progress, Internet-Draft, draft-ietf-
wimse-aims-00, 15 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
aims-00>.
[I-D.stone-vcap-ap2-binding]
Stone, B., "VCAP-AP2 Binding: Verified Delivery Settlement
for the Agent Payments Protocol", Work in Progress,
Internet-Draft, draft-stone-vcap-ap2-binding-01, 4
September 2026, <https://datatracker.ietf.org/doc/html/
draft-stone-vcap-ap2-binding-01>.
[I-D.sahu-agent-action-receipts]
Sahu, N., "Signed, Hash-Chained Action Receipts for AI
Agents", Work in Progress, Internet-Draft, draft-sahu-
agent-action-receipts-00, 16 August 2026,
<https://datatracker.ietf.org/doc/html/draft-sahu-agent-
action-receipts-00>.
[I-D.mih-sato-agent-accountability-composition]
Mih, S., Sato, T., Schrock, I., Bu, S., and A. Sokolov,
"Agent Accountability: Composition and Conformance", Work
in Progress, Internet-Draft, draft-mih-sato-agent-
Sharma Expires 20 March 2027 [Page 70]
Internet-Draft PACT September 2026
accountability-composition-01, 16 August 2026,
<https://datatracker.ietf.org/doc/html/draft-mih-sato-
agent-accountability-composition-01>.
[I-D.asor-wimse-agent-delegation-chain]
Asor, R., "Verifiable Attenuated Delegation for AI Agent
Chains", Work in Progress, Internet-Draft, draft-asor-
wimse-agent-delegation-chain-01, 3 September 2026,
<https://datatracker.ietf.org/doc/html/draft-asor-wimse-
agent-delegation-chain-01>.
[I-D.pinto-agent-authz-contestability]
Pinto, T., "Contestability Bindings for Authorized Agent
Actions", Work in Progress, Internet-Draft, draft-pinto-
agent-authz-contestability-01, 10 September 2026,
<https://datatracker.ietf.org/doc/html/draft-pinto-agent-
authz-contestability-01>.
[I-D.laxsharma-pact-01]
Sharma, L., "PACT: Liability and Settlement for Autonomous
Agent Contracts", Internet-Draft, draft-laxsharma-pact-01,
superseded by this document, 4 September 2026,
<https://www.ietf.org/archive/id/draft-laxsharma-pact-
01.html>.
[I-D.laxsharma-pact-00]
Sharma, L., "PACT: A Contract Layer for Autonomous Agent
Commerce", Internet-Draft, draft-laxsharma-pact-00,
superseded, 27 July 2026,
<https://www.ietf.org/archive/id/draft-laxsharma-pact-
00.html>.
[ASOKAN98] Asokan, N., Shoup, V., and M. Waidner, "Asynchronous
Protocols for Optimistic Fair Exchange", Proceedings of
the IEEE Symposium on Security and Privacy, 1998,
<https://doi.org/10.1109/secpri.1998.674826>.
[BELENKIY08]
Belenkiy, M., Chase, M., Erway, C.C., Jannotti, J., Kupcu,
A., and A. Lysyanskaya, "Incentivizing Outsourced
Computation", Proceedings of the 3rd International
Workshop on Economics of Networked Systems (NetEcon '08),
pp. 85-90, 2008,
<https://doi.org/10.1145/1403027.1403046>.
Sharma Expires 20 March 2027 [Page 71]
Internet-Draft PACT September 2026
[POLINSKY99]
Polinsky, A.M. and S. Shavell, "Public Enforcement of
Law", Encyclopedia of Law and Economics, entry 8000,
Edward Elgar. The result is attributed therein to Bentham
(1789), 1999.
[SP800-186]
National Institute of Standards and Technology,
"Recommendations for Discrete Logarithm-based
Cryptography: Elliptic Curve Domain Parameters", NIST
Special Publication 800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
Appendix A. An Example Terms Profile: bonded-restitution
This appendix is not normative. It carries one terms profile, under
an example identifier and unregistered, so that the experiment in
Section 1.4 has something to run against and the vectors in the
reference repository have something to reproduce. It is the -01
revision's settlement content written as a schedule over the events
of Section 4.2, with the choices the -01 revision left open now made
and two of its own choices changed where the arithmetic or its text
required (Appendix A.5), and it is offered as an example of the form
a profile takes, not as a recommendation of these terms. What the
figures below mean between the parties to a contract that names this
profile is a question this document does not answer and its author is
not qualified to answer; a profile meant for use needs an owner who
is. Until such a profile exists, this one is also the only profile a
Facilitator can list, since terms_profiles must have an entry; that
is a fact about the present and not a rule of this document.
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
Sharma Expires 20 March 2027 [Page 72]
Internet-Draft PACT September 2026
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
as Appendix B shows.
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
Sharma Expires 20 March 2027 [Page 73]
Internet-Draft PACT September 2026
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.
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
Sharma Expires 20 March 2027 [Page 74]
Internet-Draft PACT September 2026
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, and two admission vectors, one
refused and one admitted at the boundary of the constraint.
Sharma Expires 20 March 2027 [Page 75]
Internet-Draft PACT September 2026
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
Figure 14: FINAL: the path of Figure 1
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
Figure 15: SETTLED on an upheld Challenge: the path of Figure 7
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.
Appendix B. Changes from -01
This revision separates the protocol from the meaning of its terms.
The -01 revision, in its title, abstract, Section 1.2 and throughout,
made who owed whom the subject of the document; one reader on the
IETF dispatch list, Rich Salz, read it in September 2026 as a legal
framework with a protocol attached, and another, John C Klensin,
wrote that its framing was tied closely enough to legal terminology
that the IETF was the wrong place to evaluate it; both were right.
What follows is the list of what changed, with the wire consequences
first.
Sharma Expires 20 March 2027 [Page 76]
Internet-Draft PACT September 2026
* The pact version is 0.2 and every committed digest changed
(Section 15). The -01 digests were computed by a canonicalizer
that serialized the number one as 1.0, which [RFC8785] does not
allow, so the spec_hash and vtc_hash the -01 revision printed are
not what a conforming implementation computes over the -01 example
objects. V-25 in Section 14.3 pins the rule and the -02 examples
were minted after the correction.
* The liability member is gone. A contract carries terms: a profile
URI, a digest over the profile's bundle, and an opaque parameter
object (Section 5.3). The -01 figures are the parameters of the
profile in Appendix A. assurance moved into that profile's
parameters; parent moved to the top level and gained facilitator.
* The four release modes are replaced by three flows and a profile
parameter: 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 (Section 7.1).
* verification.max_verdict_seconds is added, with the verdict-lapsed
event, so a silent Verifier cannot hold a contract in DELIVERED
forever (Section 7.2).
* The Work Attestation is the Outcome Record, with the RATS
collision explained (Section 1.3). Its subject, role, amounts and
outcome vocabulary are replaced by parties, an outcome object, the
full trace, and terms_result (Section 12). One record per
contract.
* Every response is a signed Contract Status carrying the trace,
replacing the unsigned state member the -01 revision added to
echoed objects (Section 11).
* The event trace and the state machine over it are new
(Section 4.2); RELEASING and PROPOSED are gone, AWAITING_CHILDREN
is added.
* delivery_hash covers the Delivery's signature; every digest covers
the signature set (Section 2). Signature sets are sorted and
ECDSA is low-S (Section 14.1). Merkle leaves cover signatures
(Section 12.2).
* A nonconformant Delivery is refused and recorded nowhere; the -01
revision treated it as a FAIL Verdict (Section 6). The Buyer
countersignature sentence is withdrawn.
Sharma Expires 20 March 2027 [Page 77]
Internet-Draft PACT September 2026
* A Verdict may carry challenge_hash; a Challenge may carry costs; a
Seller-signed Challenge is refused (Section 7).
* Contract trees work across Facilitators: child registration, child
outcome supply, child-unresolved, a finite latest finality instant
per contract and the rule L(child) before L(parent); the depth and
cycle rules are withdrawn with the reason (Section 10). The -01
Section 10.2, which had liability cascade upward as recovery and
not downward as discharge, is withdrawn to the profile;
Section 10.3 says only that this document does not state what a
child's outcome means for its parent.
* Section 3 is a data dictionary and a role table (Section 3); no
sentence in it requires anything of a party.
* Media types move to the vendor tree; the two registries and the
pact-escrow row are withdrawn; problem types move to a tag URI
namespace and the table lists every type the implementation emits
(Section 19).
* Retrieval is restricted by default and fetch discipline is stated
(Section 17.12, Section 17.5). The threat model says plainly what
is enforced against a Facilitator, which is nothing, and what is
attributable (Section 17.1).
* The experiment is restated over protocol observables
(Section 1.4).
* A contract carries exactly one signature per party and no other;
the -01 revision accepted further signers (Section 14.2).
* verification.arbiter is withdrawn; nothing read it.
* The capability document gains issued_at and retrieval, and its
flows must list verdict-first (Section 7.1). The well-known URI
is registered provisionally, with the author as change controller.
* A Verdict is accepted while one stands only in answer to a
Challenge (Section 4.2).
* The -01 rule that confidential content MUST NOT declare open
assurance is the profile's now; Appendix A.4 refuses open
assurance alone.
* signature-invalid and signature-missing are 400 and not 401, since
no HTTP authentication scheme is involved; V-26 names the
protected-header members a verifier rejects (Section 14.1).
Sharma Expires 20 March 2027 [Page 78]
Internet-Draft PACT September 2026
* Section 16 names the repository licence, Apache License 2.0; the
-01 said Revised BSD, which was wrong.
* alg names are the fully specified ones of [RFC9864], Ed25519 for
an Ed25519 key; the polymorphic EdDSA identifier the -01 used is
refused.
Acknowledgements
On the IETF dispatch list in September 2026, Rich Salz read the -01
revision as a legal framework with a protocol attached and said so,
and John C Klensin wrote that the framing of its terms was tied
closely enough to legal terminology that the IETF was the wrong place
to evaluate it. Both were right; this revision's split between
records and terms is the consequence, and the author is grateful for
the reading. The UTF-16 key-ordering vector that exposed a latent
canonicalization defect in the reference validator, and the
formulation of verifier independence as a relation the evaluator
derives rather than a field the record declares, came from Tersign
(wowlegend) on x402-foundation/x402 issue 3065. The observation that
verification tiers say how work is checked and never who checks it
came from msaleme on the same thread. Rich Smith's A2A Settlement
Extension was the clearest instance of the pattern the -01 revision
corrected, and he engaged with the critique on a2aproject/A2A
discussion 1576.
Author's Address
Laxmikant Sharma
Independent
Email: laxsharma79@gmail.com
Sharma Expires 20 March 2027 [Page 79]