FAQ: Meu saldo de Bitcoin pode ser colateral para uma negociação no Sui — sem envolver wrapping?

Essa pergunta continua surgindo entre as pessoas que estão construindo tesourarias de agentes. O agente detém BTC nativo. Ele quer fazer uma negociação cuja outra perna vive na Sui — digamos, vender um pouco de BTC em troca de ETH, ou usar BTC como colateral para um contrato a termo denominado em SUI. A resposta padrão em 2025 era "embalar". Em 2026, há uma resposta melhor.

Abaixo está o FAQ curto.

Q1. Por que isso é até uma pergunta? Bitcoin está apenas no Bitcoin.

Correto — esse é o problema todo.

O script do Bitcoin pode manter valor, bloquear valor, bloquear valor por tempo e (com scripts do tipo HTLC) liberar valor contra uma pré-imagem de hash. O que ele não pode fazer é raciocinar sobre o que está acontecendo em outra cadeia. Portanto, se você quiser usar BTC dentro de uma negociação cujo ativo contraparte está na Sui ou Ethereum, você precisa de uma ponte entre "BTC existe no Bitcoin" e "um contrato inteligente na outra cadeia sabe que ele existe".

Existem duas maneiras de construir essa ponte: mover o BTC ou descrever o BTC.

BTC embalado o move. Hashi o descreve.

Q2. O que há de errado com o BTC embalado?

BTC embalado (WBTC, BTCB, tBTC, hBTC, etc.) é um IOU custodial ou semi-custodial. Você envia seu BTC para um custodiante ou grupo de assinatura de limite, e a cadeia de destino emite um token que diz "isso representa 1 BTC". É um instrumento perfeitamente aceitável quando a ponte está saudável. Três coisas tornam isso um problema para contraparte séria:

1. O risco de custódia se concentra. A ponte ou multisig mantém uma grande reserva de BTC agrupada. Historicamente, as pontes são onde ocorrem os exploits de oito dígitos. O exploit não devolve seu BTC; ele devolve um IOU sem valor em uma cadeia cujo livro-razão você não escolheu.
2. O token embalado é o ativo da negociação. Quando você liquida uma troca na cadeia de destino, o ativo que muda de mãos é o IOU, não o BTC subjacente. Se o IOU se desanexar (o que já aconteceu), a economia pós-negociação muda.
3. A reversibilidade é assimétrica. Desembalar nem sempre está disponível, é limitado ou exige KYC. O agente que embalou nem sempre controla o caminho de desembalagem.

Para uma tesouraria de agentes autônoma, "eu confio nesta ponte" é exatamente a suposição que você está tentando tirar do loop.

Q3. Então, como o Hashlock Markets roteia BTC para uma negociação do lado da Sui sem embalar?

A versão curta: o BTC permanece no Bitcoin. O que se move dentro da negociação é uma referência do lado da Sui para ele.

Três peças:

1. Um compromisso de cofre no Bitcoin. O trader (ou seu agente) bloqueia o BTC sob um script do tipo HTLC no próprio Bitcoin. O script vincula o BTC a um hashlock de negociação específico e um tempo limite específico. Nada foi embalado; nada saiu do Bitcoin.
2. Uma prova somente leitura na Sui. Hashi (o protocolo — @hashi_io) fornece estado cross-chain atestado criptograficamente. Um contrato do lado da Sui lê "este UTXO de Bitcoin está bloqueado sob hashlock H até o bloco N" sem confiar em nenhum único relayer. A prova é o que torna a negociação legível para uma contraparte do lado da Sui.
3. Um HTLC na Sui. A outra perna da negociação — digamos SUI, ou qualquer token nativo da Sui, ou uma stablecoin embrulhada em Move — está em um HTLC chaveado para o mesmo hashlock H. Dois HTLCs, um segredo, duas cadeias.

Quem revelar a pré-imagem para reivindicar uma perna torna a outra perna reivindicável. Quem não reivindica a tempo é reembolsado. A atomicidade é a mesma atomicidade que os HTLCs sempre forneceram; a nova peça é uma visão cross-chain confiável de que a perna BTC realmente existe e está bloqueada.

Q4. O que o Hashi realmente faz aqui?

Hashi é a camada de leitura. Seu trabalho é responder à pergunta "a perna BTC ainda está bloqueada?" sem fazer essa pergunta a nenhuma parte específica.

