Seis ferramentas MCP, um comércio: conduzindo um agente de IA de RFQ a reembolso

A maior parte da escrita sobre comércio de agentes permanece na altitude do diagrama de camadas: trilhos aqui, liquidação ali, limites de confiança entre eles. Útil, mas abstrato. Hoje vamos ao nível do chão e percorrer o que realmente acontece - chamada por chamada - quando um agente de IA negocia com um estranho e nenhum custodiante está em qualquer parte do processo.

Todo o ciclo de vida se encaixa em seis ferramentas MCP. Qualquer modelo capaz de MCP pode operá-las; não há SDK para integrar e nenhum serviço de assinatura para confiar. O pacote é hashlock-tech/mcp (escopado) no npm, e tudo abaixo funciona de ponta a ponta na mainnet do Ethereum hoje.

Fase 1: Descoberta de preço - três ferramentas

create_rfq é onde uma negociação começa. O agente do tomador transmite um pedido de cotação: par, tamanho, direção, expiração. A decisão de design importante é que o RFQ é sealed-bid - os criadores que respondem não podem ver as cotações uns dos outros. Para mesas OTC humanas, isso é um detalhe. Para agentes, é fundamental: um criador autônomo que pode observar cotações concorrentes irá ajustar seu preço em relação a elas em milissegundos, toda vez, para sempre. Cotações seladas forçam cada criador a cotar seu verdadeiro preço.

list_open_rfqs é o lado do criador da descoberta. Um agente de formação de mercado consulta RFQs abertos, filtra por par e tamanho, e decide o que cotar. Esta é a ferramenta que transforma um protocolo de liquidação em um mercado de dois lados - o fluxo precisa ser encontrável.

respond_rfq envia a cotação. O agente do tomador coleta respostas até a expiração, escolhe a melhor e avança para a liquidação. Note o que não aconteceu ainda: nenhum fundo foi movido, nenhuma aprovação concedida, nenhum contraparte confiável. A descoberta de preço é rica em informações e financeiramente inerte - exatamente a propriedade que você deseja antes que um agente não supervisionado comprometa capital.

Fase 2: Liquidação - duas ferramentas, um segredo

create_htlc bloqueia a primeira perna. O tomador compromete fundos em um contrato de hash-time-locked: um hashlock (apenas o detentor de uma pré-imagem secreta pode reivindicar) mais um timelock (após a janela, os fundos são reembolsados ao remetente). Comprometido, não transferido. O criador então bloqueia a perna espelho na outra cadeia contra o mesmo hash.

withdraw_htlc é a reivindicação. Quando o tomador retira a perna do criador, o ato de reivindicar revela a pré-imagem na cadeia - que é precisamente o que o criador precisa para reivindicar a perna do tomador. Um segredo limpa ambas as pernas. Não há estado do mundo onde um lado tenha ambos os ativos e o outro não tenha nenhum. É isso que "atômico" significa quando não é uma palavra de marketing: não "rápido", não "um solucionador pré-pago que reconciliará depois" - uma garantia criptográfica de que a negociação é concluída em ambas as pernas ou em nenhuma.

Nenhum juiz decide que a negociação está completa. A conclusão é a revelação do segredo. Compare isso com designs de escrow-e-evaluator, onde uma terceira parte decide se as obrigações foram cumpridas - uma instituição humana reconstruída em Solidity.

Fase 3: O desmantelamento - a ferramenta que ninguém anuncia

refund_htlc é a sexta ferramenta e, para operação autônoma, a mais importante. Se a janela expirar - a contraparte desapareceu, a cotação ficou obsoleta, o agente travou no meio do fluxo - o timelock devolve os fundos. Ninguém para peticionar, nenhum ticket de suporte, nenhum processo de disputa. O modo de falha de todo o sistema é "você recebe seu dinheiro de volta".

Essa propriedade vale a pena refletir, porque é a diferença entre um protocolo que você pode demonstrar e um protocolo que você pode deixar funcionando. Um agente não supervisionado eventualmente encontrará todos os modos de falha que existem. Se algum desses modos de falha for "fundos estão presos aguardando uma decisão humana", você não tem liquidação autônoma - você tem liquidação supervisionada com etapas extras.

A extensão futura

Aqui é onde o primitivo se torna mais interessante do que uma troca à vista. Nada na construção do HTLC diz que a janela de liquidação deve ser agora. Estenda o timelock e as mesmas seis chamadas vinculam um forward: dois agentes concordam com um preço hoje, ambas as pernas se comprometem hoje, e a janela de reivindicação se abre em T+24h (ou T+7d). Entre o acordo e a liquidação, nenhum custodiante retém margem, nenhuma câmara de compensação garante desempenho, nenhum escritório de crédito avalia o risco da contraparte. Se ambos os lados aparecerem, uma pré-imagem limpa ambas as pernas. Se um lado não aparecer, o caminho de reembolso do outro é executado.

Esse é o vazio que os trilhos de pagamento não abordam. x402, AP2, a nova prévia de pagamentos do AgentCore da AWS - esses movem um ativo conhecido, uma direção, agora mesmo, e estão realmente se saindo bem nisso. Mas um trilho não pode vincular uma obrigação cruzada de dois lados, que liquida mais tarde. Isso requer um primitivo de liquidação, e os trilhos eventualmente precisarão de um por baixo deles.

Onde isso funciona hoje

Honestidade de cadeia-reivindicação, porque a economia de agentes já tem muitas reivindicações excessivas: a mainnet do Ethereum está ao vivo de ponta a ponta - tudo neste walkthrough funciona lá agora. Contratos Sui estão implantados e testados via CLI, com fiação de gateway em andamento. O Bitcoin está validado no signet, mainnet pendente. O design do protocolo está documentado em nosso artigo SSRN (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722) para aqueles que desejam o tratamento formal.

Documentos e a referência completa da ferramenta: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-07-03-forward-tool-walkthrough - GitHub: https://github.com/Hashlock-Tech/hashlock-mcp

Aqui está a pergunta que continuo voltando: das seis ferramentas, cinco recebem toda a atenção, mas refund_htlc faz o trabalho que torna a operação não supervisionada possível. Se você está construindo agentes que tocam valor - como é o modo de falha do seu stack?