-01 changelog: collected feedback

[laxsharma]

This issue collects substantive feedback on draft-laxsharma-pact-00 from every channel (IETF dispatch and agentproto, GitHub, Ethereum Magicians, LinkedIn, email). Format per entry: source link, one-line summary, disposition (accepted for -01 / not accepted, with reason / open question). The -01 worklist gets assembled from this thread.

Arriving with feedback? Comment here or open a dedicated issue. Both work.

[laxsharma]

Log entry 1: verifier independence, and the audit it triggered

Source: x402-foundation/x402#3065 (comment) (comment by @msaleme, 2026-08-06)

Summary: Verification tiers (Section 7) grade how strongly work is checked and never say who performs the check, which are separate properties that fail separately. Deterministic re-execution run by the seller and the same re-execution run by an independent challenger are the same tier and not the same evidence. T3-jury names an Arbiter without requiring it to be independent of the contracting parties. The open challenge window is the mechanism actually carrying independence, and the draft neither says so nor requires it.

Disposition: accepted for -01. Four changes: (a) Section 7 gains a normative split between tier (how work is checked) and verifier (who checks it for release), with release-gating verification required to come from a party that is not a contracting party or its affiliate, and seller-submitted evidence treated as input to verification rather than as verification; (b) the VTC verification member gains an explicit verifier identity so independence is contract-visible and auditable; (c) T3 gains arbiter independence and disclosure requirements, and arbiter acceptance becomes a validity condition; (d) Security Considerations gains a verifier-capture paragraph covering the case of a proof generated and verified entirely inside one party.

---

That comment prompted a full adversarial re-audit of the draft, schemas, examples, and tools/validate.py rather than a patch to Section 7. The audit ran five independent lenses: identity and spoofing, auction and contract-formation fraud, escrow and settlement economics, verification and evidence integrity, and privacy, regulatory, and operational risk. It found five structural problems, three of which are fatal to the protocol's central claim as written. Logging them here because they belong on the record, not in private notes.

Entry 2: the Bond is a fine, not collateral

Source: internal adversarial audit, 2026-08-06. Section 4.3.

Summary: Slashed Bond proceeds go to challenger costs, then a capped challenger bounty, then "a neutral sink rather than to any party to the dispute". The Buyer is a party to the dispute, so a defrauded Buyer recovers nothing from the Bond. Its only other recovery is "unspent releases", which the same section makes near-empty by releasing immediately on delivery. The words refund, restitution, compensation, and damages do not appear in the draft. Section 9's cascade language about curing a parent's obligations is contradicted by the same rule, and the cured outcome in the attestation enum has no mechanism that produces it.

Disposition: accepted for -01. Restitution-first waterfall: challenger documented costs, then Buyer restitution up to amounts already released, then capped bounty, then sink. A Facilitator must not direct proceeds to a sink while released value remains unrestituted. cured gets a normative definition.

Entry 3: pre-verification release exceeds the Bond, so defection dominates

Source: internal adversarial audit, 2026-08-06. Sections 4.3, 5, and common.schema.json.

Summary: Optimistic release is incentive-compatible only when the Bond is at least the value released before verification. Competitive second-price award drives margin toward zero, so the condition collapses to the Bond covering everything released. The draft's own worked example runs a 10 percent Bond against 75 to 100 percent released, where defecting pays roughly an order of magnitude better than honest performance. Compounding: the VTC has no checkpoint schedule member, so the Seller unilaterally decides how much value releases before verification, and window_seconds: 0 is schema-valid.

Disposition: accepted for -01. Cumulative release before final verification is capped at the Bond. Checkpoint schedules become co-signed VTC content with per-checkpoint amounts, acceptance references, and windows. window_seconds gains a nonzero minimum tied to the tier's published verification interval. Bond sizing guidance moves from percentage-of-price to estimated harm.

Entry 4: challenger economics are unfunded, and silence pays better than reporting

Source: internal adversarial audit, 2026-08-06. Sections 4.3 and 12.

Summary: Challenger reimbursement is payable from the slashed Bond, so it is capped by the Bond. For re-execution tiers, verification cost approximates execution cost, which for a competitively priced contract exceeds any plausible Bond fraction by roughly an order of magnitude. The MUST in Section 4.3 requiring reimbursement of documented verification costs is therefore unsatisfiable in the common case. Separately, a discoverer of fraud earns at most the capped bounty by reporting while the fraudulent Seller's exposure is the Bond plus unreleased price, so any private payment between those two figures leaves both parties better off than reporting. Extortion strictly dominates the designed mechanism. Section 4.3 claims to resolve the verifier's dilemma; on these numbers it does not.

