@integraledger/lcp-binding-stellar 0.9.0 → 0.10.2

package/CHANGELOG.md

@@ -1,5 +1,63 @@
 # @integraledger/lcp-binding-stellar
 
+## 0.10.2
+
+### Patch Changes
+
+- 1d892dc: Correct the Stellar manifest's account of its relationship to x402.
+
+  The docblock claimed this binding welds into a CLASSIC Stellar payment, that x402's `exact` scheme for
+  Stellar was "a different flow entirely", and that "a deployment settling through an x402-Stellar facilitator
+  does not get this carrier". Every step of that was wrong, and it contradicted the same file: `finality.note`
+  says "Soroban SAC transfer", the paragraph above it says the buyer signs the Soroban SAC `transfer`, and
+  `adapter.ts` types the field it reads as "the `to` destination of the SAC transfer". There was never a
+  classic payment here to mux.
+
+  Re-read against the live sources: x402's exact-Stellar scheme is Soroban SEP-41 token transfers —
+  `invokeHostFunction` calling `transfer(from, to, amount)`, the same operation this binding welds into. Its
+  only rule on the destination is that argument 1 must equal `requirements.payTo` exactly, and it places no
+  format constraint on `payTo` anywhere, so a seller advertising their `M…` address satisfies it by
+  construction. And CAP-67 exists precisely to permit this: it adds `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and
+  allows the SAC to take that type in `transfer`.
+
+  What IS limited is narrower and different, and is now what the docblock states: CAP-67 extended the SAC, not
+  Soroban generally. `MuxedAddressObject` "is not implicitly compatible with `AddressObject`", so a custom
+  SEP-41 token contract rejects a muxed `to` and the invocation fails rather than degrading. The carrier is
+  therefore available through x402 when, and only when, the scheme's `asset` is the SAC.
+
+  No manifest field changed — `protocol` stays absent, but now because the carrier genuinely serves bare
+  Soroban and x402 alike rather than because x402 could not reach it. Two facts are explicitly left unclaimed
+  because they were not verified: whether a given facilitator independently rejects an `M…` `payTo`, and
+  CAP-67's activation status on any particular network.
+
+- Updated dependencies [b2ffecc]
+- Updated dependencies [822190a]
+  - @integraledger/lcp-binding-core@0.11.0
+  - @integraledger/lcp-kernel@0.11.0
+
+## 0.10.1
+
+**0.10.0 was staged and withdrawn before approval; this is that release, re-cut.** The conformance corpus
+was re-sealed after 0.10.0 was staged — its root moved `32fa90a6…` → `28bbf4ef…` when the vector tree was
+brought inside the prose gates — so the staged `lcp-conformance` tarball carried a seal that no longer
+matched the repository. The seal is what proves corpus authenticity to an independent implementer, and a
+published version cannot be replaced, so the whole set was rejected and re-cut rather than shipping one
+package that disagreed with its own source. No version 0.10.0 exists on the registry.
+
+### Minor Changes
+
+- f1c531c: **Breaking:** `USDC_DECIMALS` is renamed to `HEDERA_USDC_DECIMALS`, `SOLANA_USDC_DECIMALS`,
+  `STELLAR_USDC_DECIMALS` and `SUI_USDC_DECIMALS`.
+
+  All four packages exported the same name and they did not all mean the same number — Stellar assets carry
+  seven decimals where the other three carry six. Each value was correct for its own chain, so no package had
+  a defect and every package's own test passed; the hazard lived only in importing one rail's constant and
+  applying it on another, which is a ten-fold error in an amount and surfaces at settlement rather than at
+  compile time. The rail prefix makes that import impossible to make by accident.
+
+  `minor` rather than `major` because every package here is pre-1.0, where a minor is the breaking increment
+  under semver. Migration is a rename at the import site; the values are unchanged.
+
 ## 0.9.0
 
 First public release.

package/dist/constants.d.ts

@@ -42,6 +42,15 @@ export declare const PUBNET_PASSPHRASE = "Public Global Stellar Network ; Septem
 /** The constants for one network. Both are usable — the CAP-67 muxed id is a ledger primitive, so nothing
  *  has to be deployed first. */
 export declare function getStellarConfig(network: StellarNetwork): StellarNetworkConfig;
-/** USDC on Stellar has 7 decimals — 1 USDC = 10_000_000 base units. */
-export declare const USDC_DECIMALS = 7;
+/**
+ * USDC on Stellar has 7 decimals — 1 USDC = 10_000_000 base units.
+ *
+ * RAIL-QUALIFIED ON PURPOSE. Four bindings publish a USDC decimal count and they are NOT all the same —
+ * Stellar's is 7 where Hedera's, Solana's and Sui's are 6. A bare `USDC_DECIMALS` exported four times
+ * from four packages is one name with two meanings, and the way that fails is silent: a consumer who reads
+ * it from one rail and applies it on another is off by a factor of ten in an amount, at settlement rather
+ * than at compile time. Each value is correct for its own chain, which is why no per-package test can
+ * catch the clash; the prefix is what makes it impossible to import the wrong one by accident.
+ */
+export declare const STELLAR_USDC_DECIMALS = 7;
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"constants.d.ts","sourceRoot":"","sources":["../src/constants.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH;;;8GAG8G;AAC9G,eAAO,MAAM,UAAU,EAAG,kBAA2B,CAAC;AAEtD,8DAA8D;AAC9D,eAAO,MAAM,YAAY,IAAI,CAAC;AAE9B,mGAAmG;AACnG,MAAM,MAAM,cAAc,GAAG,SAAS,GAAG,QAAQ,CAAC;AAElD;;;wFAGwF;AACxF,MAAM,WAAW,oBAAoB;IACnC,OAAO,EAAE,cAAc,CAAC;IACxB,kEAAkE;IAClE,iBAAiB,EAAE,MAAM,CAAC;IAC1B,6BAA6B;IAC7B,UAAU,EAAE,MAAM,CAAC;IACnB,uBAAuB;IACvB,aAAa,EAAE,MAAM,CAAC;IACtB,oEAAoE;IACpE,iBAAiB,EAAE,MAAM,CAAC;CAC3B;AAED,yGAAyG;AACzG,eAAO,MAAM,kBAAkB,sCAAsC,CAAC;AACtE;;gCAEgC;AAChC,eAAO,MAAM,iBAAiB,mDACoB,CAAC;AAkBnD;gCACgC;AAChC,wBAAgB,gBAAgB,CAC9B,OAAO,EAAE,cAAc,GACtB,oBAAoB,CAEtB;AAED,uEAAuE;AACvE,eAAO,MAAM,aAAa,IAAI,CAAC"}
+{"version":3,"file":"constants.d.ts","sourceRoot":"","sources":["../src/constants.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH;;;8GAG8G;AAC9G,eAAO,MAAM,UAAU,EAAG,kBAA2B,CAAC;AAEtD,8DAA8D;AAC9D,eAAO,MAAM,YAAY,IAAI,CAAC;AAE9B,mGAAmG;AACnG,MAAM,MAAM,cAAc,GAAG,SAAS,GAAG,QAAQ,CAAC;AAElD;;;wFAGwF;AACxF,MAAM,WAAW,oBAAoB;IACnC,OAAO,EAAE,cAAc,CAAC;IACxB,kEAAkE;IAClE,iBAAiB,EAAE,MAAM,CAAC;IAC1B,6BAA6B;IAC7B,UAAU,EAAE,MAAM,CAAC;IACnB,uBAAuB;IACvB,aAAa,EAAE,MAAM,CAAC;IACtB,oEAAoE;IACpE,iBAAiB,EAAE,MAAM,CAAC;CAC3B;AAED,yGAAyG;AACzG,eAAO,MAAM,kBAAkB,sCAAsC,CAAC;AACtE;;gCAEgC;AAChC,eAAO,MAAM,iBAAiB,mDACoB,CAAC;AAkBnD;gCACgC;AAChC,wBAAgB,gBAAgB,CAC9B,OAAO,EAAE,cAAc,GACtB,oBAAoB,CAEtB;AAED;;;;;;;;;GASG;AACH,eAAO,MAAM,qBAAqB,IAAI,CAAC"}

package/dist/constants.js

@@ -41,6 +41,15 @@ const PUBNET = {
 export function getStellarConfig(network) {
     return network === "testnet" ? TESTNET : PUBNET;
 }
-/** USDC on Stellar has 7 decimals — 1 USDC = 10_000_000 base units. */
-export const USDC_DECIMALS = 7;
+/**
+ * USDC on Stellar has 7 decimals — 1 USDC = 10_000_000 base units.
+ *
+ * RAIL-QUALIFIED ON PURPOSE. Four bindings publish a USDC decimal count and they are NOT all the same —
+ * Stellar's is 7 where Hedera's, Solana's and Sui's are 6. A bare `USDC_DECIMALS` exported four times
+ * from four packages is one name with two meanings, and the way that fails is silent: a consumer who reads
+ * it from one rail and applies it on another is off by a factor of ten in an amount, at settlement rather
+ * than at compile time. Each value is correct for its own chain, which is why no per-package test can
+ * catch the clash; the prefix is what makes it impossible to import the wrong one by accident.
+ */
+export const STELLAR_USDC_DECIMALS = 7;
 //# sourceMappingURL=constants.js.map

package/dist/constants.js.map

@@ -1 +1 @@
-{"version":3,"file":"constants.js","sourceRoot":"","sources":["../src/constants.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH;;;8GAG8G;AAC9G,MAAM,CAAC,MAAM,UAAU,GAAG,kBAA2B,CAAC;AAEtD,8DAA8D;AAC9D,MAAM,CAAC,MAAM,YAAY,GAAG,CAAC,CAAC;AAqB9B,yGAAyG;AACzG,MAAM,CAAC,MAAM,kBAAkB,GAAG,mCAAmC,CAAC;AACtE;;gCAEgC;AAChC,MAAM,CAAC,MAAM,iBAAiB,GAC5B,gDAAgD,CAAC;AAEnD,MAAM,OAAO,GAAyB;IACpC,OAAO,EAAE,SAAS;IAClB,iBAAiB,EAAE,kBAAkB;IACrC,UAAU,EAAE,qCAAqC;IACjD,aAAa,EAAE,qCAAqC;IACpD,iBAAiB,EAAE,0DAA0D;CAC9E,CAAC;AAEF,MAAM,MAAM,GAAyB;IACnC,OAAO,EAAE,QAAQ;IACjB,iBAAiB,EAAE,iBAAiB;IACpC,UAAU,EAAE,6BAA6B;IACzC,aAAa,EAAE,gCAAgC;IAC/C,iBAAiB,EAAE,0DAA0D;CAC9E,CAAC;AAEF;gCACgC;AAChC,MAAM,UAAU,gBAAgB,CAC9B,OAAuB;IAEvB,OAAO,OAAO,KAAK,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC;AAClD,CAAC;AAED,uEAAuE;AACvE,MAAM,CAAC,MAAM,aAAa,GAAG,CAAC,CAAC"}
+{"version":3,"file":"constants.js","sourceRoot":"","sources":["../src/constants.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH;;;8GAG8G;AAC9G,MAAM,CAAC,MAAM,UAAU,GAAG,kBAA2B,CAAC;AAEtD,8DAA8D;AAC9D,MAAM,CAAC,MAAM,YAAY,GAAG,CAAC,CAAC;AAqB9B,yGAAyG;AACzG,MAAM,CAAC,MAAM,kBAAkB,GAAG,mCAAmC,CAAC;AACtE;;gCAEgC;AAChC,MAAM,CAAC,MAAM,iBAAiB,GAC5B,gDAAgD,CAAC;AAEnD,MAAM,OAAO,GAAyB;IACpC,OAAO,EAAE,SAAS;IAClB,iBAAiB,EAAE,kBAAkB;IACrC,UAAU,EAAE,qCAAqC;IACjD,aAAa,EAAE,qCAAqC;IACpD,iBAAiB,EAAE,0DAA0D;CAC9E,CAAC;AAEF,MAAM,MAAM,GAAyB;IACnC,OAAO,EAAE,QAAQ;IACjB,iBAAiB,EAAE,iBAAiB;IACpC,UAAU,EAAE,6BAA6B;IACzC,aAAa,EAAE,gCAAgC;IAC/C,iBAAiB,EAAE,0DAA0D;CAC9E,CAAC;AAEF;gCACgC;AAChC,MAAM,UAAU,gBAAgB,CAC9B,OAAuB;IAEvB,OAAO,OAAO,KAAK,SAAS,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC;AAClD,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAAG,CAAC,CAAC"}

package/dist/index.d.ts

@@ -1,5 +1,5 @@
 export { buildMuxedDestination, createStellarAdapter, isSettledSuccessfully, STELLAR_PREFIX_NOTE, type StellarAdapter, type StellarMuxConfirmation, type StellarMuxPrefixRecovery, type StellarReader, type StellarSettlementRef, type StellarSettlementView, } from "./adapter.js";
-export { getStellarConfig, MUX_ID_BYTES, MUX_SCHEME, PUBNET_PASSPHRASE, type StellarNetwork, type StellarNetworkConfig, TESTNET_PASSPHRASE, USDC_DECIMALS, } from "./constants.js";
+export { getStellarConfig, MUX_ID_BYTES, MUX_SCHEME, PUBNET_PASSPHRASE, STELLAR_USDC_DECIMALS, type StellarNetwork, type StellarNetworkConfig, TESTNET_PASSPHRASE, } from "./constants.js";
 export { STELLAR_MANIFEST } from "./manifest.js";
 export { type DecodedMuxedAddress, decodeMuxedAddress, deriveMuxId, encodeMuxedAddress, recoverMuxIdPrefix8, verifyMuxedBinding, } from "./mux.js";
 //# sourceMappingURL=index.d.ts.map

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,qBAAqB,EACrB,oBAAoB,EACpB,qBAAqB,EACrB,mBAAmB,EACnB,KAAK,cAAc,EACnB,KAAK,sBAAsB,EAC3B,KAAK,wBAAwB,EAC7B,KAAK,aAAa,EAClB,KAAK,oBAAoB,EACzB,KAAK,qBAAqB,GAC3B,MAAM,cAAc,CAAC;AACtB,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,iBAAiB,EACjB,KAAK,cAAc,EACnB,KAAK,oBAAoB,EACzB,kBAAkB,EAClB,aAAa,GACd,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC;AACjD,OAAO,EACL,KAAK,mBAAmB,EACxB,kBAAkB,EAClB,WAAW,EACX,kBAAkB,EAClB,mBAAmB,EACnB,kBAAkB,GACnB,MAAM,UAAU,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,qBAAqB,EACrB,oBAAoB,EACpB,qBAAqB,EACrB,mBAAmB,EACnB,KAAK,cAAc,EACnB,KAAK,sBAAsB,EAC3B,KAAK,wBAAwB,EAC7B,KAAK,aAAa,EAClB,KAAK,oBAAoB,EACzB,KAAK,qBAAqB,GAC3B,MAAM,cAAc,CAAC;AACtB,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,iBAAiB,EACjB,qBAAqB,EACrB,KAAK,cAAc,EACnB,KAAK,oBAAoB,EACzB,kBAAkB,GACnB,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC;AACjD,OAAO,EACL,KAAK,mBAAmB,EACxB,kBAAkB,EAClB,WAAW,EACX,kBAAkB,EAClB,mBAAmB,EACnB,kBAAkB,GACnB,MAAM,UAAU,CAAC"}

package/dist/index.js

@@ -1,5 +1,5 @@
 export { buildMuxedDestination, createStellarAdapter, isSettledSuccessfully, STELLAR_PREFIX_NOTE, } from "./adapter.js";
-export { getStellarConfig, MUX_ID_BYTES, MUX_SCHEME, PUBNET_PASSPHRASE, TESTNET_PASSPHRASE, USDC_DECIMALS, } from "./constants.js";
+export { getStellarConfig, MUX_ID_BYTES, MUX_SCHEME, PUBNET_PASSPHRASE, STELLAR_USDC_DECIMALS, TESTNET_PASSPHRASE, } from "./constants.js";
 export { STELLAR_MANIFEST } from "./manifest.js";
 export { decodeMuxedAddress, deriveMuxId, encodeMuxedAddress, recoverMuxIdPrefix8, verifyMuxedBinding, } from "./mux.js";
 //# sourceMappingURL=index.js.map

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,qBAAqB,EACrB,oBAAoB,EACpB,qBAAqB,EACrB,mBAAmB,GAOpB,MAAM,cAAc,CAAC;AACtB,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,iBAAiB,EAGjB,kBAAkB,EAClB,aAAa,GACd,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC;AACjD,OAAO,EAEL,kBAAkB,EAClB,WAAW,EACX,kBAAkB,EAClB,mBAAmB,EACnB,kBAAkB,GACnB,MAAM,UAAU,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,qBAAqB,EACrB,oBAAoB,EACpB,qBAAqB,EACrB,mBAAmB,GAOpB,MAAM,cAAc,CAAC;AACtB,OAAO,EACL,gBAAgB,EAChB,YAAY,EACZ,UAAU,EACV,iBAAiB,EACjB,qBAAqB,EAGrB,kBAAkB,GACnB,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC;AACjD,OAAO,EAEL,kBAAkB,EAClB,WAAW,EACX,kBAAkB,EAClB,mBAAmB,EACnB,kBAAkB,GACnB,MAAM,UAAU,CAAC"}

package/dist/manifest.d.ts

@@ -16,17 +16,45 @@ import type { BindingManifest } from "@integraledger/lcp-binding-core";
  * `forwardIndexable: false` (no native index over mux prefixes; `enumerate` is a best-effort account scan,
  * `indexing: "account-scan:mux-prefix8"`). The prefix-8 truncation is stated in `finality.note` too.
  *
- * **NO `protocol`, and here is precisely what it is neutral OF.** This binding welds into the destination
- * of a CLASSIC Stellar payment. x402's `exact` scheme for Stellar (read 2026-08-08) is a different flow
- * entirely: "This spec covers SEP-41-compliant Soroban tokens **only**. Classic Stellar assets are not
- * supported", and the payment is an `invokeHostFunction` calling `transfer(from, to, amount)` where
- * "Argument 1 (to): MUST equal `requirements.payTo` exactly".
- *
- * A muxed destination cannot appear in that call — there is no classic payment to mux, and an `M…` address
- * would not equal `payTo` exactly. So a deployment settling through an x402-Stellar facilitator does not
- * get this carrier. That is a scoping fact, not a defect: the binding has never declared `protocol`, and
- * the mux weld is correct on the rail it targets. Stated here so the absence is a measured claim rather
- * than an unexamined default.
+ * **NO `protocol`, and the reason is that the carrier genuinely works on both sides — CORRECTED
+ * 2026-08-15.** An earlier revision of this paragraph said the opposite: that the binding welds into a
+ * CLASSIC Stellar payment, that x402's `exact` scheme for Stellar was "a different flow entirely", and
+ * that "a deployment settling through an x402-Stellar facilitator does not get this carrier". Every step of
+ * that was wrong, and it contradicted this same file — `finality.note` below says "Soroban SAC transfer",
+ * the paragraph above says the buyer signs the Soroban SAC `transfer`, and `adapter.ts` types the field it
+ * reads as "the `to` destination of the SAC transfer". There was never a classic payment here to mux.
+ *
+ * Re-read against the live sources on 2026-08-15:
+ *
+ * - **x402's `exact` scheme for Stellar** (`x402-foundation/x402` HEAD `167a828e8319`) is Soroban SEP-41
+ *   token transfers — an `invokeHostFunction` calling `transfer(from, to, amount)`. That is the SAME
+ *   operation this binding welds into, not a different flow.
+ * - Its only rule on the destination is "**Argument 1 (to)**: MUST equal `requirements.payTo` exactly". The
+ *   scheme places **no format constraint on `payTo` anywhere**; its example happens to show a `G…` address,
+ *   and an example is not a constraint. A seller advertising their `M…` address as `payTo` satisfies the
+ *   rule by construction.
+ * - **CAP-67** (`stellar/stellar-protocol`, `core/cap-0067.md`) exists precisely to permit this: "Add memo
+ *   support to Soroban by adding a `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and allow the SAC to take in this type
+ *   in the `transfer` function call."
+ *
+ * ⛔ **What IS limited, and it is narrower and different: CAP-67 extended the SAC, not Soroban generally.**
+ * The same CAP: "`MuxedAddressObject` … is not implicitly compatible with `AddressObject`. Thus the
+ * contracts that expect the regular `AddressObject` as an input argument **will fail** if
+ * `ScAddress::SC_ADDRESS_TYPE_MUXED_ACCOUNT` is passed to them." So the carrier depends on which contract
+ * the payment invokes:
+ *
+ * - the **SAC** — the built-in contract for a classic asset — accepts a muxed `to`, and the weld rides;
+ * - a **custom SEP-41 token contract** rejects it, and the invocation FAILS rather than degrading.
+ *
+ * A deployment therefore gets this carrier through x402 when, and only when, the scheme's `asset` is the
+ * SAC. `protocol` stays absent because that is a genuine statement of neutrality — the carrier serves bare
+ * Soroban and x402 alike — rather than, as the earlier text had it, because x402 could not reach it.
+ *
+ * ⚠️ **Two things deliberately NOT claimed here, because they were not verified.** Whether a given x402
+ * facilitator independently rejects an `M…` `payTo` (the scheme does not require it to), and CAP-67's
+ * activation status on any particular network. Both are deployment-time facts a seller must establish for
+ * themselves; asserting either from this file would be the kind of unmeasured claim the correction above
+ * exists to remove.
  */
 export declare const STELLAR_MANIFEST: BindingManifest;
 //# sourceMappingURL=manifest.d.ts.map

