---
title: "Contrato com bloqueio por hash e tempo (HTLC)"
description: "Um HTLC permite resgatar um pagamento com uma pré-imagem antes do vencimento e reembolsá-lo por outro caminho depois. Entenda como coordena canais de pagamento e swaps atômicos e onde pode falhar."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Contrato com bloqueio por hash e tempo (HTLC)

> Somente para fins educacionais; não constitui aconselhamento de investimento, jurídico ou de segurança. A segurança de um HTLC depende dos scripts ou contratos exatos, das regras das redes, da política de confirmação, das taxas, do monitoramento e da ação em tempo hábil.

<a id="answer"></a>

## Resposta direta

Um contrato com bloqueio por hash e tempo (HTLC) é um pagamento condicional com dois caminhos de gasto concorrentes. Antes do vencimento, o recebedor pode resgatar ao revelar um valor `x` cujo hash corresponda ao valor comprometido `h = H(x)` e cumprir as assinaturas ou autorizações exigidas. Depois, o pagador pode usar o caminho de reembolso. A ordem exata no limite é definida pela rede e pelo contrato, não pela palavra "antes".

O hash lock conecta ações: conhecer a mesma pré-imagem pode permitir liquidar um pagamento de entrada relacionado após pagar um de saída. O time lock limita o período condicional. Canais de pagamento usam essas propriedades para encaminhar pagamentos; swaps atômicos podem coordenar transferências em sistemas distintos.

Um HTLC não é automaticamente sem confiança, atômico, privado ou autoexecutável. Também depende de código correto, hash e codificação compatíveis, vencimentos escalonados, premissas de finalidade, acesso a taxas, monitoramento e confirmação antes do prazo. O HTLC da Lightning é um projeto Bitcoin especificado; contratos em outras redes podem ter semântica diferente.

- **Ramo de hash:** revele a pré-imagem e cumpra a autorização de sucesso enquanto o caminho for válido.
- **Ramo de tempo:** cumpra a autorização de reembolso quando o bloqueio absoluto ou relativo vencer.

<a id="mechanism"></a>

## Como funciona

Em um pagamento, Bob escolhe uma pré-imagem nova e imprevisível `x`, calcula `h = H(x)` e entrega `h` a Alice. Alice bloqueia fundos sob regras que comprometem `h`, identificam as partes autorizadas e fixam o vencimento `T`.

- Alice confere algoritmo, codificação, valor, ativo, recebedor, destino de reembolso, rede e vencimento antes de financiar.
- Bob verifica a saída realmente financiada ou o contrato implantado, não um rascunho ou a interface.
- Se Bob resgatar pelo ramo de sucesso, fornece `x`; a lógica verifica `H(x) = h` e a autorização.
- Publicar ou transmitir `x` pode permitir a Alice ou a um intermediário liquidar outro HTLC com o mesmo hash de pagamento.
- Se o sucesso não for usado a tempo, o reembolso torna-se elegível em `T`; isso não o transmite nem confirma.
- Ainda é preciso preparar ou guardar a transação, pagar taxa suficiente, enviá-la, vigiar substituições e conflitos e obter confirmações.
- Depois de revelar `x` a uma contraparte ou rede pública, trate-o como público e não o reutilize em outra condição.

Bitcoin distingue bloqueios absolutos e relativos. `OP_CHECKLOCKTIMEVERIFY` do BIP 65 impede o gasto até a altura ou tempo de bloco codificado pelo locktime; `OP_CHECKSEQUENCEVERIFY` do BIP 112 aguarda idade relativa suficiente da entrada. Os campos da transação também devem ser compatíveis. Um time lock é uma regra de validação, não um agendador.

Na Lightning, `update_add_htlc` leva valor, `payment_hash` e `cltv_expiry`. Cada salto oferece um HTLC de saída que vence antes do HTLC de entrada correspondente, deixando tempo para aprender a pré-imagem e resgatar a montante. O BOLT 3 define saídas de compromisso, caminhos `HTLC-success` e `HTLC-timeout`, assinaturas, revogação, corte por poeira e atrasos; o esboço de dois ramos não implementa um canal completo.

<a id="example"></a>

## Exemplo

Considere, apenas para ensino, Alice trocando `1 BTC` pelos `20 ETH` de Bob. O exemplo mostra somente a ordem: produção exige código revisado para cada rede e não deve copiar estes prazos nominais.