Disposition: accepted for -01. A Verification Fund posted at Agree, separate from the Bond, sized to the tier's declared verification cost and returned if no challenge succeeds. Fraud proofs submitted as commitments and revealed after a deadline, with reimbursement paid to the earliest valid commitment rather than the earliest revealed proof. Challenger stake stated as a contract term rather than an unbounded implementation choice.

Entry 5: the object being judged does not exist in the protocol

Source: internal adversarial audit, 2026-08-06. Sections 4.3, 4.4, 7, 13, and all schemas.

Summary: There is no delivery message, no committed work product, no committed production input, and no evidence container. Four consequences. Missing tier evidence is not a fraud proof, because Section 7 defines the T1 proof as an invalid or mismatched attestation and the T2 proof as a failed verification, and absence is neither, so a Seller that attaches nothing is paid. Release fires on delivery, an event Section 13 guarantees the Facilitator cannot observe. Non-delivery has no remedy at all: task.deadline has no stated consequence, no challenge window ever opens, and escrow can lock permanently. Work Attestations certify that money moved, not that any artifact was produced.

Disposition: accepted for -01. A normative Delivery object with work_hash and tier-profiled evidence, a registered media type, and a Buyer-countersigned receipt. Release gated on presence and conformance of tier evidence, with absence or non-conformance promoted to a valid fraud proof for that tier. Deadline expiry wired to an automatic Buyer remedy and a new abandoned outcome.

Entry 6: hash commitments cover pointers rather than bytes, and this repository demonstrates it

Source: internal adversarial audit, 2026-08-06. Sections 5.1 and 5.2, taskspec.schema.json, tools/validate.py.

Summary: criteria_hash commits the TaskSpec acceptance object, which carries harness_uri as a URI string. The bytes at that URI are committed by nothing, and the schema provides no harness_hash, rubric_hash, sample_hash, or schema_hash. Section 5.1's integrity guarantee is scoped to spec_uri and does not reach URIs nested inside committed content. A Buyer can therefore swap the harness after signature, run it, and submit the failure as a textbook-valid T0 fraud proof, slashing an honest Seller's Bond and keeping the work. This repository makes the point concretely: validate.py checks criteria_hash against examples/acceptance-tests.txt, an 85-byte file whose entire content is a sentence describing the tests rather than the tests themselves. Separately, acceptance declares no required members, so an empty acceptance object is schema-valid and makes every fraud proof impossible.

Disposition: accepted for -01. Every URI inside hash-committed content gains a sibling hash over the dereferenced bytes. criteria_hash is computed over the executable instrument bundle, as an archive digest or a Merkle root over path and digest pairs. The production input gains a commitment rather than only a representative sample. The example harness and the validator check are replaced so the reference implementation stops teaching the vulnerability, and acceptance gains tier-conditional required members.

Entry 7: secondary findings, accepted in principle, detail pending

Source: internal adversarial audit, 2026-08-06.

Identity: Work Attestations name no subject, no role, and no Facilitator, so they can be re-presented by a non-party, laundered from a buyer record into a seller record, or fabricated by two cooperating identities, which falsifies the economic claim in Section 10; negative outcomes are structurally unobtainable because a slashed Seller declines to co-sign and the Facilitator has no signing role; kid sits outside the JWS protected header in common.schema.json, and there is no algorithm allowlist, typ, or serialization profile; the VTC names no Facilitator, network, or asset, so a co-signed contract is replayable across venues and chains; vtc_hash excludes the signature set, so the commitment proves what was written and not who agreed; did:web identity has no key history, rotation, or revocation story.

Auction: the award is unverifiable because the Buyer is auctioneer, sole record keeper, and residual claimant, with no bid book, no receipts, no transcript, and no obligation to award; recipient-key encryption to the Buyer is permitted as a sealing mode and is not sealed against the auctioneer, contradicting Section 12; the bid commitment binds neither bidder nor CFB, so commitments can be copied and replayed; nonce entropy is unspecified while the price space is publicly bounded; there is no bid bond and no reveal deadline, so winner defection and selective non-revelation are free; the VTC is not bound to the CFB or the winning bid, so terms including the Arbiter can be substituted after award.

Verification: T0 assumes determinism it never requires, with no pinned environment, seed, or tolerance, which lets an honest Seller be slashed by ordinary nondeterminism and lets a cheating Seller escape by asserting it; T2 commits no model, proof system, or verifying key, and prover-chosen sampling reduces soundness to zero; T1 has no attestation freshness, no reference values, and names no RATS Verifier distinct from the Relying Party; T3 slashes minority jurors, which is the vulnerable Schelling payoff and admits a near-free bribe; and no party is empowered to declare a fraud proof valid for the objective tiers, since the Facilitator is forbidden to adjudicate and the Arbiter is optional.

