@integraledger/lcp-binding-evm-mpp 0.12.0 → 0.12.1

package/CHANGELOG.md

@@ -1,5 +1,35 @@
 # @integraledger/lcp-binding-evm-mpp
 
+## 0.12.1
+
+### Patch Changes
+
+- 353352f: MPP-EVM: the §8.3.5 discharge is not checked in this package, and the profile said it was
+
+  `MPP_EVM_MANIFEST`'s finality note read _"The tree checks it as OFR — `offerBoundStep`, required at TC-4"_
+  about the §8.3.5 discharge, which per LCP §C.1 rests on the ATR **stating the transaction parameters**.
+  `offerBoundStep` is, in full, `c?.offerBound ? proved : not-attempted("no-offer")` — one boolean off the
+  composition slot. It never sees an ATR and cannot establish anything about what the hashed document states.
+
+  That claim is published: it ships in `vectors/binding/mpp-evm-profile.json` and the `binding.profiles`
+  corpus case, where a stranger's auditor reads it as a check this software performs.
+
+  The note now says what is true — that nothing in this package establishes the discharge and no verifier
+  reading the wire alone can, because whether the ATR states the parameters is a property of the bytes the
+  seller hashed, checkable only against the ATR itself. It names `offerBoundStep` explicitly as the thing
+  sometimes mistaken for it, and says what that step actually reports.
+
+  `offerBoundStep`'s contract is now pinned beside the step in `verify`'s own suite: it proves on the flag
+  alone with every field of the charge absent, and an unbound offer is incompleteness rather than a failure.
+  A future change that made it a real parameter check fails that test and forces the profiles describing it to
+  be revisited.
+
+  ⚠️ No behaviour changes. The corpus root moves because the profile document is part of the sealed corpus.
+
+  - @integraledger/lcp-binding-core@0.12.1
+  - @integraledger/lcp-binding-evm-common@0.12.1
+  - @integraledger/lcp-kernel@0.12.1
+
 ## 0.12.0
 
 ### Patch Changes

package/dist/manifest.js

