@integraledger/lcp-binding-evm-mpp 0.9.0

package/dist/credential-type.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"credential-type.js","sourceRoot":"","sources":["../src/credential-type.ts"],"names":[],"mappings":"AAiCA;;;;;;;GAOG;AACH,MAAM,UAAU,8BAA8B,CAAC,KAAa;IAC1D,OAAO;QACL,OAAO,EAAE,IAAI;QACb,SAAS,EAAE,sBAAsB;QACjC,IAAI,EAAE,2CAA2C;QACjD,MAAM,EAAE,SAAS,KAAK,2ZAA2Z;KAClb,CAAC;AACJ,CAAC"}

package/dist/id-reuse.d.ts

@@ -0,0 +1,130 @@
+/**
+ * MPP-EVM Id-Reuse (LCP §8.3.5): the host's derivation rule, the weld it produces, and the *only* kind of
+ * check the resulting on-chain value permits.
+ *
+ * **THE HOST RULE, quoted.** `draft-evm-charge-00` §5.3.1 (paymentauth.org, read 2026-07-30):
+ *
+ *     nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm))
+ *
+ * — with the accompanying sentence "This specification requires the nonce to be set to the `challengeHash`".
+ * The nonce is therefore a *derivation*, not a slot: there is nothing here for LCP to occupy. What LCP does
+ * instead is supply an input — the seller sets `challenge.id = atrHash` — so the host's own required
+ * derivation carries the record into the settlement transaction.
+ *
+ * **WHAT MAKES THAT SOUND IS NOT UNIQUENESS, AND AN EARLIER DOCBLOCK SAID IT WAS.** It argued that MPP's
+ * "Unique challenge identifier" requirement (`draft-httpauth-payment` §5.1.1) was satisfied by making each
+ * ATR unique per transaction. Every citation in it was exact; the sufficiency was not. LCP v1.38 §C.1
+ * (:1282-1289):
+ *
+ * > **It is not simply available, and §8.3.5's uniqueness advice is not sufficient for it.** MPP requires
+ * > the server to bind the challenge `id` *to the challenge parameters* … expressly to prevent a client
+ * > altering the challenge it presents. **Making each ATR unique per transaction satisfies uniqueness but
+ * > not that binding.** A per-transaction ATR that itself states the transaction parameters (Section 6.1)
+ * > satisfies both, because the parameters are then inside the hashed document; a terms document made
+ * > unique by a timestamp alone does not.
+ *
+ * **THE REQUIREMENT IS ON THE ATR, AND THE TREE ALREADY VERIFIES IT.** This binding holds a hash, never the
+ * document, so it cannot inspect what the ATR says — and it should not: where the ATR lives is the seller's
+ * and buyer's business, and a rail binding that needed the document would assert a custody LCP does not
+ * require. The property §C.1 asks for is **OFR**: the ATR's offer slot is bound, meaning the transaction
+ * parameters are inside the hashed document. `verify` implements it as `offerBoundStep`
+ * (`verify/src/composition.ts`) and requires it at **TC-4** (`verify/src/required.ts`). So a record whose
+ * class is TC-4 has had this checked by the layer that holds the document; a record below TC-4 has not, and
+ * the §8.3.5 discharge on this rail is only as good as that rung.
+ *
+ * The host is internally inconsistent here and the split is kept visible deliberately: the core draft
+ * states the challenge-parameter binding as a **MUST** in the `id` field description and as a **SHOULD** in
+ * its challenge-binding section. §C.1 names that inconsistency rather than resolving it, and so does this.
+ *
+ * **Zero-party-recoverable on-chain binding on this rail still requires an Overlay Contract per §8.3.2**
+ * (§C.1:1289). Nothing here recovers an atrHash, and nothing may be added that does — see the closing note.
+ *
+ * **`abi.encodePacked` over two strings is raw UTF-8 concatenation** — no length prefix, no padding. That was
+ * confirmed against Foundry's own encoder rather than assumed, and every oracle in
+ * `vectors/binding/mpp-evm-id-reuse.json` was produced by two independent keccak-256 implementations,
+ * neither of them the one used here.
+ *
+ * **The atrHash's SPELLING is part of the preimage.** The derivation hashes the id *as a string*, so
+ * `0x7f83…` and `7f83…` are different challenge ids with different nonces. This module therefore canonicalizes
+ * to LCP's own spelling — lowercase, `0x`-prefixed, 32 bytes — before deriving OR comparing, on both the
+ * candidate and the observed nonce. An uppercase-hex spelling of the same bytes is a legal input that reaches
+ * the same nonce, not a second wire convention: it is normalized, and the vectors pin that both ways round.
+ * What is REJECTED is a value that is not 32 hex bytes at all — a missing `0x`, a wrong length, a non-hex
+ * digit. Those are different challenge ids rather than spellings of this one, and there is no canonical form
+ * to map them to.
+ *
+ * **Packed concatenation is undelimited, and the fixed length is what makes that safe.** `('ab','c')` and
+ * `('a','bc')` pack identically; the vectors pin that as an observed property of the host rule. It is
+ * unreachable for this binding because `challenge.id` is always exactly 66 characters, so no other split of
+ * the preimage produces a legal id. The length check below is therefore load-bearing, not defensive noise.
+ *
+ * **NOTHING HERE RECOVERS AN atrHash, and no future edit may add such a path.** keccak-256 has no inverse:
+ * the honest surface is confirmation of a candidate the auditor already holds. Re-deriving from a stored
+ * challenge would be service-record recovery wearing the name of zero-party recovery, and would falsify
+ * `zeroPartyRecoverable: false` in the manifest.
+ */
+import type { Outcome, Refusal } from "@integraledger/lcp-binding-core";
+import { type Hex } from "viem";
+/** The challenge the seller emits, and the nonce the buyer's authorization will therefore carry. */
+export interface MppEvmChallengeBinding {
+    /** `challenge.id` — the atrHash itself, in LCP's canonical lowercase `0x` spelling. */
+    readonly challengeId: Hex;
+    /** `challenge.realm` — MPP's protection space, the second half of the preimage. */
+    readonly realm: string;
+    /** The EIP-3009 nonce `keccak256(abi.encodePacked(id, realm))` requires. DERIVED, never chosen. */
+    readonly nonce: Hex;
+}
+/** A candidate atrHash confirmed against a settlement's on-chain nonce. Confirmation, never recovery. */
+export interface MppEvmCandidateConfirmation {
+    readonly confirmed: true;
+    /** The candidate that reproduced the on-chain nonce, canonicalized. */
+    readonly atrHash: Hex;
+    /** The protection space the derivation was performed under — the confirmation is scoped to it. */
+    readonly realm: string;
+    /** The on-chain nonce the candidate reproduced. */
+    readonly nonce: Hex;
+}
+/**
+ * MPP's derivation, exactly as its EVM method specifies it: `keccak256(abi.encodePacked(id, realm))`.
+ *
+ * Total over any two non-empty strings, because it implements MPP's rule and not an LCP-specific one — an
+ * ordinary opaque challenge id derives here too, which is what makes this the host's function rather than
+ * ours. THROWS on an empty id or realm: MPP requires both on every challenge (`realm` is a MUST per
+ * §5.1.1), so an empty one is a wiring defect in the caller, not a value to hash.
+ */
+export declare function deriveChallengeHash(challengeId: string, realm: string): Hex;
+/**
+ * The Id-Reuse weld at PROPOSAL time: `challenge.id = atrHash`, and the nonce that follows from it.
+ *
+ * THROWS on a malformed atrHash, via `canonicalAtrHash` — a seller welding a hash that is not 32 bytes is a
+ * wiring defect, and the guard is also what keeps the fixed-length argument above true of the code.
+ *
+ * **Do not reach for `binding-evm-common`'s `assertBytes32` here.** It enforces the same 32 bytes but
+ * explains them as the value that will "ride as the EIP-3009 nonce" — true on x402, false on this rail, and
+ * precisely the cross-rail misreading `binding-evm-x402`'s KNOWN-BAD note exists to stop. On MPP-EVM the
+ * atrHash rides `challenge.id` and the nonce is DERIVED from it, never occupied by it. `canonicalAtrHash`
+ * states the shape requirement and nothing about where the value rides, which is why it is the right guard:
+ * the rail-specific reasoning belongs in this docblock and in the manifest, not in an error string.
+ */
+export declare function bindAtrHash(atrHash: string, realm: string): MppEvmChallengeBinding;
+/**
+ * Confirm a candidate atrHash against the `AuthorizationUsed` nonces ONE settlement emitted.
+ *
+ * The auditor brings the atrHash (from the record, or from `legal-context.json`); the chain confirms it.
+ * Refusals rather than throws, because both the candidate and the observed nonces are data under audit —
+ * the realm is not: it is the verifier's own configuration, so an empty one throws.
+ *
+ * Every observed nonce is validated BEFORE any is matched: a malformed entry refuses loudly instead of being
+ * skipped past, because silently narrowing a settlement view could turn "this transaction is not what you
+ * think" into "no match found".
+ */
+export declare function checkCandidate(atrHash: string, realm: string, observedNonces: readonly string[]): Outcome<MppEvmCandidateConfirmation>;
+/**
+ * The refusal recovery always returns, stated in one place so the reason travels with the code.
+ *
+ * Not a "not implemented yet" and not a gap to be filled: the on-chain value is a hash over the atrHash, so
+ * there is no function from settlement to atrHash to write. A caller wanting the record must bring the
+ * candidate and use `verifyCandidate`.
+ */
+export declare function notRecoverableByConstruction(): Refusal;
+//# sourceMappingURL=id-reuse.d.ts.map