Privacy and regulatory: representative samples of real input are disclosed to unvetted bidders before any contract exists; the Section 5.1 retention duty conflicts with erasure rights and references an audit period the VTC cannot express; "MUST award to the best-ranked bid" forecloses sanctions and residency screening because no eligibility predicate exists; the Facilitator's legal status is unaddressed; Section 12 mandates publishing the settlement log while Section 13 claims counterparty privacy; and Section 13 contains no normative keywords.

Contract trees and channels: liability.parent is an unauthenticated string with no parent countersignature, so a third party can attach a failing child to someone else's contract and burn their Bond and reputation; self-subcontracting launders liability; there is no sum constraint, cycle detection, or depth limit; channels have no state schema, no highest-sequence-wins rule, no headroom cap, and no termination on Bond exhaustion.

Disposition: accepted in principle for -01, sequenced after entries 2 through 6, because the value flows and the evidence objects have to be right before the identity, auction, and tier fixes have anything stable to attach to.

---

Sequencing note for -01. The order is value flows, then the Delivery and evidence layer, then hash coverage, then identity and attestations, then auction verifiability, then tier profiles, then privacy and regulatory. That order is a dependency order rather than a priority order: correcting the economics without the evidence objects leaves nothing to verify, and correcting evidence without identity leaves the reputation layer free to counterfeit.

This is still a -00 published to be demolished. Anything above that looks wrong, or anything not yet found, is welcome here.

[laxsharma]

Log entries 8 to 20: second audit round

A second adversarial round ran on 2026-08-06 with four lenses that the first round did not use: corrected-economics design, evidence and verification layer design, a completeness critic tasked with finding what round one missed, and an IETF document-quality review. Round two produced one reframing that changes the -01 design, several findings round one missed, and a large set of document-level defects that would block the draft independently of any design question.

Entry 8: the reframe. Optimistic release was never worth what it cost

Summary: The -00 conflated two different things under "optimistic". Optimistic verification means nobody runs the acceptance instrument on the happy path, which saves the whole verification cost on every contract. Optimistic release means money moves before the challenge window closes, which is worth only the time value of the price over the window. On the draft's own worked example that second thing is worth $0.0033, while the seller's carry cost on collateral sized to make it safe is $0.0835, a ratio of 25 to 1 against the party it exists to benefit. Correctly collateralized, optimistic release is a null transaction. Under-collateralized, it is theft. There is no configuration in between where it earns its risk.

Disposition: accepted for -01. release.mode becomes a REQUIRED VTC member with four values: on-verification (the new default, mandatory to implement), on-window, optimistic, and unsecured. The last is the honest name for extending credit to a counterparty, and the spec will say plainly that no protocol-native remedy exists above the Bond for the unsecured portion.

Entry 9: the constraint the -00 was missing

Summary: Honest performance is a Seller's best response only where q * ((P - E) + B) >= C, with q the probability that a defection is detected, proven, and correctly adjudicated inside the dispute bounds. Conservatively, since a rational bidder has C at most P, this gives a facilitator-checkable form: B >= P(1-q)/q + E. Read as a requirement on q, a 10 percent Bond requires that 90.9 percent of defections are caught and proven. Under the -00, where no actor has positive expected value from checking, q is approximately zero. This shows that fixing the release rule alone does not close the protocol: deferring release still pays a defecting Seller in full whenever nobody checks. Detection probability, not release timing, is the binding constraint.

Disposition: accepted for -01. The VTC gains verification.assurance with a mode (certain, committed-sample, open) and a declared q_min, and a normative Assurance Constraint that a Facilitator MUST check before locking. open may never be the sole declared source of assurance. Sampling draws MUST derive from a Buyer seed committed before Phase C combined with the delivery commitment, so neither party can bias them.

Entry 10: the real security parameter is verification cost over price, not the tier

Summary: Three regimes follow from the ratio of verification cost to price. Below roughly 0.1 percent, verify every contract and size the Bond to harm alone. Between 0.1 and 10 percent, sampling is efficient but the assurance constraint forces a Bond near the full price. Above roughly 10 percent, no escrow configuration makes third-party challenge rational and the task is simply not economically verifiable at that price. The -00's worked example sits in the third band under a full-re-execution reading (92 percent) and in the first band under an acceptance-instrument reading (0.26 percent), which is the same tier with a hundredfold difference in whether the protocol works. This is also the direct answer to the finding on x402-foundation/x402#3065 that started all of this: what matters for release is not the tier label but who verifies and at what cost.

Disposition: accepted for -01. verification.profile is added, with acceptance, bisection, and full-reexec defined for T0. Section 7 is reconciled in favour of Section 5.2: the T0 fraud proof becomes a failing evaluation of the committed acceptance instrument against the committed delivery, and byte-level re-execution becomes one profile among three rather than the tier's definition. The -00 cites TRUEBIT for its bounty but never adopts the verification game that brings verification cost down, and that omission is the mechanical cause of the challenger-funding failure in entry 4.

