You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first real mainnet payment settled correctly (3e8dfd1…, memo pl_7j1wukfijsm1). The question it raised: what if the buyer forgets the memo?
Answer, from match-payment.ts:57: { kind: "no_memo" }. The money arrives in the merchant's wallet — nothing is lost, Quay never holds it — but the link stays active forever. Same for a mangled memo (unknown_reference).
There is no recovery path. No reconcile screen, no manual match. The seller has the money and an invoice that says unpaid.
Why muxed fixes the class, not the instance
match-payment.ts:49 already says it:
the id lives inside the destination address itself, so it survives wallets that drop, mangle, or overwrite the memo. Tried first and independently of memo — a muxed link needs no memo at all.
SEP-23 is implemented and wired (stellar-rail.ts:48, newMuxedId(), findLinkByMuxedId). CORRELATION=muxed is one environment variable. The buyer cannot forget a memo that does not exist.
Why it is not just a flag flip
M... destinations are well supported by modern wallets and are the SEP-23 standard, but some older wallets and several exchanges reject them outright. A buyer whose wallet refuses the address cannot pay at all — which is a worse failure than an unmatched payment, because at least the unmatched one delivered the money.
Create a link, attempt payment from each wallet a buyer plausibly uses: Freighter, Lobstr, xBull, and at least one exchange withdrawal.
Record which accept M... and which reject it.
Decide from evidence: muxed as default, memo as default with muxed opt-in, or both offered per link.
Regardless of the outcome
A buyer can always pay the bare G... address by hand, so the unmatched-payment state survives any correlation scheme. Worth deciding separately whether a reconcile path is warranted: the seller can see an incoming payment on their own wallet that Quay could not attribute, and today the product says nothing about it.
What happened
The first real mainnet payment settled correctly (
3e8dfd1…, memopl_7j1wukfijsm1). The question it raised: what if the buyer forgets the memo?Answer, from
match-payment.ts:57:{ kind: "no_memo" }. The money arrives in the merchant's wallet — nothing is lost, Quay never holds it — but the link staysactiveforever. Same for a mangled memo (unknown_reference).There is no recovery path. No reconcile screen, no manual match. The seller has the money and an invoice that says unpaid.
Why muxed fixes the class, not the instance
match-payment.ts:49already says it:SEP-23 is implemented and wired (
stellar-rail.ts:48,newMuxedId(),findLinkByMuxedId).CORRELATION=muxedis one environment variable. The buyer cannot forget a memo that does not exist.Why it is not just a flag flip
M...destinations are well supported by modern wallets and are the SEP-23 standard, but some older wallets and several exchanges reject them outright. A buyer whose wallet refuses the address cannot pay at all — which is a worse failure than an unmatched payment, because at least the unmatched one delivered the money.Plan
CORRELATION=muxedon the testnet service (deploys fromdev) — first real use of the staging split from ops: deploy testnet from dev and mainnet from main #194.M...and which reject it.Regardless of the outcome
A buyer can always pay the bare
G...address by hand, so the unmatched-payment state survives any correlation scheme. Worth deciding separately whether a reconcile path is warranted: the seller can see an incoming payment on their own wallet that Quay could not attribute, and today the product says nothing about it.