package/dist/id-reuse.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"id-reuse.d.ts","sourceRoot":"","sources":["../src/id-reuse.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AAEH,OAAO,KAAK,EAAE,OAAO,EAAE,OAAO,EAAE,MAAM,iCAAiC,CAAC;AAExE,OAAO,EAAU,KAAK,GAAG,EAA4B,MAAM,MAAM,CAAC;AAKlE,oGAAoG;AACpG,MAAM,WAAW,sBAAsB;IACrC,uFAAuF;IACvF,QAAQ,CAAC,WAAW,EAAE,GAAG,CAAC;IAC1B,mFAAmF;IACnF,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,mGAAmG;IACnG,QAAQ,CAAC,KAAK,EAAE,GAAG,CAAC;CACrB;AAED,yGAAyG;AACzG,MAAM,WAAW,2BAA2B;IAC1C,QAAQ,CAAC,SAAS,EAAE,IAAI,CAAC;IACzB,uEAAuE;IACvE,QAAQ,CAAC,OAAO,EAAE,GAAG,CAAC;IACtB,kGAAkG;IAClG,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;IACvB,mDAAmD;IACnD,QAAQ,CAAC,KAAK,EAAE,GAAG,CAAC;CACrB;AAED;;;;;;;GAOG;AACH,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,GAAG,CAU3E;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,WAAW,CACzB,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,MAAM,GACZ,sBAAsB,CAOxB;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,cAAc,CAC5B,OAAO,EAAE,MAAM,EACf,KAAK,EAAE,MAAM,EACb,cAAc,EAAE,SAAS,MAAM,EAAE,GAChC,OAAO,CAAC,2BAA2B,CAAC,CAsCtC;AAED;;;;;;GAMG;AACH,wBAAgB,4BAA4B,IAAI,OAAO,CAQtD"}

