Payment rail

Stellar

On Stellar, the seller’s muxed address takes the first 8 bytes of the ATR hash as its id. Source: lcp docs: rails⁠ (opens in a new tab)

Sources (1)

lcp docs: rails⁠ (opens in a new tab)

Where the ATR hash rides

On this rail, the ATR hash rides in the seller’s muxed address.

The standard

Eight bytes confirm an ATR hash that a party already holds; they do not let anyone recover it, and they bind the ATR hash only through those bytes. The pairing’s record says so. Source: lcp docs: rails⁠ (opens in a new tab) · Source: LCP §8.3.8⁠ (opens in a new tab)

The seller’s muxed address, whose 8-byte id is H’s first 8 bytes, as the Soroban transfer’s to. Source: lcp docs: rails⁠ (opens in a new tab)
x402/exact/stellarmpp/charge/stellar

Entry points: @integraledger/lcp/stellar, @integraledger/lcp/x402-exact-stellar, @integraledger/lcp/mpp · Install beside the package: @stellar/stellar-sdk

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The ATR hash of the site’s example ATR, as this rail carries it

H’s first 8 bytes, as the muxed id

9532110621754675459

Computed from the site’s example ATR by this rail’s own helper in the package, when the site was built.

What a payment on this rail proves

Of these 2 pairings, 0 have the buyer’s signature cover the ATR hash, 2 leave a public proof of it, and 0 let anyone read it back from the chain alone. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Switch to Technical to see each pairing, and the sentence its record states about what a payment through it proves.

The standard

x402/exact/stellarNative Field, truncatedBuyer signs H: noH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field, truncated (LCP §B.1)⁠ (opens in a new tab)
Where the ATR hash rides: The seller’s muxed address, whose 8-byte id is H’s first 8 bytes, as the Soroban transfer’s to.
What a payment through it proves: The ATR was assembled, written to the seller's storage and linked in the challenge before approval, and its hash is in the payment challenge, which the payer did not sign. The payer signed a transfer to the seller's muxed address whose 8-byte id is the first 8 bytes of this ATR's hash, and the transaction succeeded. The id binds this hash only through its first 8 bytes: whoever assembles the ATR can construct a second ATR whose hash begins with the same 8 bytes. This does not show that amount, asset or timing match the ATR's content.
mpp/charge/stellarNative Field, truncatedBuyer signs H: noH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Native Field, truncated (LCP §B.1)⁠ (opens in a new tab)
Where the ATR hash rides: The seller’s muxed address, whose 8-byte id is H’s first 8 bytes, as the Soroban transfer’s to.
What a payment through it proves: The ATR was assembled, written to the seller's storage and linked in the challenge before approval, and its hash is in the payment challenge, which the payer did not sign. The payer signed a transfer to the seller's muxed address whose 8-byte id is the first 8 bytes of this ATR's hash, and the transaction succeeded. The id binds this hash only through its first 8 bytes: whoever assembles the ATR can construct a second ATR whose hash begins with the same 8 bytes. This does not show that amount, asset or timing match the ATR's content.

Reading the settlement

The package reads a payment’s settlement through a reader you supply: the endpoint, the credentials, the timeouts and the retries are yours. A reader that fails never makes a payment read as failed. Source: lcp docs: reading settlement⁠ (opens in a new tab)

Sources (1)

lcp docs: reading settlement⁠ (opens in a new tab)

The protocols that pay on it

lcp docs: rails⁠ (opens in a new tab)

The live demonstrations are not running on this site at the moment.