Um LSP é contraparte e prestador, não parte do consenso Bitcoin; o cliente pode manter suas próprias keys, mas deve avaliar preço, disponibilidade, termos do canal e o trust model específico do protocolo LSPS usado.
Um Lightning Service Provider emprega liquidez própria ou adquirida para clientes. Normalmente abre um canal para uma wallet non-custodial obter inbound capacity, ou liga fundos on-chain e off-chain por swap; cobra por block space, capital, operação e risco. [1]
A capacidade de um canal Lightning é fixa e dividida entre local e remote balance. Assim, uma wallet nova sem canal não recebe um pagamento comum apenas criando uma invoice; o LSP fornece inbound liquidity sem o usuário escolher manualmente peer, UTXO e parâmetros de funding transaction. [1]
LSPS0, agora bLIP 50, unifica a comunicação client-LSP como JSON-RPC 2.0 sobre o transporte peer-to-peer Lightning BOLT8. Toda mensagem LSPS usa message ID 37913, e lsps0.list_protocols devolve as extensões exatas; o rótulo LSP não garante cada serviço. [2]
LSPS1, ou bLIP 51, padroniza uma order direta de canal. O client lê a offer, cria a order, confere capacity, price e expiry e paga on-chain ou por Lightning; a specification diz que a purchase não é atomic e o client confia no LSP para entregar o channel ou executar o refund previsto. [3]
LSPS2, ou bLIP 52, trata de just-in-time channel. O client recebe parameters e põe na invoice um route hint com request identifier; quando o incoming payment chega ao LSP, o provider abre um zero-confirmation channel, desconta a opening fee e envia o restante. O client deve estar conectado nesse momento. [4]
Um LSP non-custodial não guarda as private keys do client e deixa a ele seu lado do channel, mas permanece dependência operacional. O provider vê a conexão direta e parte do payment flow, pode negar liquidity, mudar o price dentro da offer ou ficar offline; zero-confirmation channel e prepaid order têm riscos distintos. [1]
Os padrões LSPS0, LSPS1 e LSPS2 passaram do repository original ao processo bLIP como bLIP 50, 51 e 52 ativos. A reference library lightning-liquidity implementa client handlers LSPS1 e LSPS2 e um service handler LSPS2, mas uma wallet ou node específica pode suportar apenas um subset sob termos próprios. [5]
Antes de usar, verifique node ID e connection string do LSP, resultado de lsps0.list_protocols, capacity e balance split exatos, fee, expiry, confirmations e refund policy. Depois da abertura, confira funding transaction, channel state e inbound capacity real; logo ou invoice criada não provam essas propriedades. [2]
Para ter uma visão mais completa, leia este verbete junto com Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. Também há referências a este verbete em Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Um Lightning Service Provider é automaticamente custodial?+
Não. Um LSP pode abrir canal para uma wallet que guarda suas keys e administrar somente seu lado. O client ainda depende de availability, liquidity offer e cumprimento da order.
02Um LSP permite receber o primeiro payment sem channel anterior?+
Sim, se wallet e provider suportarem LSPS2 e o payment cobrir a opening fee. O LSP abre um JIT channel quando o pagamento chega e desconta a fee; não é inbound capacity gratuita nem incondicional.