Four providers quoted Lightning

The requests named a chain the providers had never heard of. None of them said so. Each took the ticker, ignored the part it did not recognise, priced ordinary Bitcoin and returned it with no indication that it had answered a different question.

The tell was that the figures were exactly the on-chain ones. Not close — equal, to every digit. A fourth provider, asked using its own code for Lightning, answered a genuinely different number, which is what support actually looks like from outside.

A comparison built on those four answers would have ranked three on-chain quotes against one Lightning quote and declared a winner. The winner would usually have been one of the three, because an on-chain payout costs less than a Lightning one at the sizes people send — so the board would have recommended, consistently and confidently, a provider that could not do the thing being asked for.

Worse than a wrong price: an order created that way would hand a provider a Lightning invoice in the field where it expects an address. What happens next is that provider’s error handling, and nothing on this side gets a say.

So support for a network is now something a provider demonstrates rather than something inferred from an answer arriving. One provider is on that list. The other twelve are reported as not supporting it, which is true and is better than a quote that means something else.

The general version: a provider that returns a number has not necessarily understood the question. When a new dimension is added to a request — a chain, a rate mode, a currency — the first thing to check is not whether the answer is plausible, but whether it changed at all.