package/dist/id-reuse.js

@@ -0,0 +1,166 @@
+/**
+ * MPP-EVM Id-Reuse (LCP §8.3.5): the host's derivation rule, the weld it produces, and the *only* kind of
+ * check the resulting on-chain value permits.
+ *
+ * **THE HOST RULE, quoted.** `draft-evm-charge-00` §5.3.1 (paymentauth.org, read 2026-07-30):
+ *
+ *     nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm))
+ *
+ * — with the accompanying sentence "This specification requires the nonce to be set to the `challengeHash`".
+ * The nonce is therefore a *derivation*, not a slot: there is nothing here for LCP to occupy. What LCP does
+ * instead is supply an input — the seller sets `challenge.id = atrHash` — so the host's own required
+ * derivation carries the record into the settlement transaction.
+ *
+ * **WHAT MAKES THAT SOUND IS NOT UNIQUENESS, AND AN EARLIER DOCBLOCK SAID IT WAS.** It argued that MPP's
+ * "Unique challenge identifier" requirement (`draft-httpauth-payment` §5.1.1) was satisfied by making each
+ * ATR unique per transaction. Every citation in it was exact; the sufficiency was not. LCP v1.38 §C.1
+ * (:1282-1289):
+ *
+ * > **It is not simply available, and §8.3.5's uniqueness advice is not sufficient for it.** MPP requires
+ * > the server to bind the challenge `id` *to the challenge parameters* … expressly to prevent a client
+ * > altering the challenge it presents. **Making each ATR unique per transaction satisfies uniqueness but
+ * > not that binding.** A per-transaction ATR that itself states the transaction parameters (Section 6.1)
+ * > satisfies both, because the parameters are then inside the hashed document; a terms document made
+ * > unique by a timestamp alone does not.
+ *
+ * **THE REQUIREMENT IS ON THE ATR, AND THE TREE ALREADY VERIFIES IT.** This binding holds a hash, never the
+ * document, so it cannot inspect what the ATR says — and it should not: where the ATR lives is the seller's
+ * and buyer's business, and a rail binding that needed the document would assert a custody LCP does not
+ * require. The property §C.1 asks for is **OFR**: the ATR's offer slot is bound, meaning the transaction
+ * parameters are inside the hashed document. `verify` implements it as `offerBoundStep`
+ * (`verify/src/composition.ts`) and requires it at **TC-4** (`verify/src/required.ts`). So a record whose
+ * class is TC-4 has had this checked by the layer that holds the document; a record below TC-4 has not, and
+ * the §8.3.5 discharge on this rail is only as good as that rung.
+ *
+ * The host is internally inconsistent here and the split is kept visible deliberately: the core draft
+ * states the challenge-parameter binding as a **MUST** in the `id` field description and as a **SHOULD** in
+ * its challenge-binding section. §C.1 names that inconsistency rather than resolving it, and so does this.
+ *
+ * **Zero-party-recoverable on-chain binding on this rail still requires an Overlay Contract per §8.3.2**
+ * (§C.1:1289). Nothing here recovers an atrHash, and nothing may be added that does — see the closing note.
+ *
+ * **`abi.encodePacked` over two strings is raw UTF-8 concatenation** — no length prefix, no padding. That was
+ * confirmed against Foundry's own encoder rather than assumed, and every oracle in
+ * `vectors/binding/mpp-evm-id-reuse.json` was produced by two independent keccak-256 implementations,
+ * neither of them the one used here.
+ *
+ * **The atrHash's SPELLING is part of the preimage.** The derivation hashes the id *as a string*, so
+ * `0x7f83…` and `7f83…` are different challenge ids with different nonces. This module therefore canonicalizes
+ * to LCP's own spelling — lowercase, `0x`-prefixed, 32 bytes — before deriving OR comparing, on both the
+ * candidate and the observed nonce. An uppercase-hex spelling of the same bytes is a legal input that reaches
+ * the same nonce, not a second wire convention: it is normalized, and the vectors pin that both ways round.
+ * What is REJECTED is a value that is not 32 hex bytes at all — a missing `0x`, a wrong length, a non-hex
+ * digit. Those are different challenge ids rather than spellings of this one, and there is no canonical form
+ * to map them to.
+ *
+ * **Packed concatenation is undelimited, and the fixed length is what makes that safe.** `('ab','c')` and
+ * `('a','bc')` pack identically; the vectors pin that as an observed property of the host rule. It is
+ * unreachable for this binding because `challenge.id` is always exactly 66 characters, so no other split of
+ * the preimage produces a legal id. The length check below is therefore load-bearing, not defensive noise.
+ *
+ * **NOTHING HERE RECOVERS AN atrHash, and no future edit may add such a path.** keccak-256 has no inverse:
+ * the honest surface is confirmation of a candidate the auditor already holds. Re-deriving from a stored
+ * challenge would be service-record recovery wearing the name of zero-party recovery, and would falsify
+ * `zeroPartyRecoverable: false` in the manifest.
+ */
+import { canonicalAtrHash } from "@integraledger/lcp-kernel";
+import { concat, keccak256, stringToBytes } from "viem";
+/** A 32-byte value in the canonical lowercase-`0x` spelling this binding hashes and compares. */
+const BYTES32 = /^0x[0-9a-fA-F]{64}$/;
+/**
+ * MPP's derivation, exactly as its EVM method specifies it: `keccak256(abi.encodePacked(id, realm))`.
+ *
+ * Total over any two non-empty strings, because it implements MPP's rule and not an LCP-specific one — an
+ * ordinary opaque challenge id derives here too, which is what makes this the host's function rather than
+ * ours. THROWS on an empty id or realm: MPP requires both on every challenge (`realm` is a MUST per
+ * §5.1.1), so an empty one is a wiring defect in the caller, not a value to hash.
+ */
+export function deriveChallengeHash(challengeId, realm) {
+    if (challengeId === "")
+        throw new Error("MPP challenge id must be non-empty — it is half the nonce preimage");
+    if (realm === "")
+        throw new Error("MPP realm must be non-empty — the core scheme makes realm a MUST on every challenge, and it is half the nonce preimage");
+    return keccak256(concat([stringToBytes(challengeId), stringToBytes(realm)]));
+}
+/**
+ * The Id-Reuse weld at PROPOSAL time: `challenge.id = atrHash`, and the nonce that follows from it.
+ *
+ * THROWS on a malformed atrHash, via `canonicalAtrHash` — a seller welding a hash that is not 32 bytes is a
+ * wiring defect, and the guard is also what keeps the fixed-length argument above true of the code.
+ *
+ * **Do not reach for `binding-evm-common`'s `assertBytes32` here.** It enforces the same 32 bytes but
+ * explains them as the value that will "ride as the EIP-3009 nonce" — true on x402, false on this rail, and
+ * precisely the cross-rail misreading `binding-evm-x402`'s KNOWN-BAD note exists to stop. On MPP-EVM the
+ * atrHash rides `challenge.id` and the nonce is DERIVED from it, never occupied by it. `canonicalAtrHash`
+ * states the shape requirement and nothing about where the value rides, which is why it is the right guard:
+ * the rail-specific reasoning belongs in this docblock and in the manifest, not in an error string.
+ */
+export function bindAtrHash(atrHash, realm) {
+    const challengeId = canonicalAtrHash(atrHash, "bindAtrHash", "on this rail it rides challenge.id and the EIP-3009 nonce is DERIVED from it (draft-evm-charge-00 §5.3.1), never occupied by it");
+    return { challengeId, realm, nonce: deriveChallengeHash(challengeId, realm) };
+}
+/**
+ * Confirm a candidate atrHash against the `AuthorizationUsed` nonces ONE settlement emitted.
+ *
+ * The auditor brings the atrHash (from the record, or from `legal-context.json`); the chain confirms it.
+ * Refusals rather than throws, because both the candidate and the observed nonces are data under audit —
+ * the realm is not: it is the verifier's own configuration, so an empty one throws.
+ *
+ * Every observed nonce is validated BEFORE any is matched: a malformed entry refuses loudly instead of being
+ * skipped past, because silently narrowing a settlement view could turn "this transaction is not what you
+ * think" into "no match found".
+ */
+export function checkCandidate(atrHash, realm, observedNonces) {
+    if (!BYTES32.test(atrHash))
+        return {
+            refused: true,
+            haltClass: "verification-failure",
+            code: "mpp-evm/candidate-malformed",
+            detail: `a candidate atrHash must be a 0x-prefixed 32-byte value to be a legal MPP challenge id, got "${atrHash}"`,
+        };
+    for (const observed of observedNonces)
+        if (!BYTES32.test(observed))
+            return {
+                refused: true,
+                haltClass: "verification-failure",
+                code: "mpp-evm/nonce-malformed",
+                detail: `an observed EIP-3009 nonce must be a 0x-prefixed 32-byte value, got "${observed}"`,
+            };
+    if (observedNonces.length === 0)
+        return {
+            refused: true,
+            haltClass: "verification-failure",
+            code: "mpp-evm/no-settlement-event",
+            detail: "no EIP-3009 AuthorizationUsed nonce was observed for this settlement — there is nothing to verify against",
+        };
+    const candidate = canonicalAtrHash(atrHash, "checkCandidate");
+    const nonce = deriveChallengeHash(candidate, realm);
+    const matched = observedNonces.find((o) => o.toLowerCase() === nonce);
+    if (matched === undefined)
+        return {
+            refused: true,
+            haltClass: "verification-failure",
+            code: "mpp-evm/candidate-mismatch",
+            detail: `no observed nonce equals keccak256(packed("${candidate}", "${realm}")) = ${nonce}`,
+        };
+    return {
+        ok: true,
+        value: { confirmed: true, atrHash: candidate, realm, nonce },
+    };
+}
+/**
+ * The refusal recovery always returns, stated in one place so the reason travels with the code.
+ *
+ * Not a "not implemented yet" and not a gap to be filled: the on-chain value is a hash over the atrHash, so
+ * there is no function from settlement to atrHash to write. A caller wanting the record must bring the
+ * candidate and use `verifyCandidate`.
+ */
+export function notRecoverableByConstruction() {
+    return {
+        refused: true,
+        haltClass: "verification-failure",
+        code: "mpp-evm/not-recoverable-by-construction",
+        detail: "MPP-EVM is an Id-Reuse binding (LCP §8.3.5): the on-chain EIP-3009 nonce is keccak256 over the atrHash and the realm, so no atrHash can be recovered from a settlement — bring the candidate atrHash and use verifyCandidate",
+    };
+}
+//# sourceMappingURL=id-reuse.js.map

