[feature]: PortfolioPilot - Outsourcing All Market and Portfolio-Related Decision-Making During RFQ

[ffranr]

Currently, the RFQ PriceOracle provides asset-to-BTC exchange rates, serving both wallet nodes and edge nodes. A key benefit of this setup is that tapd does not need to manage pricing decisions directly—these can be offloaded to an external service.

I propose extending this approach to limit orders as well. By limit order, I mean configurable rate and volume thresholds that an edge node can set to further restrict asset channel usage. While channel capacity already imposes constraints, limit orders add an additional layer of control. In our current implementation, these are referred to as "offers."

To enhance flexibility, all market, portfolio, and financial decision-making—not just price queries—should be handled by an external service. This is particularly important for edge nodes, as they require more nuanced control over pricing, limits, and execution policies.

Introducing PortfolioPilot

To support this, I think we should introduce a more generalized service, which I will call PortfolioPilot.

Proposed PortfolioPilot RPC Endpoints

• QueryAssetRates – Returns exchange rates (migrated from or integrated with the price oracle).
• IsQuoteAcceptable – Evaluates whether a peer's proposed quote meets acceptable conditions. If PortfolioPilot handles quote validation, it could also maintain an internal record of accepted/rejected quotes.
• QueryAssetChannelLimits – Returns the maximum allowable volume for a given asset and channel.
• PaymentUpdate – Updates PortfolioPilot on whether a quote was used, ensuring it remains synchronized with executed transactions.

By consolidating these responsibilities into PortfolioPilot, we can create a dedicated service for market intelligence, portfolio management, and financial decision-making, keeping tapd focused on its core role.

---

Notes

And then, if we go down this route, we can just remove RPC endpoints AddAssetSellOffer and AddAssetBuyOffer.

This sort of change should also allow us to get rid of price tolerance checks:

taproot-assets/rfq/negotiator.go

Lines 772 to 774 in 303f3da

	acceptablePrice := msg.AssetRate.Rate.WithinTolerance(
	assetRate.Rate, tolerance,
	)

It basically shrinks tapd and moves market/portfolio related decisions to a new service.

[ffranr]

Of course, we could default to a built-in PortfolioPilot that enforces the same price threshold check we currently use, while also allowing the option to specify an external RPC PortfolioPilot.

[GeorgeTsagk]

Moving a lot of the price and market related logic to external systems seems generally like a good move, and in this case it would help the daemon focus on a secure & efficient implementation of the protocol.

It is also important to note that the responsibilities of this "portfolio pilot" entity change quite a bit. The "oracle" (previous version with just QueryAssetRates) could also be used publicly as it provides bid/ask prices on assets. The portfolio pilot acts upon a user's balance/channel state, making it less desirable to expose publicly.

The portfolio pilot seems very handy for a competitive edge node, but we also need to keep the simple tapd runner's setup in mind.