Integre Claude ao Hashlock Markets em 10 minutos: um tutorial prático de MCP

Hashlock Markets é uma plataforma de negociação de criptomoedas baseada em intenção, construída em torno de duas ideias que o DeFi tem discutido há anos, mas raramente implementadas juntas: RFQ de lance selado, para que as cotações sejam privadas, e liquidação atômica HTLC, para que as negociações entre cadeias sejam concluídas ou revertidas como uma unidade, sem custódia no meio. Sentado à frente de ambos está um servidor do Protocolo de Contexto do Modelo (MCP), o que significa que qualquer agente de IA compatível com MCP — Claude, GPT, um runtime personalizado — pode conduzir todo o ciclo de vida da negociação sem um humano no console.

Este post é a versão curta e prática: como configurar isso, o que cada parte faz e as chamadas de ferramentas específicas que um agente fará em uma negociação normal.

Se você quiser a página inicial do protocolo, ela está em hashlock.markets. O repositório canônico é github.com/Hashlock-Tech/hashlock-mcp.

Passo 1: escolha um transporte

Existem duas maneiras de conectar um agente ao servidor Hashlock MCP.

stdio (local). Seu agente inicia o servidor como um processo filho. Configure-o como qualquer outro servidor MCP em seu cliente de escolha:

{
  "mcpServers": {
    "hashlock": {
      "command": "npx",
      "args": ["-y", "@hashlock-tech/mcp"]
    }
  }
}

Esta é a opção mais rápida para desenvolvimento. O pacote é instalado automaticamente do npm, o nome escopado é @hashlock-tech/mcp, e você não precisa se preocupar em hospedar nada.

Streamable HTTP (hospedado). Aponte seu agente para:

https://hashlock.markets/mcp

Esta é a escolha certa para qualquer runtime de agente que possa falar Streamable HTTP MCP — incluindo Claude no Chrome, orquestradores personalizados, plataformas hospedadas e qualquer coisa que não tenha um relacionamento amigável com a criação de processos locais. Uma URL, sem instalação.

Ambos os transportes expõem as mesmas seis ferramentas descritas abaixo, com a mesma semântica. Escolha a que melhor se adapta à sua implantação.

Passo 2: faça login com Ethereum

A autenticação é SIWE — Sign-In with Ethereum. Sem senhas, sem chaves de API para vazar em um .env, sem tokens portadores de longa duração.

O fluxo é o handshake padrão do SIWE:

1. O agente solicita um nonce do servidor.
2. O servidor retorna uma mensagem SIWE contendo o nonce, o domínio e um timestamp de emissão.
3. O agente assina a mensagem com a carteira que você delegou a ele.
4. O agente envia a assinatura; o servidor a verifica na blockchain e abre uma sessão.

Algumas implicações práticas que vale a pena deixar explícitas:

• O agente nunca mantém um segredo de longa duração. Ele mantém uma chave. Você pode revogar o acesso girando a chave.
• Você pode limitar a carteira. A maioria dos operadores dá ao agente uma carteira de negociação dedicada em vez de entregar as chaves de seu tesouro principal. Financiado com um orçamento diário, um agente com uma carteira limitada tem um teto rígido sobre o que pode fazer, e você pode auditar cada ação seguindo a pegada na blockchain.
• Sessões são por carteira, não por runtime de agente. Se você trocar de Claude para um cliente MCP diferente amanhã, a mesma autenticação SIWE funciona desde que a mesma carteira assine.

Se você está construindo isso em um produto, o fluxo SIWE leva cerca de uma tela de código por runtime de agente. O servidor MCP lida com os detalhes do protocolo no lado do servidor.

Passo 3: entenda as seis ferramentas

Uma vez conectado e autenticado, o agente tem seis ferramentas disponíveis. Elas se mapeiam claramente ao ciclo de vida da negociação.

RFQ (Solicitação de Cotação)

create_rfq é o ponto de entrada do trader. Chamá-lo transmite a intenção de forma privada para a rede de formadores de mercado conectados ao Hashlock. Cada formador de mercado vê o pedido, o precifica e envia uma cotação com respond_rfq. Nenhum formador de mercado vê o preço de um concorrente. Essa é a parte do "lance selado": a janela do leilão permanece privada até que o trader escolha um vencedor.

Isso importa por duas razões. Primeiro, os formadores de mercado podem cotar de forma mais apertada, porque não estão preocupados em serem copiados ou subcotados por um concorrente mais rápido lendo o mesmo livro de ordens público. Segundo, a intenção do trader não vaza para o mempool público, então não há front-running e nenhum imposto MEV sobre o preenchimento.

Liquidação HTLC (Hash Time-Locked Contract)

A garantia de liquidação atômica resulta da matemática do HTLC. Ambos os lados bloqueiam fundos contra o mesmo hash. A primeira parte a revelar a pré-imagem para reclamar os fundos da contraparte também publica essa pré-imagem na blockchain, que a outra parte pode então usar para reclamar os fundos de seu contraparte. Ou ambas as pernas da troca são concluídas, ou ambas as pernas são reembolsadas após o tempo limite. Não há estado em que um lado tenha sido pago e o outro não.

Para um agente que está operando sem supervisão, a versão prática disso é: passos falhados são seguros. Um erro de rede durante withdraw_htlc não deixa o trader exposto — ele pode tentar novamente, e se não o fizer, o tempo limite aciona refund_htlc. Um agente construído sobre esse primitivo pode ser agressivo em relação a tentativas sem colocar capital em risco.

Passo 4: uma negociação normal, do início ao fim

Aqui está a sequência de chamadas que um agente faz para trocar, digamos, ETH na Ethereum por SUI na Sui:

1. create_rfq com {from: "ETH", to: "SUI", amount, fromChain: "ethereum", toChain: "sui"}. O servidor retorna um ID de RFQ e inicia a janela do leilão.
2. Aguarde as cotações de respond_rfq. Os formadores de mercado enviam lances selados. O agente os coleta, escolhe o melhor preço (ou