- Alice gera novos `x` e `h = H(x)` e bloqueia `1 BTC` para Bob resgatar com a pré-imagem e Alice reembolsar após `48 hours`.
- Após verificar a transação Bitcoin e a política de confirmação, Bob bloqueia `20 ETH` com hash e codificação compatíveis; o caminho de Alice termina após `24 hours` e depois há o reembolso de Bob.
- Antes de revelar `x` para resgatar `20 ETH`, Alice verifica ID da rede Ethereum, bytecode, endereço, ativo, valor, partes, `h` e os dois caminhos invocáveis.
- Bob obtém `x` do resgate ou da mensagem acordada e tenta o caminho de sucesso Bitcoin antes do prazo posterior.
- Se a troca parar antes da revelação, cada reembolso só fica elegível pelas regras de sua rede; cada parte deve enviá-lo e confirmá-lo.

A diferença entre `48 hours` e `24 hours` é uma margem de reação, não um parâmetro universalmente seguro. Modele reorganizações, tempo de bloco, finalidade, execução, relés, mempool, taxas, censura e latência nos dois sistemas. A segunda parte não deve avançar só porque a interface diz "confirmado".

<a id="risks"></a>

## Riscos

- **Compromisso errado:** algoritmo, comprimento ou codificação diferem e o mesmo `x` não funciona nos dois lados.
- **Artefato errado:** saída, ID de rede, endereço, bytecode, ativo, valor, recebedor ou reembolso divergem da interface.
- **Ordem insegura:** prazos iguais ou próximos impedem resgate a montante após pagamento a jusante.
- **Erro de limite:** altura, tempo de bloco, timestamp, idade relativa e comparações `<` e `<=` não equivalem.
- **Sem reembolso automático:** maturidade só valida o gasto; carteira, nó, usuário ou vigia precisa agir.
- **Taxa e poeira:** o resgate pode ser antieconômico, cortado na Lightning, ficar preso ou exigir o ativo nativo de taxa.
- **Confirmação e reorganização:** ver transação ou pré-imagem não significa liquidação irreversível.
- **Corrida e congestionamento:** sucessos, timeouts, substituições, conflitos ou atrasos maliciosos consomem a margem.
- **Implementação:** falhas de script, contrato, carteira, assinatura, nonce, RPC ou cliente podem invalidar os caminhos.
- **Monitoramento:** uma parte offline pode perder revelação, vencimento, fechamento forçado, substituição ou último momento útil.
- **Privacidade:** hashes reutilizados, pré-imagens, valores, horários e eventos podem correlacionar transferências.
- **Opcionalidade e bloqueio:** uma parte pode imobilizar liquidez e desistir; conclusão e compensação não são garantidas.

Antes de arriscar valor, teste sucesso e reembolso com quantia insignificante, registre artefatos e prazos, reserve taxas e atribua monitoramento e transmissão em falhas.

<a id="misconceptions"></a>

## Equívocos comuns

- **"Os fundos voltam automaticamente no vencimento."** Em geral só se habilita o reembolso; alguém deve transmiti-lo e confirmá-lo.
- **"Cumprir `H(x) = h` é o contrato inteiro."** Assinaturas, ramos, campos, regras, revogação e autorização também importam.
- **"O mesmo vencimento nos dois lados é justo."** Intermediário ou segundo ator precisa de margem a montante após conhecer `x`.
- **"Uma pré-imagem visível garante tempo para resgatar."** Confirmações, reorganização, congestionamento, taxas e censura podem esgotá-lo.
- **"Atômico significa duas redes mudando numa transação indivisível."** Estados separados são coordenados; aborto, reembolso e estados unilaterais temporários continuam possíveis.
- **"HTLCs são anônimos e eliminam toda confiança."** Vazem sinais e dependem de código, redes, chaves, monitoramento e operação.

<a id="related"></a>

## Tópicos relacionados

- [Hash criptográfico](/pt-br/crypto/cryptographic-hash/)
- [Carteira MPC](/pt-br/crypto/mpc-wallet/)
- [Risco de módulo multissig](/pt-br/crypto/multisig-module-risk/)
- [Contrato inteligente](/pt-br/crypto/smart-contract/)
- [Canais de estado](/pt-br/crypto/state-channels/)

<a id="sources"></a>

## Fontes

- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (acesso: 2026-08-20)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (acesso: 2026-08-20)
- [BOLT #2: protocolo de pares para canais](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs (acesso: 2026-08-20)
- [BOLT #3: formatos de transações e scripts Bitcoin](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs (acesso: 2026-08-20)
- [BOLT #4: protocolo de roteamento onion](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs (acesso: 2026-08-20)

Source: https://wiki.fcontext.com/pt-br/crypto/htlc/index.mdx