@integraledger/lcp-binding-stellar 0.10.1 → 0.12.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (7) hide show
  1. package/CHANGELOG.md +43 -0
  2. package/dist/manifest.d.ts +39 -11
  3. package/dist/manifest.d.ts.map +1 -1
  4. package/dist/manifest.js +39 -11
  5. package/dist/manifest.js.map +1 -1
  6. package/package.json +3 -3
  7. package/src/manifest.ts +39 -11
package/CHANGELOG.md CHANGED
@@ -1,5 +1,48 @@
1
1
  # @integraledger/lcp-binding-stellar
2
2
 
3
+ ## 0.12.0
4
+
5
+ ### Patch Changes
6
+
7
+ - Updated dependencies
8
+ - @integraledger/lcp-kernel@0.12.0
9
+ - @integraledger/lcp-binding-core@0.12.0
10
+
11
+ ## 0.10.2
12
+
13
+ ### Patch Changes
14
+
15
+ - 1d892dc: Correct the Stellar manifest's account of its relationship to x402.
16
+
17
+ The docblock claimed this binding welds into a CLASSIC Stellar payment, that x402's `exact` scheme for
18
+ Stellar was "a different flow entirely", and that "a deployment settling through an x402-Stellar facilitator
19
+ does not get this carrier". Every step of that was wrong, and it contradicted the same file: `finality.note`
20
+ says "Soroban SAC transfer", the paragraph above it says the buyer signs the Soroban SAC `transfer`, and
21
+ `adapter.ts` types the field it reads as "the `to` destination of the SAC transfer". There was never a
22
+ classic payment here to mux.
23
+
24
+ Re-read against the live sources: x402's exact-Stellar scheme is Soroban SEP-41 token transfers —
25
+ `invokeHostFunction` calling `transfer(from, to, amount)`, the same operation this binding welds into. Its
26
+ only rule on the destination is that argument 1 must equal `requirements.payTo` exactly, and it places no
27
+ format constraint on `payTo` anywhere, so a seller advertising their `M…` address satisfies it by
28
+ construction. And CAP-67 exists precisely to permit this: it adds `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and
29
+ allows the SAC to take that type in `transfer`.
30
+
31
+ What IS limited is narrower and different, and is now what the docblock states: CAP-67 extended the SAC, not
32
+ Soroban generally. `MuxedAddressObject` "is not implicitly compatible with `AddressObject`", so a custom
33
+ SEP-41 token contract rejects a muxed `to` and the invocation fails rather than degrading. The carrier is
34
+ therefore available through x402 when, and only when, the scheme's `asset` is the SAC.
35
+
36
+ No manifest field changed — `protocol` stays absent, but now because the carrier genuinely serves bare
37
+ Soroban and x402 alike rather than because x402 could not reach it. Two facts are explicitly left unclaimed
38
+ because they were not verified: whether a given facilitator independently rejects an `M…` `payTo`, and
39
+ CAP-67's activation status on any particular network.
40
+
41
+ - Updated dependencies [b2ffecc]
42
+ - Updated dependencies [822190a]
43
+ - @integraledger/lcp-binding-core@0.11.0
44
+ - @integraledger/lcp-kernel@0.11.0
45
+
3
46
  ## 0.10.1
4
47
 
5
48
  **0.10.0 was staged and withdrawn before approval; this is that release, re-cut.** The conformance corpus
package/dist/manifest.d.ts CHANGED
@@ -16,17 +16,45 @@ import type { BindingManifest } from "@integraledger/lcp-binding-core";
16
16
  * `forwardIndexable: false` (no native index over mux prefixes; `enumerate` is a best-effort account scan,
17
17
  * `indexing: "account-scan:mux-prefix8"`). The prefix-8 truncation is stated in `finality.note` too.
18
18
  *
19
- * **NO `protocol`, and here is precisely what it is neutral OF.** This binding welds into the destination
20
- * of a CLASSIC Stellar payment. x402's `exact` scheme for Stellar (read 2026-08-08) is a different flow
21
- * entirely: "This spec covers SEP-41-compliant Soroban tokens **only**. Classic Stellar assets are not
22
- * supported", and the payment is an `invokeHostFunction` calling `transfer(from, to, amount)` where
23
- * "Argument 1 (to): MUST equal `requirements.payTo` exactly".
24
- *
25
- * A muxed destination cannot appear in that call — there is no classic payment to mux, and an `M…` address
26
- * would not equal `payTo` exactly. So a deployment settling through an x402-Stellar facilitator does not
27
- * get this carrier. That is a scoping fact, not a defect: the binding has never declared `protocol`, and
28
- * the mux weld is correct on the rail it targets. Stated here so the absence is a measured claim rather
29
- * than an unexamined default.
19
+ * **NO `protocol`, and the reason is that the carrier genuinely works on both sides — CORRECTED
20
+ * 2026-08-15.** An earlier revision of this paragraph said the opposite: that the binding welds into a
21
+ * CLASSIC Stellar payment, that x402's `exact` scheme for Stellar was "a different flow entirely", and
22
+ * that "a deployment settling through an x402-Stellar facilitator does not get this carrier". Every step of
23
+ * that was wrong, and it contradicted this same file — `finality.note` below says "Soroban SAC transfer",
24
+ * the paragraph above says the buyer signs the Soroban SAC `transfer`, and `adapter.ts` types the field it
25
+ * reads as "the `to` destination of the SAC transfer". There was never a classic payment here to mux.
26
+ *
27
+ * Re-read against the live sources on 2026-08-15:
28
+ *
29
+ * - **x402's `exact` scheme for Stellar** (`x402-foundation/x402` HEAD `167a828e8319`) is Soroban SEP-41
30
+ * token transfers — an `invokeHostFunction` calling `transfer(from, to, amount)`. That is the SAME
31
+ * operation this binding welds into, not a different flow.
32
+ * - Its only rule on the destination is "**Argument 1 (to)**: MUST equal `requirements.payTo` exactly". The
33
+ * scheme places **no format constraint on `payTo` anywhere**; its example happens to show a `G…` address,
34
+ * and an example is not a constraint. A seller advertising their `M…` address as `payTo` satisfies the
35
+ * rule by construction.
36
+ * - **CAP-67** (`stellar/stellar-protocol`, `core/cap-0067.md`) exists precisely to permit this: "Add memo
37
+ * support to Soroban by adding a `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and allow the SAC to take in this type
38
+ * in the `transfer` function call."
39
+ *
40
+ * ⛔ **What IS limited, and it is narrower and different: CAP-67 extended the SAC, not Soroban generally.**
41
+ * The same CAP: "`MuxedAddressObject` … is not implicitly compatible with `AddressObject`. Thus the
42
+ * contracts that expect the regular `AddressObject` as an input argument **will fail** if
43
+ * `ScAddress::SC_ADDRESS_TYPE_MUXED_ACCOUNT` is passed to them." So the carrier depends on which contract
44
+ * the payment invokes:
45
+ *
46
+ * - the **SAC** — the built-in contract for a classic asset — accepts a muxed `to`, and the weld rides;
47
+ * - a **custom SEP-41 token contract** rejects it, and the invocation FAILS rather than degrading.
48
+ *
49
+ * A deployment therefore gets this carrier through x402 when, and only when, the scheme's `asset` is the
50
+ * SAC. `protocol` stays absent because that is a genuine statement of neutrality — the carrier serves bare
51
+ * Soroban and x402 alike — rather than, as the earlier text had it, because x402 could not reach it.
52
+ *
53
+ * ⚠️ **Two things deliberately NOT claimed here, because they were not verified.** Whether a given x402
54
+ * facilitator independently rejects an `M…` `payTo` (the scheme does not require it to), and CAP-67's
55
+ * activation status on any particular network. Both are deployment-time facts a seller must establish for
56
+ * themselves; asserting either from this file would be the kind of unmeasured claim the correction above
57
+ * exists to remove.
30
58
  */
