Atomicidade em Negociações Multi-perna: Quando uma Pré-imagem Deve Liquidar Três Pernas de Uma Vez

Um agente autônomo inicia uma negociação de três pernas. Primeira perna: ele paga BTC e recebe ETH. Segunda perna: ele roteia esse ETH para uma segunda contraparte por USDC. Terceira perna: esse USDC é liquidado para um fornecedor por uma reserva de computação. As pernas um e dois se liquidam. Então a terceira contraparte fica em silêncio.

O agente agora está segurando USDC que nunca quis, a um preço que já se moveu contra ele, sem nenhuma maneira de reverter as duas primeiras pernas. Ele não perdeu a negociação. Ele perdeu o controle de seu próprio inventário.

Esse é o modo de falha que as trocas atômicas de uma única perna não abordam, e é o que os agentes autônomos enfrentam constantemente, porque a "negociação" de um agente raramente é um único salto. É um caminho. Este post é sobre tornar todo o caminho atômico: ou cada perna se liquida, ou cada perna se desfaz, sem um estado intermediário onde alguém fique segurando o ativo errado.

Liquidar-então-esperar é o padrão, e é o problema

Veja como uma negociação de múltiplos saltos é executada hoje sem atomicidade. Você liquida a perna um. Então você tenta a perna dois. Então você tenta a perna três. Cada "tentativa" é uma nova negociação com novo risco. Chame isso de liquidar-então-esperar.

Cada salto intermediário carrega três custos que se acumulam ao longo do caminho:

• Risco de inventário. Entre as pernas, você está segurando um ativo que não queria segurar. Para um agente de criação de mercado, isso às vezes é aceitável. Para um agente que executa um caminho direcional, é pura exposição.
• Risco de preço. O mercado se move enquanto você está no meio do caminho. A cotação que tornou a perna três valiosa no início pode estar submersa quando as pernas um e dois se liquidam.
• Risco de contraparte. A contraparte de cada perna pode simplesmente não aparecer, como a terceira fez acima. Você fica preso no salto que alcançou.

A maioria da infraestrutura de liquidação financiada que está sendo lançada este ano otimiza extremamente bem o caso de uma perna ou o caso de duas partes. A liquidação de trilhos de pagamento e mesas OTC atômicas tornam uma troca entre duas partes segura. Isso é real e útil. A atomicidade de múltiplas pernas é um problema diferente: trata-se de vincular N pernas através de N contrapartes e possivelmente N cadeias em um único destino de liquidação. Resolver a perna única não resolve o caminho.

O truque central: um segredo controla cada perna

Contratos de hash-time-lock já nos dão atomicidade para duas partes. A Parte A bloqueia fundos atrás de hash(s). A Parte B bloqueia os fundos correspondentes atrás do mesmo hash(s). Quando A revela s para reivindicar os fundos de B, a revelação é pública, então B usa o mesmo s para reivindicar os fundos de A. Atômico: ou s é revelado e ambas as pernas se completam, ou nunca é revelado e ambas reembolsam após um tempo limite.

A extensão para múltiplas pernas é quase embaraçosamente direta: use o mesmo hashlock H = hash(s) em cada perna do caminho. Uma única pré-imagem s então controla toda a cadeia.

Perna 1:  A --BTC--> B    bloqueado atrás de H
Perna 2:  B --ETH--> C    bloqueado atrás de H
Perna 3:  C --USDC--> D   bloqueado atrás de H

s revelado uma vez  =>  o hashlock de cada perna se abre
s nunca revelado =>  cada perna reembolsa

Não há um estado intermediário "perna um concluída, perna dois pendente" em que um agente possa ficar preso, porque nenhuma perna pode ser concluída sem s, e no momento em que s é público, cada perna pode ser concluída. O caminho se liquida como uma unidade.

A parte que realmente requer cuidado: a escada de tempo

A versão ingênua acima tem um erro fatal de tempo. Quem revelar s primeiro o expõe a todos. Se os tempos limites forem iguais, a última parte a reivindicar pode descobrir que a janela de reembolso de sua contraparte já foi aberta, permitindo que essa contraparte pegue o reembolso e a reivindicação do segredo revelado.