package/dist/id-reuse.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"id-reuse.js","sourceRoot":"","sources":["../src/id-reuse.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgEG;AAGH,OAAO,EAAE,gBAAgB,EAAE,MAAM,2BAA2B,CAAC;AAC7D,OAAO,EAAE,MAAM,EAAY,SAAS,EAAE,aAAa,EAAE,MAAM,MAAM,CAAC;AAElE,iGAAiG;AACjG,MAAM,OAAO,GAAG,qBAAqB,CAAC;AAuBtC;;;;;;;GAOG;AACH,MAAM,UAAU,mBAAmB,CAAC,WAAmB,EAAE,KAAa;IACpE,IAAI,WAAW,KAAK,EAAE;QACpB,MAAM,IAAI,KAAK,CACb,oEAAoE,CACrE,CAAC;IACJ,IAAI,KAAK,KAAK,EAAE;QACd,MAAM,IAAI,KAAK,CACb,wHAAwH,CACzH,CAAC;IACJ,OAAO,SAAS,CAAC,MAAM,CAAC,CAAC,aAAa,CAAC,WAAW,CAAC,EAAE,aAAa,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC;AAC/E,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,WAAW,CACzB,OAAe,EACf,KAAa;IAEb,MAAM,WAAW,GAAG,gBAAgB,CAClC,OAAO,EACP,aAAa,EACb,iIAAiI,CAC3H,CAAC;IACT,OAAO,EAAE,WAAW,EAAE,KAAK,EAAE,KAAK,EAAE,mBAAmB,CAAC,WAAW,EAAE,KAAK,CAAC,EAAE,CAAC;AAChF,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,cAAc,CAC5B,OAAe,EACf,KAAa,EACb,cAAiC;IAEjC,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,OAAO,CAAC;QACxB,OAAO;YACL,OAAO,EAAE,IAAI;YACb,SAAS,EAAE,sBAAsB;YACjC,IAAI,EAAE,6BAA6B;YACnC,MAAM,EAAE,gGAAgG,OAAO,GAAG;SACnH,CAAC;IACJ,KAAK,MAAM,QAAQ,IAAI,cAAc;QACnC,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,QAAQ,CAAC;YACzB,OAAO;gBACL,OAAO,EAAE,IAAI;gBACb,SAAS,EAAE,sBAAsB;gBACjC,IAAI,EAAE,yBAAyB;gBAC/B,MAAM,EAAE,wEAAwE,QAAQ,GAAG;aAC5F,CAAC;IACN,IAAI,cAAc,CAAC,MAAM,KAAK,CAAC;QAC7B,OAAO;YACL,OAAO,EAAE,IAAI;YACb,SAAS,EAAE,sBAAsB;YACjC,IAAI,EAAE,6BAA6B;YACnC,MAAM,EACJ,2GAA2G;SAC9G,CAAC;IACJ,MAAM,SAAS,GAAG,gBAAgB,CAAC,OAAO,EAAE,gBAAgB,CAAQ,CAAC;IACrE,MAAM,KAAK,GAAG,mBAAmB,CAAC,SAAS,EAAE,KAAK,CAAC,CAAC;IACpD,MAAM,OAAO,GAAG,cAAc,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,WAAW,EAAE,KAAK,KAAK,CAAC,CAAC;IACtE,IAAI,OAAO,KAAK,SAAS;QACvB,OAAO;YACL,OAAO,EAAE,IAAI;YACb,SAAS,EAAE,sBAAsB;YACjC,IAAI,EAAE,4BAA4B;YAClC,MAAM,EAAE,8CAA8C,SAAS,OAAO,KAAK,SAAS,KAAK,EAAE;SAC5F,CAAC;IACJ,OAAO;QACL,EAAE,EAAE,IAAI;QACR,KAAK,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,KAAK,EAAE;KAC7D,CAAC;AACJ,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,OAAO,EAAE,IAAI;QACb,SAAS,EAAE,sBAAsB;QACjC,IAAI,EAAE,yCAAyC;QAC/C,MAAM,EACJ,8NAA8N;KACjO,CAAC;AACJ,CAAC"}

