Boltz

Comece pelo sentido da troca. Se você tem bitcoin na cadeia principal e quer abastecer uma carteira Lightning, usa um Submarine Swap: paga on-chain, por uma transação registrada na blockchain, e recebe por Lightning. O Reverse Swap faz o caminho inverso. Você paga uma fatura Lightning, uma solicitação de pagamento com os dados necessários, e passa a poder retirar fundos na cadeia. O Chain Swap conecta duas cadeias, como Bitcoin e Liquid. Nos dois últimos casos, seu aplicativo precisa transmitir um claim, a transação que efetivamente recolhe os fundos. Pagar não encerra, portanto, sua parte do processo. Além disso, na Liquid você recebe L-BTC, um ativo dessa rede separada, e não uma saída comum da cadeia principal Bitcoin. Confira também a rede de destino antes de confirmar. [1]

Imagine que o servidor envie um endereço e um valor a pagar. Sem outras verificações, você apenas confia que eles correspondem à troca combinada. O cliente Boltz, o aplicativo no seu dispositivo, deve calcular o valor e conferir o hash de pagamento da fatura Lightning. Esse hash é uma impressão digital calculada que vincula o pagamento ao swap correto. O aplicativo também verifica o endereço e o script, as condições que determinam quem pode gastar os fundos e quando. Com Taproot, uma maneira de construir uma saída Bitcoin, isso inclui as chaves e a árvore de scripts, que organiza as possíveis condições de gasto. O usuário comum não precisa calcular tudo manualmente; precisa de um cliente que realmente confira. O código aberto de boltz-web-app permite examinar a implementação, mas não comprova, sozinho, que outra integração ou o aplicativo carregado no navegador esteja correto. [5] [9]

Um endereço de swap não é uma conta para juntar o valor necessário aos poucos. A documentação Boltz exige uma única transação lockup, o envio inicial que bloqueia os fundos pelas regras da troca. Pagamentos posteriores ao mesmo endereço não são somados: só o primeiro é usado no swap. Se você mandar menos por engano, não envie automaticamente a diferença. Em um Chain Swap, o cliente pode oferecer uma nova cotação com base no valor recebido, em vez de devolvê-lo. Deve restar tempo suficiente, o valor precisa respeitar os limites e nenhuma assinatura de refund, ou devolução, pode ter sido criada. O serviço também precisa ter fundos disponíveis. É um procedimento específico para um Chain Swap financiado incorretamente, não uma autorização para completar qualquer transferência que falhou. [2] [8]

Para comparar custos, acompanhe todo o percurso, não só a porcentagem anunciada. Boltz cobra pelo serviço, e as transações nas respectivas cadeias têm custos próprios. Em um Reverse Swap, o dado técnico onchainAmount representa o valor que Boltz bloqueia para você após considerar a taxa do lockup feito pelo próprio serviço. Esse ainda não é o valor líquido recebido na carteira: falta pagar seu claim, a transação que recolhe os fundos. Em um Chain Swap, você também paga sua transação de envio inicial. Compare, portanto, o gasto total com o recebimento final. Taxas, mínimos e limites dependem do sentido e do par de redes e podem variar com as condições da rede. Um exemplo antigo de publicidade não é uma cotação atual. [6]

Se um Submarine Swap ou Chain Swap falhar depois do envio dos fundos, recuperá-los pode exigir uma transação sua. Você precisa da chave de refund e dos dados do swap guardados. Com Taproot, a cooperação de Boltz pode permitir um key path refund mais rápido: uma devolução assinada em conjunto, sem esperar a condição de tempo. Sem cooperação, o script path permite devolver os fundos pelo script previsto depois de cumprido o timelock, a restrição temporal nas regras da transação. Essa possibilidade não transmite nada sozinha; o cliente precisa agir. Já cancelar um pagamento Lightning ainda não liquidado em um Reverse Swap libera os fundos pendentes de volta. É outro caso, que não implica recuperação automática após toda falha do aplicativo ou um claim perdido por falta de tempo. [3]

No Reverse Swap, liquidar o pagamento Lightning e recolher seus fundos na cadeia são eventos diferentes. O estado invoice.settled pode significar que Boltz recebeu o preimage, um valor secreto que permite completar o pagamento ligado ao seu hash. O servidor não acompanha se o aplicativo realmente transmite o claim em seguida. Por isso, o cliente deve verificar a própria saída, os fundos destinados a você, e recolhê-la antes do timeout, o limite após o qual a outra parte pode recuperá-la. Aplicativo fechado, dados perdidos ou taxa insuficiente podem dificultar o término. Uma notificação pode despertar o aplicativo, mas não substitui uma transação transmitida. Avalie o resultado pelo recebimento real, não apenas por uma mensagem verde de sucesso. [1] [2]

Um backup normal da carteira pode não conter tudo de que um swap pendente precisa. Boltz Rescue Key é um conjunto de palavras de backup para um método compatível de recuperação. Swap Restore reconstrói com ele os swaps UTXO suportados, que usam saídas individuais de transações ainda não gastas. O cliente deriva um xpub, uma chave pública estendida para localizar swaps relacionados, e as chaves privadas correspondentes. O claim também exige recuperar corretamente o preimage. Um seed qualquer, o segredo inicial de outro aplicativo, não serve automaticamente: método de derivação e formato de recuperação devem coincidir. As chaves privadas permanecem no dispositivo. O xpub enviado não permite gastar, mas revela seu histórico de swaps ao servidor Boltz. Por isso, guarde os registros do cliente específico e eventuais arquivos refund antigos junto com o backup habitual da carteira. [4] [2]

Uma transação pode aparecer na rede antes de entrar em um bloco. Aceitá-la nesse momento é chamado de 0-conf, sem confirmações. A documentação Boltz diz que o serviço não aceita esses depósitos de usuários na cadeia principal Bitcoin por causa da adoção de full-RBF. Essas regras permitem, sob certas condições, substituir uma transação não confirmada por outra com taxa maior, mesmo sem sinalização inicial dessa possibilidade. No Reverse Swap, por outro lado, o destinatário assume o risco se aceitar uma transação não confirmada. Não se deve estender as regras de um par de redes a todos os outros. Documentação acessível tampouco prova que o serviço tenha agora fundos suficientes para sua transferência. Antes de pagar, confira os parâmetros atuais, o tempo disponível e o estado daquele swap. [7] [6]