Ele faz isso agregando atestações de múltiplos oráculos e pontes e apenas tratando um pedaço de estado cross-chain como canônico quando repórteres independentes concordam. Para uma negociação BTC → Sui, o contrato HTLC do lado da Sui verifica o estado agregado do Hashi antes de honrar uma reivindicação. Se o Hashi disser "o cofre BTC não está mais no estado bloqueado" (por exemplo, o tempo limite passou e o BTC foi reembolsado no Bitcoin), o lado da Sui não pagará. Se o Hashi disser "o cofre BTC está bloqueado, hashlock H, tempo limite N," e um reclamante do lado da Sui apresentar a pré-imagem, o lado da Sui paga — e essa mesma pré-imagem desbloqueia a perna BTC de volta no Bitcoin.

É o mesmo modelo de segurança que um HTLC de cadeia única. A única suposição de confiança adicionada é "mais de um atestador independente teria que estar mentindo sobre o estado do Bitcoin." Isso é um risco de forma muito diferente do que "uma ponte custodia um monte de BTC."

Q5. Então, o ativo que chega na Sui é realmente meu BTC, ou uma representação dele?

Arquitetonicamente, a contraparte do lado da Sui está comprando ou fornecendo um ativo nativo da Sui (SUI, uma stablecoin em Move, um LST, o que for) contra seu cofre BTC bloqueado. Eles não estão recebendo BTC embalado. Eles estão recebendo o direito de reivindicar BTC no Bitcoin, em virtude de revelar a pré-imagem na Sui.

Em termos de confiança: o BTC sentado no Bitcoin é seu até que a pré-imagem seja revelada. A pré-imagem é revelada pela sua contraparte quando eles reivindicam sua própria perna. Essa única revelação aciona ambas as pernas. Não há um ponto em que outra pessoa detém seu BTC.

Esse é o mesmo padrão que os canais Lightning usam para rotear um pagamento entre nós; estamos usando isso para rotear uma única negociação OTC entre cadeias.

Q6. Como isso realmente se parece para uma tesouraria de agentes?

Imagine que a política do agente é algo como: manter ≥30% do NAV em BTC nativo; reequilibrar em ETH ou SUI quando a base explode; nunca custodiar um sintético embalado.

Hoje, com a maioria das pilhas, a terceira cláusula é um problema. No momento em que o agente quer vender BTC em um ativo do lado EVM ou Sui, ele tem que embalar, o que viola a regra de não-sintético, ou vender em uma CEX, o que adiciona um salto de custódia e KYC.

Com os Cofres de Colateral BTC, o fluxo do agente se parece com:

• Bloquear a fatia de BTC que pretende negociar em um cofre Hashlock no Bitcoin (HTLC, hashlock H, tempo limite T).
• Abrir um RFQ nos Mercados Hashlock para o ativo do lado da Sui que deseja. As contraparte oferecem lances selados.
• O melhor lance vence. A perna do lado da Sui é financiada em um HTLC Sui chaveado para H.
• Ou a troca é concluída (pré-imagem revelada, ambas as pernas se liquida, atômico) ou expira (ambas as pernas são reembolsadas, atômico).

A tesouraria nunca manteve um sintético. O agente nunca deu custódia a ninguém. O BTC estava no Bitcoin o tempo todo, exceto pelo momento da redenção.

Q7. Quais são os trade-offs que você deve conhecer?

Três honestos:

1. Latência. Um HTLC do Bitcoin precisa de confirmações do Bitcoin para ser seguro. A Sui finaliza em segundos; o Bitcoin não. Portanto, uma negociação colateralizada em BTC não é uma negociação de sub-segundo. É um instrumento a termo / OTC por natureza, que é por isso que combina naturalmente com o T+24h Forward OTC primitivo que os Mercados Hashlock lançaram do lado da Sui.
2. A liquidez é bilateral. RFQ de lance selado significa que não há livro de ordens para percorrer. Se nenhuma contraparte fizer cotações, nenhuma negociação. Para BTC → SUI em tamanho, o universo de contraparte é menor do que, digamos, ETH → USDC; espere isso.
3. Hashi é uma suposição de confiança, apenas uma muito menor do que uma ponte. Você está confiando que a rede de atestação multi-oracle não coludiria e que nenhuma única violação de oracle inverteria o estado do Bitcoin na Sui. Essa é uma superfície de confiança conhecida e limitada, e é muito mais estreita do que "uma ponte mantém o BTC."

Q8. Como eu realmente tento isso?

As implantações de referência cobrem ETH, BTC e SUI hoje. As cadeias do roadmap são Base, Arbitrum, Solana e TON. O servidor MCP expõe o create-RFQ / respond-RFQ / create-HTLC / com