swap: an asset↔asset offer cannot be requested or filled — one program and one TLV field short

[pietro909]

@arkade-os/swap can neither request nor fill an offer where both legs name an
asset. The solver decides such offers as of
lightning-swap-service#110
(merged), so the two sides now disagree about what the corridor serves.

Nothing is broken in production: no orchestrator serves an asset leg yet
(lss#125 tracks
what each leg still needs), and every failure below is loud. Filing it now because
closing it is design work, not a patch, and the solver side has already landed.

What the solver admits

src/core/assetOffer.ts models both sides as string | null — wantAssetId and
offerAssetId — with null meaning BTC, and its markets are unordered pairs of
asset ids with null. Both non-null is a served market; only the same asset on
both sides is refused, as degenerate_pair. On the wire, lss#113 makes the pair
arkade:<68-hex>->arkade:<68-hex> (152 chars, inside the 158 cap it sized for
exactly this case).

Where this SDK stops it

Four places, at origin/master:

site	what it enforces
packages/swap/src/offer.ts:40-41,54-55,91	two covenant programs only — swap-want-asset.program.json / swap-want-btc.program.json, selected by offer.wantAsset ? … : …
offer.ts:138,189	the offer TLV carries ONE asset field (wantAsset, tag 0x03), not two
offer.ts:165 and offer.ts:238	"offer must carry exactly one of wantAsset or offerAsset", on build and on TLV decode
rfq.ts:259-265 (arkadeSwapRequest), rfq.ts:971 (offerTermsFromQuote)	the same invariant at the request and quote-mapping layers

The failure is loud and early — arkadeSwapRequest throws before anything reaches
a solver, so a client cannot even ask. That is the right behaviour for today; it
is not a bug to fix in isolation.

What closing it needs

1. A third covenant program: deliver asset X against a deposit of asset Y. The
   existing two are "the fill must deliver an asset" and "the fill must deliver
   sats"; neither constrains both legs.
2. A widened offer TLV that can name two assets and say which is which, plus
   the decode-side rule that replaces "exactly one".
3. Relaxing the four guards above, in that order — they are correct until 1 and 2
   exist, and relaxing them first would let a caller build a request the fill path
   cannot settle.

Worth designing against lss#107's covenant and this repo's #763 together, rather
than after either merges.

Related

• feat(swap): name the asset id in the arkade pair leg #762 (merged) — the pair leg now names the asset id; this is the sibling gap
  it did not cover.
• feat(vhtlc): let a VHTLC be denominated in an Arkade asset (ScriptV2, and v1 by inheritance) #763 — VHTLC.ScriptV2 denominated in an asset: the same asset-covenant
  work, one leg at a time.
• lss#110 (merged) — the solver-side fill decision that admits asset↔asset.
• lss#107 — the solver's asset swap covenant and wire Asset ID codec.
• lss#125 — corridor support matrix; asset legs are "decision only" until an
  orchestrator exists.

[arkana-ai-bot]

Code context — confirmed block sites

All four guards verified against origin/master:

File	Line(s)	What it enforces
packages/swap/src/offer.ts	40–41, 54–55, 91	Two programs only (wantAssetProgram / wantBtcProgram), selected by offer.wantAsset ? … : …
offer.ts	164–165	Build-time: if (Boolean(offer.wantAsset) === Boolean(offer.offerAsset)) → throws "offer must carry exactly one…"
offer.ts	237–238	Decode-time: same XOR check on fields.wantAsset / fields.offerAsset
packages/swap/src/rfq.ts	259–265	arkadeSwapRequest — throws "asset→asset is nameable on the wire but no solver quotes it yet" before any network call

The error in rfq.ts accurately describes the current state: the solver side has landed (lss#110) but neither the third covenant program nor the widened TLV exists in this SDK yet.

Sequencing note

The issue has the ordering right. The guards at offer.ts:164 and offer.ts:237 are correct until a third program and the widened TLV exist — relaxing them first would let a caller construct a request the fill path cannot settle. The rfq.ts guard can be relaxed last, after the fill path is complete end-to-end.

Related files

• packages/swap/src/offer.ts — program map, TLV codec, both guards
• packages/swap/src/rfq.ts — arkadeSwapRequest (line 244) and offerTermsFromQuote (line 967)
• packages/swap/src/ — the third .program.json artifact (does not exist yet; needs the covenant from lss#107)

No immediate action needed from this side until the solver corridor support matrix (lss#125) is complete. Worth coordinating #763 (asset-denominated VHTLC) and lss#107's covenant before touching this.