package/dist/index.d.ts

@@ -0,0 +1,5 @@
+export { createMppEvmAdapter, type MppEvmAdapter, type MppEvmAdapterConfig, } from "./adapter.js";
+export { notAuthorizationCredentialType } from "./credential-type.js";
+export { bindAtrHash, checkCandidate, deriveChallengeHash, type MppEvmCandidateConfirmation, type MppEvmChallengeBinding, notRecoverableByConstruction, } from "./id-reuse.js";
+export { MPP_EVM_MANIFEST } from "./manifest.js";
+//# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,mBAAmB,EACnB,KAAK,aAAa,EAClB,KAAK,mBAAmB,GACzB,MAAM,cAAc,CAAC;AAItB,OAAO,EAAE,8BAA8B,EAAE,MAAM,sBAAsB,CAAC;AACtE,OAAO,EACL,WAAW,EACX,cAAc,EACd,mBAAmB,EACnB,KAAK,2BAA2B,EAChC,KAAK,sBAAsB,EAC3B,4BAA4B,GAC7B,MAAM,eAAe,CAAC;AACvB,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC"}

package/dist/index.js

@@ -0,0 +1,8 @@
+export { createMppEvmAdapter, } from "./adapter.js";
+// `assetWasTransferred` and `ERC20_TRANSFER_TOPIC0` moved to `@integraledger/lcp-binding-evm-common` when
+// binding-evm-x402 needed the same predicate. They are NOT re-exported from here: a symbol with two homes
+// is how the two copies drift, which is the thing the move was for.
+export { notAuthorizationCredentialType } from "./credential-type.js";
+export { bindAtrHash, checkCandidate, deriveChallengeHash, notRecoverableByConstruction, } from "./id-reuse.js";
+export { MPP_EVM_MANIFEST } from "./manifest.js";
+//# sourceMappingURL=index.js.map

