blip-29: enhance tap_rfq with in_asset_id, out_asset_id
#3
Conversation
Refactors `tap_rfq` to support explicit asset identification for both incoming and outgoing assets in RFQ requests. Previously, `tap_rfq` implied BTC as one of the assets in a swap, limiting asset flexibility. The introduction of `in_asset_id` and `out_asset_id` enables clear directionality for swaps, indicating the asset to send and to receive. This update mandates that either `in_asset_id`, or `out_asset_id`, or both must be specified. If one is omitted, BTC is assumed as the default asset for the unspecified direction.
| @@ -924,21 +924,26 @@ accept if favorable | |||
|
|
|||
| ##### Request For Quote (`tap_rfq`) | |||
|
|
|||
| When a receiver wishes to receive `N` units of TAP asset ID `asset_id`, a new | |||
| When a receiver wishes to receive `N` units of TAP asset ID `in_asset_id`, a new | |||
There was a problem hiding this comment.
Term here assumes only receiver, but now can be receiver/sender based on the new fields below.
| p2p message `tap_rfq` is sent with the following structure: | ||
|
|
||
| 1. type: ?? (`tap_rfq`) | ||
| 2. data: | ||
| * [`32*byte`:`rfq_id`] | ||
| * [`32*byte`:`asset_id`] | ||
| * [`32*byte`:`in_asset_id`] | ||
| * [`32*byte`:`out_asset_id`] |
There was a problem hiding this comment.
Seeing it laid out now, do we also need to split the asset_amt field as well?
Before this change, asset_amt here was the amount of USD (or w/e) tied to the invoice. So we were asking for a price quote in BTC/asset_id.
My interpretation now is that if you only specify in_asset_id (assume USD-X), then in the LN setting, it's a quote for receiving asset_id. If you only specify out_asset_id, then in the LN setting, it's a quote for sending asset_id.
Does that match your interpretation? Perhaps we can make it a bit more concrete by outlining some typical user flows near the end of the document.
|
Closed in favour of #4 which will include all RFQ changes. |
Towards solving lightninglabs/taproot-assets#859
Refactors
tap_rfqto support explicit asset identification for both incoming and outgoing assets in RFQ requests. Previously,tap_rfqimplied BTC as one of the assets in a swap, limiting asset flexibility. The introduction ofin_asset_idandout_asset_idenables clear directionality for swaps, indicating the asset to send and to receive.This update mandates that either
in_asset_id, orout_asset_id, or both must be specified. If one is omitted, BTC is assumed as the default asset for the unspecified direction.