@@ -75,7 +75,7 @@ export const MPP_EVM_MANIFEST = {
     indexing: "none",
     finality: {
         reversible: false,
-        note: "scoped to MPP's `authorization` credential type (§5.3), the only one of the four whose challengeHash reaches the chain — under the RECOMMENDED `permit2` type (§5.2) the same derived value is signature-committed in an off-chain EIP-712 witness, and `transaction`/`hash` (§5.4/§5.5) bind no challenge at all. Within that scope: final on settlement — the EIP-3009 authorization is consumed on-chain and there is no on-rail reversal; the weld is derivation-bound (nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm)), draft-evm-charge-00 §5.3.1), so a candidate atrHash is VERIFIED against the on-chain nonce and never recovered from it; recourse is the record's elected forum (PAY-3/RCS-5), never dispute resolution. The §8.3.5 discharge rests on the ATR STATING the transaction parameters (LCP §6.1), not on ATR uniqueness: MPP binds the challenge id to the challenge parameters, and uniqueness alone does not satisfy that (§C.1). The tree checks it as OFR — `offerBoundStep`, required at TC-4 — so this weld is only as strong as the record's class. Zero-party-recoverable on-chain binding on this rail still requires an Overlay Contract per §8.3.2",
+        note: "scoped to MPP's `authorization` credential type (§5.3), the only one of the four whose challengeHash reaches the chain — under the RECOMMENDED `permit2` type (§5.2) the same derived value is signature-committed in an off-chain EIP-712 witness, and `transaction`/`hash` (§5.4/§5.5) bind no challenge at all. Within that scope: final on settlement — the EIP-3009 authorization is consumed on-chain and there is no on-rail reversal; the weld is derivation-bound (nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm)), draft-evm-charge-00 §5.3.1), so a candidate atrHash is VERIFIED against the on-chain nonce and never recovered from it; recourse is the record's elected forum (PAY-3/RCS-5), never dispute resolution. The §8.3.5 discharge rests on the ATR STATING the transaction parameters (LCP §6.1), not on ATR uniqueness: MPP binds the challenge id to the challenge parameters, and uniqueness alone does not satisfy that (§C.1). **Nothing in this package establishes that discharge, and no verifier reading the wire alone can.** Whether the ATR states the transaction parameters is a property of the bytes the seller hashed, so it is checkable only against the ATR itself — by the party that minted it, before the weld, or by a counterparty that fetches the document and reads it. `offerBoundStep` is sometimes read as covering this and does not: it reports whether the record carries an offer binding at all, which is a different question and answers `not-attempted` rather than `failed` when it does not. Zero-party-recoverable on-chain binding on this rail still requires an Overlay Contract per §8.3.2",
     },
     weldGrades: { authorization: "signature" },
     lifecycleStates: ["proposed", "settled"],

package/dist/manifest.js.map

@@ -1 +1 @@
-{"version":3,"file":"manifest.js","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8DG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAoB;IAC/C,IAAI,EAAE,SAAS;IACf,QAAQ,EAAE,KAAK;IACf,OAAO,EAAE,UAAU;IACnB,QAAQ,EAAE;QACR,OAAO,EAAE,IAAI;QACb,oBAAoB,EAAE,KAAK;QAC3B,gBAAgB,EAAE,KAAK;KACxB;IACD,YAAY,EAAE,UAAU,EAAE,0GAA0G;IACpI,WAAW,EAAE,YAAY,EAAE,8DAA8D;IACzF,QAAQ,EAAE,MAAM;IAChB,QAAQ,EAAE;QACR,UAAU,EAAE,KAAK;QACjB,IAAI,EAAE,0oCAA0oC;KACjpC;IACD,UAAU,EAAE,EAAE,aAAa,EAAE,WAAW,EAAE;IAC1C,eAAe,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;CACzC,CAAC"}
+{"version":3,"file":"manifest.js","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8DG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAoB;IAC/C,IAAI,EAAE,SAAS;IACf,QAAQ,EAAE,KAAK;IACf,OAAO,EAAE,UAAU;IACnB,QAAQ,EAAE;QACR,OAAO,EAAE,IAAI;QACb,oBAAoB,EAAE,KAAK;QAC3B,gBAAgB,EAAE,KAAK;KACxB;IACD,YAAY,EAAE,UAAU,EAAE,0GAA0G;IACpI,WAAW,EAAE,YAAY,EAAE,8DAA8D;IACzF,QAAQ,EAAE,MAAM;IAChB,QAAQ,EAAE;QACR,UAAU,EAAE,KAAK;QACjB,IAAI,EAAE,qlDAAqlD;KAC5lD;IACD,UAAU,EAAE,EAAE,aAAa,EAAE,WAAW,EAAE;IAC1C,eAAe,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;CACzC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integraledger/lcp-binding-evm-mpp",
-  "version": "0.12.0",
+  "version": "0.12.1",
   "description": "Welds an LCP record into an MPP settlement on EVM by Id-Reuse (LCP §8.3.5).",
   "keywords": [
     "lcp",
@@ -43,9 +43,9 @@
   "homepage": "https://github.com/IntegraLedger/integra-protocol/tree/main/packages/binding-evm-mpp#readme",
   "dependencies": {
     "viem": "2.55.11",
-    "@integraledger/lcp-binding-core": "0.12.0",
-    "@integraledger/lcp-kernel": "0.12.0",
-    "@integraledger/lcp-binding-evm-common": "0.12.0"
+    "@integraledger/lcp-binding-core": "0.12.1",
+    "@integraledger/lcp-kernel": "0.12.1",
+    "@integraledger/lcp-binding-evm-common": "0.12.1"
   },
   "devDependencies": {
     "@types/node": "24.13.3",

package/src/manifest.ts

@@ -77,7 +77,7 @@ export const MPP_EVM_MANIFEST: BindingManifest = {
   indexing: "none",
   finality: {
     reversible: false,
-    note: "scoped to MPP's `authorization` credential type (§5.3), the only one of the four whose challengeHash reaches the chain — under the RECOMMENDED `permit2` type (§5.2) the same derived value is signature-committed in an off-chain EIP-712 witness, and `transaction`/`hash` (§5.4/§5.5) bind no challenge at all. Within that scope: final on settlement — the EIP-3009 authorization is consumed on-chain and there is no on-rail reversal; the weld is derivation-bound (nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm)), draft-evm-charge-00 §5.3.1), so a candidate atrHash is VERIFIED against the on-chain nonce and never recovered from it; recourse is the record's elected forum (PAY-3/RCS-5), never dispute resolution. The §8.3.5 discharge rests on the ATR STATING the transaction parameters (LCP §6.1), not on ATR uniqueness: MPP binds the challenge id to the challenge parameters, and uniqueness alone does not satisfy that (§C.1). The tree checks it as OFR — `offerBoundStep`, required at TC-4 — so this weld is only as strong as the record's class. Zero-party-recoverable on-chain binding on this rail still requires an Overlay Contract per §8.3.2",
+    note: "scoped to MPP's `authorization` credential type (§5.3), the only one of the four whose challengeHash reaches the chain — under the RECOMMENDED `permit2` type (§5.2) the same derived value is signature-committed in an off-chain EIP-712 witness, and `transaction`/`hash` (§5.4/§5.5) bind no challenge at all. Within that scope: final on settlement — the EIP-3009 authorization is consumed on-chain and there is no on-rail reversal; the weld is derivation-bound (nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm)), draft-evm-charge-00 §5.3.1), so a candidate atrHash is VERIFIED against the on-chain nonce and never recovered from it; recourse is the record's elected forum (PAY-3/RCS-5), never dispute resolution. The §8.3.5 discharge rests on the ATR STATING the transaction parameters (LCP §6.1), not on ATR uniqueness: MPP binds the challenge id to the challenge parameters, and uniqueness alone does not satisfy that (§C.1). **Nothing in this package establishes that discharge, and no verifier reading the wire alone can.** Whether the ATR states the transaction parameters is a property of the bytes the seller hashed, so it is checkable only against the ATR itself — by the party that minted it, before the weld, or by a counterparty that fetches the document and reads it. `offerBoundStep` is sometimes read as covering this and does not: it reports whether the record carries an offer binding at all, which is a different question and answers `not-attempted` rather than `failed` when it does not. Zero-party-recoverable on-chain binding on this rail still requires an Overlay Contract per §8.3.2",
   },
   weldGrades: { authorization: "signature" },
   lifecycleStates: ["proposed", "settled"],