package/dist/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,mBAAmB,GAGpB,MAAM,cAAc,CAAC;AACtB,0GAA0G;AAC1G,0GAA0G;AAC1G,oEAAoE;AACpE,OAAO,EAAE,8BAA8B,EAAE,MAAM,sBAAsB,CAAC;AACtE,OAAO,EACL,WAAW,EACX,cAAc,EACd,mBAAmB,EAGnB,4BAA4B,GAC7B,MAAM,eAAe,CAAC;AACvB,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC"}

package/dist/manifest.d.ts

@@ -0,0 +1,66 @@
+import type { BindingManifest } from "@integraledger/lcp-binding-core";
+/**
+ * The MPP-EVM Id-Reuse binding manifest (published as `mpp-evm-derived-v1`).
+ *
+ * **pattern = "id-reuse"** (LCP §8.3.5), and this is the one member of the family that differs *at the
+ * weld*. On MPP's EVM charge method the EIP-3009 nonce is not ours to occupy: `draft-evm-charge-00` §5.3.1
+ * REQUIRES `nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm))`, and §5.2.3 fixes the
+ * Permit2 witness type string with a MUST ("Implementations MUST use the exact type string above"). There is
+ * no free field on this path. What remains available is Id-Reuse: the seller sets `challenge.id = atrHash`,
+ * so the host's own derivation carries the record into the settlement transaction.
+ *
+ * **Do NOT reconcile this manifest against `binding-evm-x402`'s.** That package's docblock records an
+ * archived declaration marked KNOWN-BAD for reading MPP-EVM's derivation-MUST onto the x402 path, where no
+ * derivation exists. This is where that reading is correct, and the two manifests legitimately differ: x402
+ * is off-canonical Native Field on the same nonce field, MPP-EVM is Id-Reuse over a derivation. "Fixing" one
+ * to look like the other reintroduces the bug the archive comment exists to stop.
+ *
+ * **`nativeField` is absent, and its absence is substantive** — not merely the schema's `iff`. Nothing of
+ * ours occupies a protocol field here; the atrHash rides an identifier the host protocol already requires.
+ *
+ * **SCOPE — this manifest declares ONE of MPP's four credential types, and the scope is load-bearing.**
+ * `draft-evm-charge-00` defines four ways a client may present payment, and the derived `challengeHash`
+ * reaches the chain in exactly one of them:
+ * - **§5.3 `authorization`** — the derived value IS the EIP-3009 nonce, so it is committed on-chain. Opt-in
+ *   and token-conditional: §4.2.2 "Servers MUST only include `"authorization"` when the `currency` token is
+ *   known to implement EIP-3009", and §5.3.2 the same rule as a prohibition ("Servers MUST NOT advertise
+ *   `"authorization"` in `credentialTypes` unless the `currency` token is known to implement EIP-3009").
+ *   **This is the credential type this binding covers, and the only one it can.**
+ * - **§5.2 `permit2`** — "The RECOMMENDED credential type", and it carries the SAME derived `challengeHash`
+ *   inside the EIP-712 `PaymentWitness` struct, which the client signs but which never appears in calldata or
+ *   an event log; §10.4 places it "in the EIP-712 witness data (Permit2)". Signature-committed, off-chain,
+ *   unreadable from a settlement.
+ * - **§5.4 `transaction`** and **§5.5 `hash`** — plain ERC-20 transfers. No challengeHash anywhere; §10.4
+ *   says so outright ("weaker challenge binding than Permit2 credentials").
+ *
+ * So `weldGrades` is keyed by MPP's own credential-type name rather than by a coinage like `derived`: the key
+ * IS the scope, machine-readably, and `finality.note` repeats it in prose for whoever reads only the published
+ * profile JSON. A grade for `permit2` would be declared from the specification rather than from this binding —
+ * the package constructs no witness — and `transaction`/`hash` have no weld to grade. Generalizing the
+ * strongest leg to the whole rail is the failure this scoping exists to prevent, and the adapter enforces the
+ * same scope at runtime: a settlement that moved the token without an `AuthorizationUsed` beside it is refused
+ * by credential type, never reported as an absence of settlement.
+ *
+ * **The WLD-3 triple, under that scope:**
+ * - `onChain: true` — the derived value is the EIP-3009 nonce, emitted as an indexed topic of
+ *   `AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce)` and consumed on-chain by the
+ *   token contract (§8: "The nonce is consumed on-chain by the token contract itself"). **Read from the host
+ *   specification and from the adapter's own behaviour on synthetic logs; NOT yet from a live MPP-EVM
+ *   settlement** — the repository's opt-in on-chain integration suite discharges that against a real transaction, and until
+ *   it runs, this member is the one still owed a live proof.
+ * - `zeroPartyRecoverable: false` — keccak-256 has no inverse. An auditor holding only the transaction hash
+ *   reads the nonce and cannot obtain the atrHash from it. Verification of a *candidate* is the whole of
+ *   what this rail offers, which is why the adapter exposes `verifyCandidate` and why `recover` refuses.
+ *   Observed of the code: no member maps a settlement to an atrHash, and `recover` takes no arguments.
+ * - `forwardIndexable: false` — §8.3's criterion is enumeration "bound to a given `atrHash`", and §8.3.5
+ *   states it directly: "Not forward-indexable by `atrHash` alone — the on-chain value is a hash over
+ *   `atrHash` and other inputs." Knowing the realm as well, one *could* derive the nonce and topic-filter it,
+ *   but that is realm-scoped, and it is degenerate besides: §8.3.5's uniqueness satisfaction makes each ATR
+ *   unique per transaction, so there is at most one settlement per atrHash to enumerate. Hence `indexing:
+ *   "none"` and no `enumerate` member. Observed of the code: no `enumerate` exists to call.
+ *
+ * `weldGrades.authorization = "signature"`: the payer's EIP-3009 typed-data message covers the `nonce` field,
+ * so the buyer's signature — not merely an inclusion in a transaction — commits the derived value.
+ */
+export declare const MPP_EVM_MANIFEST: BindingManifest;
+//# sourceMappingURL=manifest.d.ts.map

