Se o seu agente de negociação pede um preço em voz alta, já pagou por isso

Este é um artigo curto e prático — uma dica de sábado em vez de uma análise profunda. Mas é um erro que continuo vendo no código de agentes de negociação, e vale trinta segundos da sua atenção.

Aqui está: no momento em que seu agente pede um preço, ele já deu algo em troca.

O fluxo de cotações ingênuo

Imagine um agente de negociação que quer vender 10 ETH por BTC. Para encontrar um preço, a movimentação óbvia é perguntar por aí. Transmita a intenção para um livro de ordens aberto, entre em contato com uma lista de formadores de mercado, coloque isso em um local público adjacente ao mempool. Colete as cotações que retornam, escolha a melhor e negocie.

Isso parece uma comparação de preços. Não é. É publicação.

Um pedido de cotação não é uma pergunta neutra. Ele carrega direção (você é um vendedor), tamanho (10 ETH) e — pelo fato de que você está perguntando agora — urgência. Qualquer um que veja o pedido antes de você negociar está lendo sua mão.

Três maneiras que vazam custos para você

Uma vez que sua intenção é visível, três coisas acontecem, e nenhuma delas é a seu favor.

Front-running. Uma parte mais rápida vê "vendedor de 10 ETH a caminho" e negocia antes de você, movendo o preço para o ponto que você estava prestes a pegar. Você chega atrasado à sua própria negociação.

Sombreamento de cotações. Formadores de mercado que podem ver que você é um vendedor comprometido — e podem ver o que seus concorrentes estão mostrando — silenciosamente ampliam suas cotações. Você não está recebendo o melhor preço deles. Você está recebendo o pior preço que eles acham que você ainda aceitará.

Última olhada. Este é o silencioso. Um formador mostra a você uma cotação atraente, você se compromete com ela e então — no momento entre seu compromisso e a liquidação — o formador reprecifica ou simplesmente recusa. "Desculpe, o mercado se moveu." A opcionalidade foi deles o tempo todo. Você carregou o risco; eles mantiveram a saída.

Seu agente acha que realizou um leilão competitivo. O que ele realmente fez foi anunciar sua posição e então dar aos contrapartes uma opção gratuita sobre isso.

O que uma RFQ de lance selado muda

Um pedido de cotação de lance selado inverte a assimetria de informação.

O agente publica uma RFQ. Os formadores submetem lances — mas os lances são selados: cada formador precifica o pedido sem ver os lances dos outros formadores e sem ver qualquer reação do tomador. Não há livro ao vivo para sombreamento, nenhum número de concorrente para cortar por um fio, nenhuma leitura de quão desesperadamente você quer a execução.

Quando a janela de lances fecha, o tomador vê os lances e escolhe o melhor. Crucialmente, o formador que cotou se comprometeu com aquele preço. Não há "deixe-me olhar novamente" — porque a próxima coisa que acontece é a liquidação, não uma renegociação.

Essa é a metade pré-negociação. A metade pós-compromisso é onde a liquidação atômica importa.

Lance selado mais liquidação atômica — por que ambos

Um lance selado remove o vazamento pré-negociação: ninguém sombra ou faz front-running em um pedido que não pode ler.

A liquidação atômica remove o vazamento pós-compromisso: a última olhada só existe porque há uma lacuna entre "concordado" e "liquidado" onde um lado ainda mantém uma opção. Feche essa lacuna e a opção desaparece.

Hashlock funde os dois em uma única operação. A RFQ e a liquidação não são etapas separadas que uma contraparte pode se interpor. O lance vencedor liquida através de um contrato de hash-timelock (HTLC): ou ambas as pernas da troca são concluídas, ou ambos os lados reembolsam. Não há estado em que o formador tenha reprecificado, saído ou mantido seu ativo. O prazo é imposto pela cadeia, não pelas boas intenções de ninguém.

Para um agente, tudo isso é algumas chamadas de ferramenta sobre o MCP — o protocolo aberto que a Anthropic introduziu para conectar modelos a sistemas externos. O servidor MCP expõe seis ferramentas; o caminho da RFQ é create_rfq para postar o pedido, list_open_rfqs para ver o que está ativo, respond_rfq para os formadores submeterem um lance selado, e as ferramentas de troca para liquidar o vencedor. Seu agente não gerencia timelocks ou observa a cadeia — ele chama uma ferramenta e obtém um resultado atômico.

Os limites honestos

Uma RFQ de lance selado não é uma capa de invisibilidade. Ela protege a fase de cotação — a janela onde sua intenção, de outra forma, seria legível e explorável. Uma vez que uma negociação é liquidada na cadeia, a transação de liquidação é pública, como qualquer outra; a licitação selada não remove e não pode esconder uma negociação concluída. O que ela remove é a opção gratuita que as contrapartes obtêm quando podem ver sua mão antes de você negociar.

E a habitual ressalva sobre o status da cadeia, porque mantemos isso honesto: a liquidação atômica está ativa de ponta a ponta na Ethereum mainnet hoje. Contratos Sui estão implantados e testados em CLI com a fiação do gateway em andamento; o P2WSH HTLC do Bitcoin está validado no signet com o mainnet ainda pendente. Quando este post diz "ativo", significa Ethereum mainnet.

A conclusão

Se você está construindo um agente de negociação, trate o pedido de cotação como parte da negociação, não como uma consulta gratuita antes dela. O spread mais barato do mundo não ajuda se chegar até ele vazar sua posição para todos que poderiam agir sobre isso.

Então aqui está a pergunta que eu realmente gostaria que os construtores refletissem: se fazer compras por um preço é em si um vazamento, quanto do que chamamos de "melhor execução" foi realmente o melhor — e quanto foi apenas o preço menos ruim que conseguimos depois de mostrar nossa mão?

Hashlock Markets — liquidação atômica para a economia dos agentes. RFQ de lance selado + liquidação HTLC, fundidos em uma única operação. Sem pontes, sem custodiante.

• Protocolo: https://hashlock.markets?utm_source=devto&utm_medium=referral&utm_campaign=2026-05-23-sealed-bid-rfq
• Servidor MCP (fonte): https://github.com/Hashlock-Tech/hashlock-mcp
• Para o design do mecanismo subjacente, há um artigo de trabalho no SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722