Entry 11: no rule anywhere returns the Seller's Bond

Summary: The Bond enters the protocol in Section 4.2 and never leaves it. Section 4.4 closes escrow, and escrow is the Buyer's locked price, not the Seller's collateral. There is no bond-release rule in the document. Any reader who assumes the Bond returns on close is also contradicting Section 9's cascade, which requires it to stay exposed until every descendant contract has finalized.

Disposition: accepted for -01. Explicit bond release on contract finality, less any slashed amount, recorded in the Facilitator's log.

Entry 12: contract-tree finality is unordered, which makes both of Section 9's mechanisms unimplementable

Summary: Section 9's only ordering constraint is on task.deadline, and challenge windows are not deadlines. A child whose window is longer than its parent's finalizes after the parent. Two consequences. The parent's Work Attestation MUST carry a Merkle root over its children's attestation hashes, but a child attestation that does not exist yet cannot be committed, so a conformant implementation deadlocks on its own MUST. And if a child is successfully challenged after the parent settled, the cascade exposes a parent Bond that the settlement already disposed of, so the cascade is a rule about a value that no longer exists.

Disposition: accepted for -01. Finality becomes bottom-up: a Facilitator MUST NOT close escrow or release a Bond while any descendant remains non-final, and MUST reject a child VTC whose latest possible finality instant does not precede the parent's earliest. This depends on the parent-authentication fix in entry 7, since the ordering rule cannot be enforced against a parent the Facilitator cannot see.

Entry 13: the protocol has objects and no endpoints, so no two implementations can exchange a message

Summary: The -00 defines wire objects and not one address to send them to. There is no bid submission endpoint, no CFB distribution channel, no delivery address, no challenge submission address, no facilitator or arbiter address, and no attestation exchange address. The only URI in the protocol is the static well-known document, and attestation_jwks is a key set rather than a service. Four media types are registered for a protocol that needs at least a dozen wire objects. There is also no error object anywhere: every failure path is a bare "MUST reject", so a rejected bidder cannot distinguish "you were late" from "your commitment was malformed" from "you are ineligible" from "I am cheating you". In an auction whose auctioneer is also the residual claimant, silent rejection is the entire attack surface and the -00 makes silence the only available behaviour.

Disposition: accepted for -01. An endpoints object in the well-known document, TLS 1.3 or later required, all failure responses as Problem Details [RFC9457] with a "PACT Error Codes" registry, and media type registrations for every wire object rather than four.

Entry 14: the x402 auth-capture mapping does not close

Summary: This one matters most, because a live proposal at x402-foundation/x402#3065 and a community pull request at #3066 both depend on the mapping. Six concrete mismatches. The captureAuthorizer role has no home in PACT terms: making the Facilitator hold it gives it exactly the discretion Sections 3 and 12 forbid; making an on-chain predicate contract hold it requires the VTC and verification outcome on chain, which Section 13's privacy model prevents; making the Buyer hold it removes the Seller's protection entirely. x402 exposes /verify and /settle and nothing for capture, void, refund, or reclaim, so Section 8's claim that the predicate is evaluated at those interfaces is true only for the lock. auth-capture has no payee-side deposit, so the Bond has no instrument on that rail and slash has no mapping at all. The upto precedent is cited for a property upto forbids, since upto enforces single-use settlement while PACT checkpoints are repeated partial releases. Deadline semantics invert: auth-capture ends payer recourse at authorizationExpiry while PACT needs recourse live after release. And the -00 calls pact-escrow a scheme while what PACT actually contributes is a release policy over an existing scheme.

Disposition: accepted for -01, and this needs a public correction sooner than -01. Section 8's pact-escrow becomes a Release Policy profile with the captureAuthorizer explicitly required to be an instrument that is not either party, two conformant instantiations named, the Bond named as a separate instrument, and an explicit statement that auth-capture alone is insufficient because it cannot hold payee-side collateral. Open question for the x402 maintainers, recorded here because -01 must not assert it either way: does auth-capture permit repeated partial capture against a single authorization? The scheme files contain no occurrence of partial, incremental, multiple, or captureAmount. If it does not, a checkpointed PACT contract needs one authorization per checkpoint.

Entry 15: the A2A binding has no transport for anything after delivery

Summary: A2A terminal states admit no further messages and the stream closes. A Seller finishing work moves the A2A task to COMPLETED, which is exactly the instant PACT's challenge window opens. Every subsequent PACT object, the delivery record, the fraud proof, the arbiter ruling, the revert notice, the co-signed attestations, has nowhere to travel. PACT's entire Trust phase has no A2A transport. Separately, A2A CANCELED, REJECTED, and FAILED have no PACT representation, so the transport can cancel a task while the contract stays in force and escrow stays locked.