package/dist/manifest.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"manifest.d.ts","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,iCAAiC,CAAC;AAEvE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8DG;AACH,eAAO,MAAM,gBAAgB,EAAE,eAkB9B,CAAC"}

package/dist/manifest.js

@@ -0,0 +1,83 @@
+/**
+ * The MPP-EVM Id-Reuse binding manifest (published as `mpp-evm-derived-v1`).
+ *
+ * **pattern = "id-reuse"** (LCP §8.3.5), and this is the one member of the family that differs *at the
+ * weld*. On MPP's EVM charge method the EIP-3009 nonce is not ours to occupy: `draft-evm-charge-00` §5.3.1
+ * REQUIRES `nonce = keccak256(abi.encodePacked(challenge.id, challenge.realm))`, and §5.2.3 fixes the
+ * Permit2 witness type string with a MUST ("Implementations MUST use the exact type string above"). There is
+ * no free field on this path. What remains available is Id-Reuse: the seller sets `challenge.id = atrHash`,
+ * so the host's own derivation carries the record into the settlement transaction.
+ *
+ * **Do NOT reconcile this manifest against `binding-evm-x402`'s.** That package's docblock records an
+ * archived declaration marked KNOWN-BAD for reading MPP-EVM's derivation-MUST onto the x402 path, where no
+ * derivation exists. This is where that reading is correct, and the two manifests legitimately differ: x402
+ * is off-canonical Native Field on the same nonce field, MPP-EVM is Id-Reuse over a derivation. "Fixing" one
+ * to look like the other reintroduces the bug the archive comment exists to stop.
+ *
+ * **`nativeField` is absent, and its absence is substantive** — not merely the schema's `iff`. Nothing of
+ * ours occupies a protocol field here; the atrHash rides an identifier the host protocol already requires.
+ *
+ * **SCOPE — this manifest declares ONE of MPP's four credential types, and the scope is load-bearing.**
+ * `draft-evm-charge-00` defines four ways a client may present payment, and the derived `challengeHash`
+ * reaches the chain in exactly one of them:
+ * - **§5.3 `authorization`** — the derived value IS the EIP-3009 nonce, so it is committed on-chain. Opt-in
+ *   and token-conditional: §4.2.2 "Servers MUST only include `"authorization"` when the `currency` token is
+ *   known to implement EIP-3009", and §5.3.2 the same rule as a prohibition ("Servers MUST NOT advertise
+ *   `"authorization"` in `credentialTypes` unless the `currency` token is known to implement EIP-3009").
+ *   **This is the credential type this binding covers, and the only one it can.**
+ * - **§5.2 `permit2`** — "The RECOMMENDED credential type", and it carries the SAME derived `challengeHash`
+ *   inside the EIP-712 `PaymentWitness` struct, which the client signs but which never appears in calldata or
+ *   an event log; §10.4 places it "in the EIP-712 witness data (Permit2)". Signature-committed, off-chain,
+ *   unreadable from a settlement.
+ * - **§5.4 `transaction`** and **§5.5 `hash`** — plain ERC-20 transfers. No challengeHash anywhere; §10.4
+ *   says so outright ("weaker challenge binding than Permit2 credentials").
+ *
+ * So `weldGrades` is keyed by MPP's own credential-type name rather than by a coinage like `derived`: the key
+ * IS the scope, machine-readably, and `finality.note` repeats it in prose for whoever reads only the published
+ * profile JSON. A grade for `permit2` would be declared from the specification rather than from this binding —
+ * the package constructs no witness — and `transaction`/`hash` have no weld to grade. Generalizing the
+ * strongest leg to the whole rail is the failure this scoping exists to prevent, and the adapter enforces the
+ * same scope at runtime: a settlement that moved the token without an `AuthorizationUsed` beside it is refused
+ * by credential type, never reported as an absence of settlement.
+ *
+ * **The WLD-3 triple, under that scope:**
+ * - `onChain: true` — the derived value is the EIP-3009 nonce, emitted as an indexed topic of
+ *   `AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce)` and consumed on-chain by the
+ *   token contract (§8: "The nonce is consumed on-chain by the token contract itself"). **Read from the host
+ *   specification and from the adapter's own behaviour on synthetic logs; NOT yet from a live MPP-EVM
+ *   settlement** — the repository's opt-in on-chain integration suite discharges that against a real transaction, and until
+ *   it runs, this member is the one still owed a live proof.
+ * - `zeroPartyRecoverable: false` — keccak-256 has no inverse. An auditor holding only the transaction hash
+ *   reads the nonce and cannot obtain the atrHash from it. Verification of a *candidate* is the whole of
+ *   what this rail offers, which is why the adapter exposes `verifyCandidate` and why `recover` refuses.
+ *   Observed of the code: no member maps a settlement to an atrHash, and `recover` takes no arguments.
+ * - `forwardIndexable: false` — §8.3's criterion is enumeration "bound to a given `atrHash`", and §8.3.5
+ *   states it directly: "Not forward-indexable by `atrHash` alone — the on-chain value is a hash over
+ *   `atrHash` and other inputs." Knowing the realm as well, one *could* derive the nonce and topic-filter it,
+ *   but that is realm-scoped, and it is degenerate besides: §8.3.5's uniqueness satisfaction makes each ATR
+ *   unique per transaction, so there is at most one settlement per atrHash to enumerate. Hence `indexing:
+ *   "none"` and no `enumerate` member. Observed of the code: no `enumerate` exists to call.
+ *
+ * `weldGrades.authorization = "signature"`: the payer's EIP-3009 typed-data message covers the `nonce` field,
+ * so the buyer's signature — not merely an inclusion in a transaction — commits the derived value.
+ */
+export const MPP_EVM_MANIFEST = {
+    rail: "evm:mpp",
+    protocol: "mpp",
+    pattern: "id-reuse",
+    recovery: {
+        onChain: true,
+        zeroPartyRecoverable: false,
+        forwardIndexable: false,
+    },
+    assetBinding: "filtered", // candidate verification filters the configured token's own log (AuthorizationUsed / assetWasTransferred)
+    successGate: "structural", // a reverted tx emits no logs, so the weld event cannot exist
+    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",
+    },
+    weldGrades: { authorization: "signature" },
+    lifecycleStates: ["proposed", "settled"],
+};
+//# sourceMappingURL=manifest.js.map