A solução é uma escada de tempo decrescente. A parte que revela o segredo deve ser a última cuja segurança está em risco, então cada perna a montante recebe estritamente mais tempo:

Tempo limite da perna 1:  T0 + 12h   (mais longo — A revelou primeiro, precisa da maior margem de segurança)
Tempo limite da perna 2:  T0 +  8h
Tempo limite da perna 3:  T0 +  4h   (mais curto — D reivindica primeiro, acionando a cascata para cima)

A parte a jusante reivindica primeiro, o que publica s, o que dá a cada parte a montante tempo suficiente restante para reivindicar antes que sua própria janela de reembolso se abra. Este é o mesmo argumento de segurança que faz o roteamento de pagamentos Lightning funcionar, generalizado de um caminho de pagamento para um caminho de negociação heterogêneo e cross-chain.

A consequência que vale a pena internalizar: o pior caso de bloqueio de capital é definido pela mais longa perna na escada, e se aplica a todas as partes simultaneamente. Um caminho de cinco pernas bloqueia o capital de todos por toda a duração do degrau mais alto.

Onde quebra, honestamente

Se apenas descrevêssemos o caminho feliz, isso seria marketing. A construção tem limitações reais e nomeadas, e um agente decidindo se deve usá-la precisa delas:

• O problema da opção gratuita. O detentor do segredo pode observar o mercado depois que todas as pernas estão bloqueadas e escolher se deve revelar. Essa é uma opção gratuita com valor proporcional à volatilidade e ao tempo de bloqueio. As mitig ações são janelas curtas, uma taxa não reembolsável que o detentor do segredo perde em caso de não conclusão, ou colateral postado. Nenhuma delas torna a opção exatamente zero.
• Bloqueio de capital escala com a contagem de pernas. Cada perna é bloqueada ao mesmo tempo, pela duração do pior caso. Um caminho longo é caro para manter aberto.
• Suposição de vivacidade. Alguém precisa entrar online para revelar s dentro da janela. A atomicidade protege os fundos — ninguém perde dinheiro — mas uma parte de ataque pode forçar todo o caminho a se desfazer ao ficar inativa. Você obtém segurança, não garantia de conclusão.
• Compatibilidade da função hash entre cadeias. Um caminho cross-chain é atômico apenas se cada cadeia puder verificar o mesmo hash da mesma pré-imagem. SHA-256 é a escolha portátil; uma perna em uma cadeia cujo hash nativo barato é Keccak precisa do caminho SHA-256 explicitamente, ou a propriedade de segredo compartilhado quebra silenciosamente.

A atomicidade multi-perna é estritamente mais segura do que liquidar-então-esperar na dimensão que mais importa para um agente — você nunca pode ficar preso no meio do caminho segurando o ativo errado — mas compra essa segurança com eficiência de capital e uma exigência de vivacidade. Essa é a troca. Declare isso claramente para qualquer um que esteja integrando.

Como um agente expressa isso através do MCP

O objetivo de colocar isso atrás de um servidor MCP é que o agente deve descrever um caminho, não orquestrar saltos manualmente. Um RFQ de lance fechado carrega o conjunto completo de pernas — os ativos, as cadeias, os slots de contraparte e o único hashlock que os vinculará. Os respondentes fazem lances nas pernas; o conjunto combinado compartilha um H; a escada de tempo é derivada do comprimento do caminho e das cadeias envolvidas. O agente raciocina sobre um resultado de liquidação, não três independentes.

A realidade do status da cadeia, declarada exatamente como está hoje: a mainnet Ethereum está ao vivo de ponta a ponta. HTLCs do Bitcoin estão validadas por signet, mainnet pendente. Contratos Sui estão implantados e testados em CLI, com fiação de gateway em andamento. Um caminho que toca todos os três é construível em partes hoje e de ponta a ponta à medida que essas pernas entram online; a perna BTC-para-ETH do exemplo de abertura é a parte que está ao vivo agora. Sem ponte, sem custódia, sem ativo embrulhado em nenhum salto.

A distinção que vale a pena manter

"Camada de liquidação" passou a nomear várias coisas diferentes este ano — pag