31
59
  export declare const STELLAR_MANIFEST: BindingManifest;
32
60
  //# sourceMappingURL=manifest.d.ts.map
package/dist/manifest.d.ts.map CHANGED
@@ -1 +1 @@
1
- {"version":3,"file":"manifest.d.ts","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,iCAAiC,CAAC;AAEvE;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AACH,eAAO,MAAM,gBAAgB,EAAE,eAkB9B,CAAC"}
1
+ {"version":3,"file":"manifest.d.ts","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,iCAAiC,CAAC;AAEvE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwDG;AACH,eAAO,MAAM,gBAAgB,EAAE,eAkB9B,CAAC"}
package/dist/manifest.js CHANGED
@@ -15,17 +15,45 @@
15
15
  * `forwardIndexable: false` (no native index over mux prefixes; `enumerate` is a best-effort account scan,
16
16
  * `indexing: "account-scan:mux-prefix8"`). The prefix-8 truncation is stated in `finality.note` too.
17
17
  *
18
- * **NO `protocol`, and here is precisely what it is neutral OF.** This binding welds into the destination
19
- * of a CLASSIC Stellar payment. x402's `exact` scheme for Stellar (read 2026-08-08) is a different flow
20
- * entirely: "This spec covers SEP-41-compliant Soroban tokens **only**. Classic Stellar assets are not
21
- * supported", and the payment is an `invokeHostFunction` calling `transfer(from, to, amount)` where
22
- * "Argument 1 (to): MUST equal `requirements.payTo` exactly".
23
- *
24
- * A muxed destination cannot appear in that call — there is no classic payment to mux, and an `M…` address
25
- * would not equal `payTo` exactly. So a deployment settling through an x402-Stellar facilitator does not
26
- * get this carrier. That is a scoping fact, not a defect: the binding has never declared `protocol`, and
27
- * the mux weld is correct on the rail it targets. Stated here so the absence is a measured claim rather
28
- * than an unexamined default.
18
+ * **NO `protocol`, and the reason is that the carrier genuinely works on both sides — CORRECTED
19
+ * 2026-08-15.** An earlier revision of this paragraph said the opposite: that the binding welds into a
20
+ * CLASSIC Stellar payment, that x402's `exact` scheme for Stellar was "a different flow entirely", and
21
+ * that "a deployment settling through an x402-Stellar facilitator does not get this carrier". Every step of
22
+ * that was wrong, and it contradicted this same file — `finality.note` below says "Soroban SAC transfer",
23
+ * the paragraph above says the buyer signs the Soroban SAC `transfer`, and `adapter.ts` types the field it
24
+ * reads as "the `to` destination of the SAC transfer". There was never a classic payment here to mux.
25
+ *
26
+ * Re-read against the live sources on 2026-08-15:
27
+ *
28
+ * - **x402's `exact` scheme for Stellar** (`x402-foundation/x402` HEAD `167a828e8319`) is Soroban SEP-41
29
+ * token transfers — an `invokeHostFunction` calling `transfer(from, to, amount)`. That is the SAME
30
+ * operation this binding welds into, not a different flow.
31
+ * - Its only rule on the destination is "**Argument 1 (to)**: MUST equal `requirements.payTo` exactly". The
32
+ * scheme places **no format constraint on `payTo` anywhere**; its example happens to show a `G…` address,
33
+ * and an example is not a constraint. A seller advertising their `M…` address as `payTo` satisfies the
34
+ * rule by construction.
35
+ * - **CAP-67** (`stellar/stellar-protocol`, `core/cap-0067.md`) exists precisely to permit this: "Add memo
36
+ * support to Soroban by adding a `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and allow the SAC to take in this type
37
+ * in the `transfer` function call."
38
+ *
39
+ * ⛔ **What IS limited, and it is narrower and different: CAP-67 extended the SAC, not Soroban generally.**
40
+ * The same CAP: "`MuxedAddressObject` … is not implicitly compatible with `AddressObject`. Thus the
41
+ * contracts that expect the regular `AddressObject` as an input argument **will fail** if
42
+ * `ScAddress::SC_ADDRESS_TYPE_MUXED_ACCOUNT` is passed to them." So the carrier depends on which contract
43
+ * the payment invokes:
44
+ *
45
+ * - the **SAC** — the built-in contract for a classic asset — accepts a muxed `to`, and the weld rides;
46
+ * - a **custom SEP-41 token contract** rejects it, and the invocation FAILS rather than degrading.
47
+ *
48
+ * A deployment therefore gets this carrier through x402 when, and only when, the scheme's `asset` is the
49
+ * SAC. `protocol` stays absent because that is a genuine statement of neutrality — the carrier serves bare
50
+ * Soroban and x402 alike — rather than, as the earlier text had it, because x402 could not reach it.
51
+ *
52
+ * ⚠️ **Two things deliberately NOT claimed here, because they were not verified.** Whether a given x402
53
+ * facilitator independently rejects an `M…` `payTo` (the scheme does not require it to), and CAP-67's
54
+ * activation status on any particular network. Both are deployment-time facts a seller must establish for
55
+ * themselves; asserting either from this file would be the kind of unmeasured claim the correction above
56
+ * exists to remove.
29
57
  */
30
58
  export const STELLAR_MANIFEST = {
31
59
  rail: "stellar",
package/dist/manifest.js.map CHANGED
@@ -1 +1 @@
1
- {"version":3,"file":"manifest.js","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA4BG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAoB;IAC/C,IAAI,EAAE,SAAS;IACf,OAAO,EAAE,cAAc;IACvB,WAAW,EAAE,cAAc;IAC3B,QAAQ,EAAE;QACR,OAAO,EAAE,IAAI;QACb,oBAAoB,EAAE,KAAK;QAC3B,gBAAgB,EAAE,KAAK;KACxB;IACD,YAAY,EAAE,MAAM,EAAE,2FAA2F;IACjH,WAAW,EAAE,WAAW,EAAE,wEAAwE;IAClG,QAAQ,EAAE,0BAA0B;IACpC,QAAQ,EAAE;QACR,UAAU,EAAE,KAAK;QACjB,IAAI,EAAE,0VAA0V;KACjW;IACD,UAAU,EAAE,EAAE,WAAW,EAAE,WAAW,EAAE;IACxC,eAAe,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;CACzC,CAAC"}
1
+ {"version":3,"file":"manifest.js","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwDG;AACH,MAAM,CAAC,MAAM,gBAAgB,GAAoB;IAC/C,IAAI,EAAE,SAAS;IACf,OAAO,EAAE,cAAc;IACvB,WAAW,EAAE,cAAc;IAC3B,QAAQ,EAAE;QACR,OAAO,EAAE,IAAI;QACb,oBAAoB,EAAE,KAAK;QAC3B,gBAAgB,EAAE,KAAK;KACxB;IACD,YAAY,EAAE,MAAM,EAAE,2FAA2F;IACjH,WAAW,EAAE,WAAW,EAAE,wEAAwE;IAClG,QAAQ,EAAE,0BAA0B;IACpC,QAAQ,EAAE;QACR,UAAU,EAAE,KAAK;QACjB,IAAI,EAAE,0VAA0V;KACjW;IACD,UAAU,EAAE,EAAE,WAAW,EAAE,WAAW,EAAE;IACxC,eAAe,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;CACzC,CAAC"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@integraledger/lcp-binding-stellar",
3
- "version": "0.10.1",
3
+ "version": "0.12.0",
4
4
  "description": "Welds an ATR hash into a Stellar payment.",
5
5
  "keywords": [
6
6
  "lcp",
@@ -42,8 +42,8 @@
42
42
  "homepage": "https://github.com/IntegraLedger/integra-protocol/tree/main/packages/binding-stellar#readme",
43
43
  "dependencies": {
44
44
  "@stellar/stellar-sdk": "16.2.0",
45
- "@integraledger/lcp-binding-core": "0.10.1",
46
- "@integraledger/lcp-kernel": "0.10.1"
45
+ "@integraledger/lcp-binding-core": "0.12.0",
46
+ "@integraledger/lcp-kernel": "0.12.0"
47
47
  },
48
48
  "devDependencies": {
49
49
  "@types/json-schema": "7.0.15",
package/src/manifest.ts CHANGED
@@ -17,17 +17,45 @@ import type { BindingManifest } from "@integraledger/lcp-binding-core";
17
17
  * `forwardIndexable: false` (no native index over mux prefixes; `enumerate` is a best-effort account scan,
18
18
  * `indexing: "account-scan:mux-prefix8"`). The prefix-8 truncation is stated in `finality.note` too.
19
19
  *
20
- * **NO `protocol`, and here is precisely what it is neutral OF.** This binding welds into the destination
21
- * of a CLASSIC Stellar payment. x402's `exact` scheme for Stellar (read 2026-08-08) is a different flow
22
- * entirely: "This spec covers SEP-41-compliant Soroban tokens **only**. Classic Stellar assets are not
23
- * supported", and the payment is an `invokeHostFunction` calling `transfer(from, to, amount)` where
24
- * "Argument 1 (to): MUST equal `requirements.payTo` exactly".
25
- *
26
- * A muxed destination cannot appear in that call — there is no classic payment to mux, and an `M…` address
27
- * would not equal `payTo` exactly. So a deployment settling through an x402-Stellar facilitator does not
28
- * get this carrier. That is a scoping fact, not a defect: the binding has never declared `protocol`, and
29
- * the mux weld is correct on the rail it targets. Stated here so the absence is a measured claim rather
30
- * than an unexamined default.
20
+ * **NO `protocol`, and the reason is that the carrier genuinely works on both sides — CORRECTED
21
+ * 2026-08-15.** An earlier revision of this paragraph said the opposite: that the binding welds into a
22
+ * CLASSIC Stellar payment, that x402's `exact` scheme for Stellar was "a different flow entirely", and
23
+ * that "a deployment settling through an x402-Stellar facilitator does not get this carrier". Every step of
24
+ * that was wrong, and it contradicted this same file — `finality.note` below says "Soroban SAC transfer",
25
+ * the paragraph above says the buyer signs the Soroban SAC `transfer`, and `adapter.ts` types the field it
26
+ * reads as "the `to` destination of the SAC transfer". There was never a classic payment here to mux.
27
+ *
28
+ * Re-read against the live sources on 2026-08-15:
29
+ *
30
+ * - **x402's `exact` scheme for Stellar** (`x402-foundation/x402` HEAD `167a828e8319`) is Soroban SEP-41
31
+ * token transfers — an `invokeHostFunction` calling `transfer(from, to, amount)`. That is the SAME
32
+ * operation this binding welds into, not a different flow.
33
+ * - Its only rule on the destination is "**Argument 1 (to)**: MUST equal `requirements.payTo` exactly". The
34
+ * scheme places **no format constraint on `payTo` anywhere**; its example happens to show a `G…` address,
35
+ * and an example is not a constraint. A seller advertising their `M…` address as `payTo` satisfies the
36
+ * rule by construction.
37
+ * - **CAP-67** (`stellar/stellar-protocol`, `core/cap-0067.md`) exists precisely to permit this: "Add memo
38
+ * support to Soroban by adding a `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and allow the SAC to take in this type
39
+ * in the `transfer` function call."
40
+ *
41
+ * ⛔ **What IS limited, and it is narrower and different: CAP-67 extended the SAC, not Soroban generally.**
42
+ * The same CAP: "`MuxedAddressObject` … is not implicitly compatible with `AddressObject`. Thus the
43
+ * contracts that expect the regular `AddressObject` as an input argument **will fail** if
44
+ * `ScAddress::SC_ADDRESS_TYPE_MUXED_ACCOUNT` is passed to them." So the carrier depends on which contract
45
+ * the payment invokes:
46
+ *
47
+ * - the **SAC** — the built-in contract for a classic asset — accepts a muxed `to`, and the weld rides;
48
+ * - a **custom SEP-41 token contract** rejects it, and the invocation FAILS rather than degrading.
49
+ *
50
+ * A deployment therefore gets this carrier through x402 when, and only when, the scheme's `asset` is the
51
+ * SAC. `protocol` stays absent because that is a genuine statement of neutrality — the carrier serves bare
52
+ * Soroban and x402 alike — rather than, as the earlier text had it, because x402 could not reach it.
53
+ *
54
+ * ⚠️ **Two things deliberately NOT claimed here, because they were not verified.** Whether a given x402
55
+ * facilitator independently rejects an `M…` `payTo` (the scheme does not require it to), and CAP-67's
56
+ * activation status on any particular network. Both are deployment-time facts a seller must establish for
57
+ * themselves; asserting either from this file would be the kind of unmeasured claim the correction above
58
+ * exists to remove.
31
59
  */
32
60
  export const STELLAR_MANIFEST: BindingManifest = {
33
61
  rail: "stellar",