Disposition: accepted for -01. A normative A2A binding with an extension URI, metadata keys per object, and a two-task model: a Performance Task that completes on delivery and a Settlement Task opened at that instant which stays open until contract finality. State mappings for CANCELED, REJECTED, and FAILED.

Entry 16: the AP2 binding cites objects that no longer exist

Summary: Section 4.2 cites an "AP2 Intent or Cart Mandate". Those objects were replaced in AP2 v0.2, released 2026-04-28, three months before this draft was submitted; the current vocabulary is Checkout Mandate and Payment Mandate with Receipts. The deeper problem is not the rename. A closed Payment Mandate is a point-in-time authorization, and PACT releases value at multiple instants that are unknown when the human signs, for an amount a Vickrey award has not yet determined, possibly reverted afterwards. A closed mandate cannot authorize that. The construct that can is the open Payment Mandate, with amount ranges and execution windows, and the -00 does not know it exists.

Disposition: accepted for -01. Both citations replaced, the binding rewritten to REQUIRE an open Payment Mandate whose window covers deadline plus all challenge windows plus max dispute duration, verified once at contract effectiveness rather than at each release, with the mandate subject bound to parties.buyer by an RFC 7800 cnf claim. A closed mandate is permitted only for single-checkpoint contracts.

Entry 17: the missing role, and fourteen internal contradictions

Summary: The document review found that six of its contradictions are downstream of one hole: PACT has no Verifier role. Section 4.3 requires someone to determine that a fraud proof is valid, Sections 3 and 12 forbid the Facilitator from doing it, Section 5 makes the Arbiter OPTIONAL, and Section 7's escape clause covers only judgment-based tiers. Other contradictions: the Facilitator must write an object only the parties can sign; Section 4.3 releases immediately while Section 8 requires the predicate to enforce the window; Section 9's cascade cures a party Section 4.3's waterfall forbids paying; Section 12 mandates a public settlement log while Section 13 claims counterparty privacy; Sections 5.2 and 7 give two incompatible definitions of a failed deliverable; Section 12 claims a shill-resistance property Section 4.1 does not state; Section 4.4 closes escrow and emits attestations before arbitration can finish; Section 7's T1 role assignment contradicts both RFC 9334 and Section 3; and Section 5.1's retention rule is keyed to two things that do not exist ("contract finality" is undefined and the VTC cannot express an audit period).

Disposition: accepted for -01. The Verifier is introduced as a first-class role in Section 3 with its authority defined by predicate class: a Facilitator MAY evaluate total, deterministic predicates over data fixed in the co-signed VTC, and MUST NOT perform any evaluation requiring re-execution or judgment. Every listed contradiction gets resolving text.

Entry 18: document-level defects that would block the draft independently of the design

Summary: No threat model in Security Considerations. Privacy Considerations has no normative content. Normative dependencies on non-stable, non-IETF documents cited informatively, with a MUST in Section 8 pointing at an unversioned URL. IANA Considerations cannot be executed: no RFC 6838 media type templates, no registry field definitions, no designated expert instructions. No mandatory-to-implement algorithm and no JWS profile in a protocol whose security rests entirely on signatures. Two differently named version fields with no comparison rule and no mandatory-to-understand mechanism. Four dangling citations and one normatively used but undefined construction. Requirements phrased as "MUST be able to" and "MUST NOT be able to", which no party can test.

Disposition: accepted for -01. These are mechanical and will be fixed wholesale rather than logged individually.

Entry 19: what the review found sound, recorded so -01 does not break it

The hash-commitment-and-conveyance discipline in Section 5.1 is the right pattern and should be the template for the coverage fix rather than replaced. Binding the acceptance instrument to the CFB's criteria_hash is the one term the -00 carries correctly across phases and is the model for the settlement, arbiter, bond, and window bindings that are missing. Section 5.2's rule that the acceptance instrument governs over prose is the right call for machine-executable contracts. The settlement-binding abstraction in Section 8 survives: what fails is the specific pact-escrow mapping, not the idea of mapping a lifecycle onto a rail through a registered binding. The RATS framing in T1 is the correct standards choice and needs additions, not replacement. The [YOKOO] reasoning for excluding combinatorial awards is correct. And the primitive choices, JCS, JWS, algorithm-prefixed hashes, RFC 8615, RFC 8693, are right; composition over invention remains the draft's strongest feature.

Entry 20: open questions that -01 must not guess at

Whether x402 auth-capture permits repeated partial capture against one authorization. Whether a named verifier under assurance: certain may be the Buyer, or whether independence must be required above some contract value. How to close the residual bribe zone for contracts where the Buyer cannot verify its own deliverable, which is precisely the case that motivates T2-zkml and T3-jury. And the honest limit of the open-challenger model: even fully funded, the worked example equilibrates near a 3 percent fraud rate, and pushing that to 0.1 percent needs a bounty above the price and a Bond many times it. That is a property of the model rather than of the parameters, and -01 will state it rather than hide it.