package/dist/manifest.js.map

@@ -0,0 +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"}

package/package.json

@@ -0,0 +1,63 @@
+{
+  "name": "@integraledger/lcp-binding-evm-mpp",
+  "version": "0.9.0",
+  "description": "Welds an LCP record into an MPP settlement on EVM by Id-Reuse (LCP §8.3.5).",
+  "keywords": [
+    "lcp",
+    "legal-context-protocol",
+    "legal-terms",
+    "agentic-commerce",
+    "settlement",
+    "atr-hash",
+    "evm",
+    "mpp"
+  ],
+  "type": "module",
+  "sideEffects": false,
+  "exports": {
+    ".": {
+      "types": "./dist/index.d.ts",
+      "default": "./dist/index.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "files": [
+    "dist",
+    "src",
+    "CHANGELOG.md",
+    "LICENSE",
+    "NOTICE"
+  ],
+  "publishConfig": {
+    "registry": "https://registry.npmjs.org",
+    "access": "public"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/IntegraLedger/integra-protocol.git",
+    "directory": "packages/binding-evm-mpp"
+  },
+  "bugs": {
+    "url": "https://github.com/IntegraLedger/integra-protocol/issues"
+  },
+  "homepage": "https://github.com/IntegraLedger/integra-protocol/tree/main/packages/binding-evm-mpp#readme",
+  "dependencies": {
+    "viem": "2.55.11",
+    "@integraledger/lcp-binding-core": "0.9.0",
+    "@integraledger/lcp-binding-evm-common": "0.9.0",
+    "@integraledger/lcp-kernel": "0.9.0"
+  },
+  "devDependencies": {
+    "@types/node": "24.13.3",
+    "vitest": "4.1.10"
+  },
+  "license": "Apache-2.0",
+  "engines": {
+    "node": ">=24"
+  },
+  "scripts": {
+    "build": "tsc -p tsconfig.build.json",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "test": "vitest run"
+  }
+}