package/dist/manifest.d.ts.map

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

@@ -15,17 +15,45 @@
  * `forwardIndexable: false` (no native index over mux prefixes; `enumerate` is a best-effort account scan,
  * `indexing: "account-scan:mux-prefix8"`). The prefix-8 truncation is stated in `finality.note` too.
  *
- * **NO `protocol`, and here is precisely what it is neutral OF.** This binding welds into the destination
- * of a CLASSIC Stellar payment. x402's `exact` scheme for Stellar (read 2026-08-08) is a different flow
- * entirely: "This spec covers SEP-41-compliant Soroban tokens **only**. Classic Stellar assets are not
- * supported", and the payment is an `invokeHostFunction` calling `transfer(from, to, amount)` where
- * "Argument 1 (to): MUST equal `requirements.payTo` exactly".
- *
- * A muxed destination cannot appear in that call — there is no classic payment to mux, and an `M…` address
- * would not equal `payTo` exactly. So a deployment settling through an x402-Stellar facilitator does not
- * get this carrier. That is a scoping fact, not a defect: the binding has never declared `protocol`, and
- * the mux weld is correct on the rail it targets. Stated here so the absence is a measured claim rather
- * than an unexamined default.
+ * **NO `protocol`, and the reason is that the carrier genuinely works on both sides — CORRECTED
+ * 2026-08-15.** An earlier revision of this paragraph said the opposite: that the binding welds into a
+ * CLASSIC Stellar payment, that x402's `exact` scheme for Stellar was "a different flow entirely", and
+ * that "a deployment settling through an x402-Stellar facilitator does not get this carrier". Every step of
+ * that was wrong, and it contradicted this same file — `finality.note` below says "Soroban SAC transfer",
+ * the paragraph above says the buyer signs the Soroban SAC `transfer`, and `adapter.ts` types the field it
+ * reads as "the `to` destination of the SAC transfer". There was never a classic payment here to mux.
+ *
+ * Re-read against the live sources on 2026-08-15:
+ *
+ * - **x402's `exact` scheme for Stellar** (`x402-foundation/x402` HEAD `167a828e8319`) is Soroban SEP-41
+ *   token transfers — an `invokeHostFunction` calling `transfer(from, to, amount)`. That is the SAME
+ *   operation this binding welds into, not a different flow.
+ * - Its only rule on the destination is "**Argument 1 (to)**: MUST equal `requirements.payTo` exactly". The
+ *   scheme places **no format constraint on `payTo` anywhere**; its example happens to show a `G…` address,
+ *   and an example is not a constraint. A seller advertising their `M…` address as `payTo` satisfies the
+ *   rule by construction.
+ * - **CAP-67** (`stellar/stellar-protocol`, `core/cap-0067.md`) exists precisely to permit this: "Add memo
+ *   support to Soroban by adding a `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and allow the SAC to take in this type
+ *   in the `transfer` function call."
+ *
+ * ⛔ **What IS limited, and it is narrower and different: CAP-67 extended the SAC, not Soroban generally.**
+ * The same CAP: "`MuxedAddressObject` … is not implicitly compatible with `AddressObject`. Thus the
+ * contracts that expect the regular `AddressObject` as an input argument **will fail** if
+ * `ScAddress::SC_ADDRESS_TYPE_MUXED_ACCOUNT` is passed to them." So the carrier depends on which contract
+ * the payment invokes:
+ *
+ * - the **SAC** — the built-in contract for a classic asset — accepts a muxed `to`, and the weld rides;
+ * - a **custom SEP-41 token contract** rejects it, and the invocation FAILS rather than degrading.
+ *
+ * A deployment therefore gets this carrier through x402 when, and only when, the scheme's `asset` is the
+ * SAC. `protocol` stays absent because that is a genuine statement of neutrality — the carrier serves bare
+ * Soroban and x402 alike — rather than, as the earlier text had it, because x402 could not reach it.
+ *
+ * ⚠️ **Two things deliberately NOT claimed here, because they were not verified.** Whether a given x402
+ * facilitator independently rejects an `M…` `payTo` (the scheme does not require it to), and CAP-67's
+ * activation status on any particular network. Both are deployment-time facts a seller must establish for
+ * themselves; asserting either from this file would be the kind of unmeasured claim the correction above
+ * exists to remove.
  */
 export const STELLAR_MANIFEST = {
     rail: "stellar",

package/dist/manifest.js.map

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

@@ -1,6 +1,6 @@
 {
   "name": "@integraledger/lcp-binding-stellar",
-  "version": "0.9.0",
+  "version": "0.10.2",
   "description": "Welds an ATR hash into a Stellar payment.",
   "keywords": [
     "lcp",
@@ -42,8 +42,8 @@
   "homepage": "https://github.com/IntegraLedger/integra-protocol/tree/main/packages/binding-stellar#readme",
   "dependencies": {
     "@stellar/stellar-sdk": "16.2.0",
-    "@integraledger/lcp-binding-core": "0.9.0",
-    "@integraledger/lcp-kernel": "0.9.0"
+    "@integraledger/lcp-binding-core": "0.11.0",
+    "@integraledger/lcp-kernel": "0.11.0"
   },
   "devDependencies": {
     "@types/json-schema": "7.0.15",

package/src/constants.ts

@@ -70,5 +70,14 @@ export function getStellarConfig(
   return network === "testnet" ? TESTNET : PUBNET;
 }
 
-/** USDC on Stellar has 7 decimals — 1 USDC = 10_000_000 base units. */
-export const USDC_DECIMALS = 7;
+/**
+ * USDC on Stellar has 7 decimals — 1 USDC = 10_000_000 base units.
+ *
+ * RAIL-QUALIFIED ON PURPOSE. Four bindings publish a USDC decimal count and they are NOT all the same —
+ * Stellar's is 7 where Hedera's, Solana's and Sui's are 6. A bare `USDC_DECIMALS` exported four times
+ * from four packages is one name with two meanings, and the way that fails is silent: a consumer who reads
+ * it from one rail and applies it on another is off by a factor of ten in an amount, at settlement rather
+ * than at compile time. Each value is correct for its own chain, which is why no per-package test can
+ * catch the clash; the prefix is what makes it impossible to import the wrong one by accident.
+ */
+export const STELLAR_USDC_DECIMALS = 7;

package/src/index.ts

@@ -15,10 +15,10 @@ export {
   MUX_ID_BYTES,
   MUX_SCHEME,
   PUBNET_PASSPHRASE,
+  STELLAR_USDC_DECIMALS,
   type StellarNetwork,
   type StellarNetworkConfig,
   TESTNET_PASSPHRASE,
-  USDC_DECIMALS,
 } from "./constants.js";
 export { STELLAR_MANIFEST } from "./manifest.js";
 export {

package/src/manifest.ts

@@ -17,17 +17,45 @@ import type { BindingManifest } from "@integraledger/lcp-binding-core";
  * `forwardIndexable: false` (no native index over mux prefixes; `enumerate` is a best-effort account scan,
  * `indexing: "account-scan:mux-prefix8"`). The prefix-8 truncation is stated in `finality.note` too.
  *
- * **NO `protocol`, and here is precisely what it is neutral OF.** This binding welds into the destination
- * of a CLASSIC Stellar payment. x402's `exact` scheme for Stellar (read 2026-08-08) is a different flow
- * entirely: "This spec covers SEP-41-compliant Soroban tokens **only**. Classic Stellar assets are not
- * supported", and the payment is an `invokeHostFunction` calling `transfer(from, to, amount)` where
- * "Argument 1 (to): MUST equal `requirements.payTo` exactly".
- *
- * A muxed destination cannot appear in that call — there is no classic payment to mux, and an `M…` address
- * would not equal `payTo` exactly. So a deployment settling through an x402-Stellar facilitator does not
- * get this carrier. That is a scoping fact, not a defect: the binding has never declared `protocol`, and
- * the mux weld is correct on the rail it targets. Stated here so the absence is a measured claim rather
- * than an unexamined default.
+ * **NO `protocol`, and the reason is that the carrier genuinely works on both sides — CORRECTED
+ * 2026-08-15.** An earlier revision of this paragraph said the opposite: that the binding welds into a
+ * CLASSIC Stellar payment, that x402's `exact` scheme for Stellar was "a different flow entirely", and
+ * that "a deployment settling through an x402-Stellar facilitator does not get this carrier". Every step of
+ * that was wrong, and it contradicted this same file — `finality.note` below says "Soroban SAC transfer",
+ * the paragraph above says the buyer signs the Soroban SAC `transfer`, and `adapter.ts` types the field it
+ * reads as "the `to` destination of the SAC transfer". There was never a classic payment here to mux.
+ *
+ * Re-read against the live sources on 2026-08-15:
+ *
+ * - **x402's `exact` scheme for Stellar** (`x402-foundation/x402` HEAD `167a828e8319`) is Soroban SEP-41
+ *   token transfers — an `invokeHostFunction` calling `transfer(from, to, amount)`. That is the SAME
+ *   operation this binding welds into, not a different flow.
+ * - Its only rule on the destination is "**Argument 1 (to)**: MUST equal `requirements.payTo` exactly". The
+ *   scheme places **no format constraint on `payTo` anywhere**; its example happens to show a `G…` address,
+ *   and an example is not a constraint. A seller advertising their `M…` address as `payTo` satisfies the
+ *   rule by construction.
+ * - **CAP-67** (`stellar/stellar-protocol`, `core/cap-0067.md`) exists precisely to permit this: "Add memo
+ *   support to Soroban by adding a `SC_ADDRESS_TYPE_MUXED_ACCOUNT` and allow the SAC to take in this type
+ *   in the `transfer` function call."
+ *
+ * ⛔ **What IS limited, and it is narrower and different: CAP-67 extended the SAC, not Soroban generally.**
+ * The same CAP: "`MuxedAddressObject` … is not implicitly compatible with `AddressObject`. Thus the
+ * contracts that expect the regular `AddressObject` as an input argument **will fail** if
+ * `ScAddress::SC_ADDRESS_TYPE_MUXED_ACCOUNT` is passed to them." So the carrier depends on which contract
+ * the payment invokes:
+ *
+ * - the **SAC** — the built-in contract for a classic asset — accepts a muxed `to`, and the weld rides;
+ * - a **custom SEP-41 token contract** rejects it, and the invocation FAILS rather than degrading.
+ *
+ * A deployment therefore gets this carrier through x402 when, and only when, the scheme's `asset` is the
+ * SAC. `protocol` stays absent because that is a genuine statement of neutrality — the carrier serves bare
+ * Soroban and x402 alike — rather than, as the earlier text had it, because x402 could not reach it.
+ *
+ * ⚠️ **Two things deliberately NOT claimed here, because they were not verified.** Whether a given x402
+ * facilitator independently rejects an `M…` `payTo` (the scheme does not require it to), and CAP-67's
+ * activation status on any particular network. Both are deployment-time facts a seller must establish for
+ * themselves; asserting either from this file would be the kind of unmeasured claim the correction above
+ * exists to remove.
  */
 export const STELLAR_MANIFEST: BindingManifest = {
   rail: "stellar",