loopin: Route invoices over asset channels - #1212
Conversation
Wrap tapd's asset-aware invoice RPC so Loop In can create regular and hold invoices payable through a selected asset channel.
Create Loop In swap and probe invoices through tapd, pin both invoices to the negotiated asset edge, and pass that edge to the server as the final hop.
Let RPC and CLI callers select an asset and optional channel peer for Loop In while preserving the existing BTC invoice behavior by default.
Record the new Taproot Asset invoice path in the next Loop release notes.
There was a problem hiding this comment.
Pull request overview
This PR extends Loop In to support routing swap/probe invoices over Taproot Asset channels by exposing asset routing parameters on the Loop In RPC/CLI and creating the invoices via tapd, pinned to the negotiated asset edge peer.
Changes:
- Add
asset_info(asset ID + optional asset edge node) to Loop In RPC/Swagger/CLI, and validate incompatible routing options. - Update Loop In swap initiation to create both swap and probe invoices through
tapdwhenasset_infois set, pinning server payment/probe to the negotiated edge peer. - Add test coverage for asset invoice creation, peer pinning, and request validation; update session fixtures and release notes.
Reviewed changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
server_mock_test.go |
Extend mock server to capture Loop In last-hop and initiator passed during swap creation. |
looprpc/client.swagger.json |
Document new Loop In asset_info fields in the REST/Swagger surface. |
looprpc/client.proto |
Add AssetLoopInRequest and LoopInRequest.asset_info to the public RPC API. |
looprpc/client.pb.go |
Regenerated protobuf bindings to include the new Loop In asset_info message/field. |
loopin.go |
Implement asset-aware Loop In flow: validate options and create swap/probe invoices via tapd. |
loopin_test.go |
Add tests verifying tapd invoice creation, peer pinning, and request validation for asset Loop Ins. |
loopd/swapclient_server.go |
Parse/validate asset_info on the daemon RPC boundary and map into internal LoopInRequest. |
interface.go |
Extend internal LoopInRequest with AssetId and AssetEdgeNode. |
docs/release-notes/release-notes-next.md |
Add release note entry for Taproot Asset channel invoice routing in Loop In. |
cmd/loop/testdata/sessions/loopin/06_loop-in-external-force.json |
Update CLI golden session output to include asset_info. |
cmd/loop/testdata/sessions/basic-swaps/02_loop-in.json |
Update CLI golden session output to include asset_info. |
cmd/loop/loopin.go |
Add CLI flags for asset loop-ins and plumb asset_info into the Loop In RPC request. |
client.go |
Improve logging/validation around asset loop-in usage in the client entrypoint. |
assets/client.go |
Add TapdClient.AddAssetInvoice helper to create (hold) invoices via tapd asset channels. |
assets/client_test.go |
Add tests for AddAssetInvoice covering hold vs regular invoice and incomplete responses. |
Files not reviewed (1)
- looprpc/client.pb.go: Generated file
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| assetID, err := hex.DecodeString(cmd.String("asset_id")) | ||
| if err != nil { | ||
| return fmt.Errorf("invalid asset id: %w", err) | ||
| } | ||
|
|
||
| var assetEdgeNode []byte | ||
| if cmd.IsSet("asset_edge_node") { | ||
| assetEdgeNode, err = hex.DecodeString( | ||
| cmd.String("asset_edge_node"), | ||
| ) | ||
| if err != nil { | ||
| return fmt.Errorf("invalid asset edge node: %w", err) | ||
| } | ||
| } |
Include the new asset Loop In flags in the generated man page and Markdown command reference.
|
/gateway review |
|
👀 gateway review starting… |
|
/gateway review |
| The optional node identity public key of the asset channel peer to use for | ||
| RFQ negotiation. If omitted, tapd selects from the eligible asset channels. | ||
| */ | ||
| bytes asset_edge_node = 2; |
There was a problem hiding this comment.
[P1] Require a minimum asset output: The request specifies only an asset ID and optional peer. It provides no minimum asset amount or rate floor, even though the edge quote determines how many asset units the client receives for its on-chain BTC. The quote is negotiated only after CLI confirmation and is never returned, displayed, or persisted. The daemon-wide tapd price-deviation check is not per-swap user consent. Add a quote phase or fields such as minimum_asset_amount or rate_limit, show the resulting asset amount, and enforce the limit in AddInvoiceRequest before committing the swap.
| return nil, err | ||
| var probeInvoice string | ||
| if assetLoopIn { | ||
| assetProbe, err := cfg.assets.AddAssetInvoice( |
There was a problem hiding this comment.
[P1] Probe the exact RFQ used by the swap: This second AddAssetInvoice call negotiates a new RFQ. Checking only that its peer matches is insufficient: the probe and swap invoices have different RFQ IDs, virtual SCIDs, rates, limits, and policies. A probe can therefore succeed with a smaller asset requirement or different final-hop fee while the actual swap quote fails after the BTC HTLC is funded. Create the probe and swap invoices from the same accepted RFQ-backed route hint, or otherwise verify and reserve the exact rate, SCID, and capacity used by the swap invoice.
|
|
||
| // Pin the probe and the server payment to the same edge node as | ||
| // the swap invoice. | ||
| request.LastHop = "ePeer |
There was a problem hiding this comment.
[P1] Do not treat the tapd reference quote as edge selection: When no edge is supplied, tapd negotiates with multiple peers and returns its most-expensive quote as the reference quote while putting multiple RFQ hints in the invoice. That response is not a selected route, but this code treats its peer as one and pins the server to it, forcing the worst-priced edge and disabling the other hints. The server fee quote was also calculated earlier with LastHop unset, so its invoice amount may not match this route fee. Require an explicit edge for now, or add a pre-swap selection phase that chooses an approved quote before calculating server fees.
| // assetLoopInInvoiceExpiry is the invoice lifetime an asset edge must cover | ||
| // with its RFQ quote. If an on-chain funding transaction does not confirm in | ||
| // this window, the swap fails safely and the client can reclaim the HTLC. | ||
| const assetLoopInInvoiceExpiry = int64(60 * 60) |
There was a problem hiding this comment.
[P1] Invoice lifetime is shorter than the payment lifecycle: The asset invoice and RFQ expire after one hour, but the server normally waits 3-6 confirmations and retries failed payments only after one hour. Normal block variance alone makes expiration likely, particularly for six-confirmation swaps. Once funded, failure can send the client to the default 1000-block refund path. The RFQ must cover confirmation and retry time, or RFQ and invoice creation must be deferred until the HTLC is sufficiently confirmed.
|
|
||
| assetInfo = &looprpc.AssetLoopInRequest{ | ||
| AssetId: assetID, | ||
| AssetEdgeNode: assetEdgeNode, |
There was a problem hiding this comment.
[P2] Quote the explicit asset edge in the CLI: asset_edge_node is placed in AssetInfo here, but the preflight quote below uses only the separate last_hop flag. The CLI therefore displays and uses a fee cap for a different route, while Loop internally re-quotes with the asset edge and may fail with ErrSwapFeeTooHigh. Make asset_edge_node the effective LoopInLastHop and reject conflicting values.
Summary
requests
tapd, pin both to thenegotiated asset edge, and pass that peer to the server as the final hop
peer selection, and request validation
Testing
GOWORK=off go test ./...GOWORK=off make lint workers=4GOWORK=off make rpcGOWORK=off make docs-checkGOWORK=off make commitmsg-lint range="origin/master..HEAD"Pull Request Checklist
docs/release-notes/release-notes-next.md