[laxsharma]

Log entries 21 to 28: external review, prior art, and two corrections

Two things since the second audit round. Reviewers on adjacent specifications found
things the internal rounds did not, and a prior-art audit found that one of the entries
above claims something that is not new. Taking the correction first, because it is the
one that matters.

Entry 21: correction to entry 9. The constraint is not new

Source: prior-art audit, 2026-08-20. Primary sources read directly, not from summaries.

Entry 9 above records B >= P(1-q)/q + E as "the constraint the -00 was missing" and
treats it as a differentiator. The inequality is the classical deterrence bound and it
has been stated in this application domain since 2008. Three prior statements, in
increasing order of closeness:

• Polinsky and Shavell, Public Enforcement of Law, Encyclopedia of Law and
  Economics entry 8000, 1999: "the optimal fine is the harm h divided by the probability
  of detection p, that is, h/p", and with a public cost k of imposing the fine, "The
  optimal fine then becomes h/p + k". That survey traces the result to Bentham, 1789.
• Mamageishvili and Felten, Incentive Schemes for Rollup Validators,
  arXiv:2308.02880: the asserter's indifference condition is alpha = U/(R+U), which
  solved for the deposit rather than the checking probability is R = U(1-alpha)/alpha.
• Belenkiy, Chase, Erway, Jannotti, Kupcu and Lysyanskaya, Incentivizing Outsourced
  Computation, NetEcon '08, doi 10.1145/1403027.1403046. This one is not merely
  analogous. Their Theorem 1 sets the fine-to-reward ratio at f/r >= (1-p)/p for
  detection probability p, in the same application domain (a principal outsourcing
  computation to untrusted contractors), under the same premise the -01 work started
  from ("verifying a task's output requires as much work as computing it again"), with
  the fine posted in advance as a deposit held by the principal: "Real currencies might
  also be used if contractors offer the fine amount as deposit with the boss." That is
  entry 9's inequality with their fine as the Bond, their reward as the Price, and
  E = 0.

What survives. The E term. Every one of those settings withholds the reward until
the check has had its opportunity, so none of them has a notion of value released before
verification concludes. Optimistic release both hands part of the price to a defecting
Seller and puts it beyond recovery, so the required Bond rises one for one with it. That
is why a contract can satisfy the classical bound at Agree and violate it by the time
judgment arrives, and it is the only part of entry 9 that is ours.

Disposition: entry 9 stands as a constraint and is withdrawn as a novelty claim. The
-01 states the bound with Belenkiy cited first, in its Section 1.3 and again in 7.2.

There is a second consequence. Entry 4 accepted a capped challenger bounty. Belenkiy's
Theorem 6 gives a lower bound in the neighbouring redundancy setting: breaking the
equilibrium in which both contractors shirk requires a bounty of at least r/(1-q),
which is no less than the reward itself. The mechanism there is joint shirking rather
than the bilateral bribe of entry 4, so it is not the same argument, but it points the
same way and it is a formal statement of what entry 4 reached informally. The -01 bounty
rule cites it rather than rediscovering it, in its Section 7.4.

Entry 22: the broad novelty claim does not survive either

Source: prior-art audit, 2026-08-20.

The abstract's framing, that existing agent protocols move tasks and money and nothing
binds work to payment to proof, does not hold. Testing the -00's nine mechanisms against
the fair-exchange literature, the multi-agent literature, the 2026 ERC record and the
adjacent Internet-Drafts:

Mechanism	Verdict
Sealed-bid second-price award	Narrow. Absent from every merged ERC and every adjacent draft, but fully specified in the multi-agent literature, and commit-reveal against a cheating auctioneer is Lipmaa, Asokan and Niemi, FC 2002.
Co-signed hash-committed contract object	Survives on one field. ERC-8203 (ethereum/ERCs#1614) carries parties, price, hash-committed scope and a normative proof-type registry. It lacks liability.
Optimistic release	Narrow. Survives against the 2026 escrow standards, which are all pessimistic. Does not survive Asokan's revocability case, optimistic rollups, or arXiv:2606.21045.
Challenge window, bonded fraud proof, bounty	Covered. What is left is the remedy waterfall, and ERC-8033 already has disputeBond and disputerReimbursement.
Graded verification tiers	Covered. arXiv:2606.08790 has a strictly stronger admissibility ordering, and ERC-8004 names the same taxonomy.
Settlement-derived reputation	Covered. ERC-8275 derives it from escrow events by construction.
Recursive trees, cascading liability, Merkle-committed children	Survives. No subcontract notion anywhere in x402, the agent-commerce ERCs, or the adjacent drafts.
Payment channels	Covered. The x402 batch-settlement scheme is merged.
Bond sizing against detection probability	Covered. See entry 21.

Two further omissions, both structural rather than incidental. The -00's agree, perform,
verify, settle loop is optimistic fair exchange, a literature beginning with Asokan,
Schunter and Waidner at CCS 1997, and the draft cites none of it. And the reason that
literature does not answer the -01's question is worth stating rather than hiding: it
establishes what a third party must be able to do for an exchange to be fair, and takes
for granted that a dispute is decided on evidence, without asking who pays to produce
the evidence.

Disposition: accepted. The -01 narrows to what it can defend, which is liability as a
required member of a co-signed contract object, propagated through a Merkle-committed
subcontract tree. Everything else is composition and the draft is stronger for saying so,
with a related-work section that cites the above rather than waiting for a reviewer to
supply it.

Entry 23: verifier independence, second pass

Source: @msaleme and @wowlegend on x402-foundation/x402#3065, 2026-08-06 to 2026-08-19.

Entry 1 accepted that tiers grade how work is checked and never say who checks it. The
follow-up exchange sharpened that into three rules the -01 should carry as normative text
rather than as fields:

1. Derived, not declared. Independence is a relation between the attesting party and
   the parties to the contract, so it must be computed by the evaluator, not asserted by
   the record. A criterion satisfiable by writing a string reproduces the defect it was
   meant to catch. Stated as an evaluator-side disqualification in
   specs: add compliance-fields extension — tax/audit record + verifier disqualification rules (#2848) x402-foundation/x402#2853, specs/extensions/compliance_fields.md, section
   "independence".
2. Identity normalization before comparison. Party identifiers must be normalized and
   the normalization must fold toward same party, covering whitespace, case, EIP-55
   checksum variants and trailing /, . and #, with percent-encoding deliberately
   left undecoded because an open-ended normalizer is its own attack surface. An
   identifier that does not parse after normalization is not evaluable and must not be
   read as outside the parties. Same file, at 0f865a2.
3. Scope by commitment. An independence claim reaches exactly as far as the record's
   own commitments and no further. A settlement-scoped attestation, however independent
   its signer, carries no delivery or acceptance evidence. This is what stops
   "verifier is not the seller" being over-read as "the verifier saw that the work was
   right".

Disposition: accepted for -01, all three as MUST NOTs, citing #2853 as the prior
statement. One boundary recorded so the -01 does not overclaim a dependency: that rule
governs how an evaluator may read an attestation after the fact, while PACT's binds at
contract formation, constraining who may be named as verifier before any work happens.
Same disqualification, two enforcement points, and a conformance suite over the second
does not exercise the first.

Separately, @msaleme's RCL-007 is an executable negative vector rejecting a record whose
check is attested by its own emitter, and predates the -00. It should be cited as prior
art for the rule, not presented as a consequence of it.

Entry 24: the validator's canonicalization was wrong in a way no ASCII test would show

Source: a canonicalization vector raised by @wowlegend on the same thread, 2026-08-19.

jcs() in tools/validate.py was built on json.dumps(sort_keys=True), which orders
object keys by Unicode code point. RFC 8785 section 3.2.3 orders them by UTF-16 code
unit. The two agree throughout the Basic Multilingual Plane and diverge above it, since a
supplementary-plane key encodes as a surrogate pair beginning U+D800 and therefore sorts
below keys in U+E000 to U+FFFF.

No published hash changes. Every key in every shipped example is ASCII, so the two
orderings already agreed on all of them, and spec_hash, criteria_hash and vtc_hash
are byte-identical before and after. This was a latent defect, not a live one.

Worth recording anyway for the reason it was invisible: an implementation carrying that
shortcut passes an ASCII or BMP vector by accident, so the defect survives exactly the
tests an implementer would think to write. The module caveat had disclosed only the
number-serialization limitation and said nothing about key order, which was the more
misleading of the two omissions.

Disposition: fixed in #3, with two vectors pinning the order at the root and nested,
and the caveat rewritten to name what is fixed and what is still not implemented.

Entry 25: citation defects in the -00

Source: prior-art audit, 2026-08-20. All verified against the Datatracker API.

• draft-kotecha-agentic-dispute-protocol is dead. Still at -00 and expired
  17 April 2026. The -00 cites it as work in progress and names an ADP-conformant
  service as a candidate T3 Arbiter, which is a dangling normative dependency.
• draft-hood-agtp-commerce-00 (2026-06-28) is uncited. It was filed 26 days before
  the -00's document date, by the same author as the AGTP the -00 does cite as transport,
  and it carries Work Completion Records and an audit-verified settlement timing. This
  is the omission most likely to be found first.
• draft-stone-vcap-ap2-binding-00 (2026-03-17) is uncited, four months ahead of the
  -00's own ap2-mandate settlement binding.
• VCAP and ATEP are now at -01 (both 2026-03-24, expiring 2026-09-25) and AGTP is
  at -09 (2026-06-28). The -00 cites earlier revisions.
• [LONELY] is dated 2004. Ausubel and Milgrom, "The Lovely but Lonely Vickrey Auction",
  is 2006, in Cramton, Shoham and Steinberg, Combinatorial Auctions, MIT Press.

Disposition: accepted for -01, all five.

Entry 26: there is currently no venue for this layer

Source: IETF 126 agentproto BOF minutes, and the ART area charter repository.

The WG-forming BOF for agentproto was held on 23 July 2026. Sense of the room was
154 to 51 in favour of forming a working group, but only 38 to 124 that the initial
scope was correct. The draft charter contains no occurrence of commerce, payment,
escrow, settlement, contract, economics or reputation, in scope, deliverables, or the
out-of-scope list. Separately, the community landscape at nomoticai/ietf-agent-landscape
opens its agentic commerce section with "No dedicated venue or BoF", and does not list
this draft.

Disposition: open question, not a -01 change. Recorded because it bears on where the
-01 goes rather than what it says. If the charter is settled without commerce in scope,
this layer has no working group, and the individual-submission path plus the adjacent
drafts in entry 25 are the whole ecosystem.

Entry 27: what entries 21 to 26 did to the -01 scope

The -00 is 4,963 words attempting the surface area of a protocol suite. For comparison,
RFC 9635 (GNAP) is 63,382 words for one protocol, and RFC 8785, the smallest thing the
-00 depends on, is 5,012. The prior-art result says most of that surface is already
occupied. Both point the same way.

That was written before -01 existed. It now does, and this is what it did:

1. Kept and specified liability as a required, co-signed member, and the
   Merkle-committed subcontract tree with cascading liability, including entry 12's
   bottom-up finality rule and an explicit ordering inequality.
2. Kept as composition and cited: the settlement loop as optimistic fair exchange
   (Asokan, Shoup and Waidner), the bond rule as the deterrence bound (Belenkiy;
   Polinsky and Shavell; Mamageishvili and Felten), and independence against #2853.
3. Cut contract channels and the sealed-bid award procedure. The tree survived,
   so it stayed. Both removals are justified in the -01's Section 1.2 rather than
   left for a reader to notice.
4. Fixed the economics: three separated value pools, a restitution-first
   waterfall, a facilitator-checkable assurance constraint, an explicit bond-release
   rule, and on-verification replacing optimistic release as the default and the
   only mode required of conformant implementations.

It also added what the -00 was missing rather than merely wrong about: a Delivery
object, protocol endpoints, a conformance section, and a worked example carried in
the document.

The result is 42 pages against the -00's 16, with 94 MUST and 19 MUST NOT against 32
and 5.

Entry 28: the -00 specification and its reference implementation had decoupled

Source: self-audit, 2026-09-03.

Four rules were enforced by tools/validate.py or the schemas with no normative text
anywhere in the -00: the JWS algorithm allowlist, kid placement inside the protected
header, harness_hash alongside harness_uri, and the instrument-manifest
construction for criteria_hash. The algorithm one is security-relevant rather than
cosmetic: an implementer working from the document alone was open to alg: none and to
confusion of a public key for a symmetric secret, and their implementation was then
rejected by the reference validator for a rule it had never been told.

This is the same defect this repository was raising with other specifications during
August, where a rule lived in a conformance suite and not in the spec text.

Two related findings. The published -00 carries no hash values and no numeric example
anywhere in its .txt, .xml or .html, so the document made no verifiable claim about
its own reference implementation. And criteria_hash meant one thing in the document,
which described it as committing the acceptance object, and another in the repository,
which computed it as a manifest of per-file digests.

Disposition: fixed. -01 Section 13 states every rule a conformance checker
enforces, Section 16 carries a worked example with its digests, and Section 5.1
specifies the manifest construction. #4 brings the schemas, examples and validator to
match, taking the suite from 30 checks to 54.

One consequence worth recording because it breaks things: vtc_hash in -01 covers
the contract including its signature set, where the -00 excluded it. The -00
commitment proved what was written and not who agreed to it, so signature entries could
be appended or stripped without invalidating it. Digests computed under the two
definitions differ and an -00 contract does not validate against the -01 schema. Both
are intended.

---

Timing: the target is the IETF 127 I-D submission cutoff on 2 November 2026, not the
28 January 2027 expiry.

As before, this is a -00 published to be demolished. Entries 21, 22 and 28 are the
largest demolitions so far and all three came from looking harder rather than from a
reviewer, which is not a reason to be pleased about them.