signer-mcp

Assinatura sem chave para CEX/DEX para agentes de IA — as chaves de API da exchange permanecem dentro de um AWS Nitro Enclave, para que um agente com injeção de prompt não possa vazá-las. Binance, OKX, Bybit, KuCoin, Hyperliquid, Asterdex.

GitHub

Experimente este MCPPatrocinado

Documentação

@usenami/signer-mcp

Assine ordens de CEX a partir de qualquer agente de IA compatível com MCP — o segredo de assinatura nunca sai do AWS Nitro Enclave.

signer-mcp é a face pública do Usenami Signer. Ele dá ao Claude Desktop, Cursor, ElizaOS e qualquer outro cliente compatível com MCP uma superfície de seis ferramentas para operar contas perpétuas reais de CEX/DEX (Binance, OKX, Asterdex, KuCoin, Bybit, Hyperliquid) sem que o segredo de assinatura entre no processo do agente — nem no seu.

Status: v0 (alfa), piloto por convite. Manifesto de venues, atestação, leitura de conta, colocação/cancelamento de ordens e hedge de duas pernas. ⚠️ Considere que as ordens são reais. Qual venue e rede suas ordens atingem é decidido pela política vinculada ao seu token, e nem esta página nem list_venues podem lhe dizer qual — pergunte a quem emitiu o token. Não há rede de segurança implícita de testnet, então trate cada ordem como dinheiro real em mainnet até confirmar o contrário. Leia place_order antes de enviar qualquer coisa.

Por que isso existe

Todo framework de agente que toca uma CEX hoje carrega a chave de API para dentro do processo do agente. Isso coloca o segredo no disco, em variáveis de ambiente, em pacotes npm, em chamadas de ferramentas manipuladas por prompt e no seu histórico de shell. Uma injeção de prompt, um comprometimento de supply chain, uma linha de log acidental, um colega curioso — e a chave vaza.

O Signer adota a abordagem oposta. A chave de assinatura é gerada dentro de um AWS Nitro Enclave atestado pela própria AWS. A medição do enclave (PCR0) é publicada em https://usenami.io/signer/attestations. O servidor MCP que você instala aqui pode pedir ao enclave para assinar uma ordem específica — limitada por uma política explícita (limite por ativo, limite por período, venues permitidos) — mas não pode ler a chave. Nem o agente, nem seu laptop, nem sua IaC, nem nossos próprios engenheiros.

Se o agente for comprometido, o pior que ele pode fazer é colocar ordens dentro da sua janela de política. A chave em si permanece atestada.

Início rápido (Claude Desktop)

Obtenha um token. O acesso é por convite durante o piloto — não há cadastro self-service ainda; solicite acesso via usenami.io/signer (link de contato no rodapé) e seu token é provisionado no onboarding, vinculado a uma política com limites por venue. Ainda não tem token? Os passos 2–4 funcionam mesmo assim: list_venues e get_attestation não precisam de token. Observe o que cada um realmente faz, porque apenas um deles fala conosco: get_attestation busca um documento assinado por NSM do gateway, enquanto list_venues responde a partir de um manifesto estático compilado neste pacote e não faz nenhuma chamada de rede.

Edite claude_desktop_config.json. O caminho é ~/Library/Application Support/Claude/claude_desktop_config.json no macOS.

{
  "mcpServers": {
    "signer": {
      "command": "npx",
      "args": ["-y", "@usenami/signer-mcp@^0.6.0"],
      "env": {
        "SIGNER_GATEWAY_URL": "https://signer-demo.usenami.io:8443",
        "SIGNER_API_TOKEN": "sk_live_..."
      }
    }
  }
}

Fixe @^0.6.0 — versões anteriores não funcionam de imediato. Toda versão publicada até e incluindo 0.5.0 define o padrão de SIGNER_GATEWAY_URL como https://signer.usenami.io, que faz 301-redirecionar todo caminho para a página de marketing. As ferramentas de rede então recebem HTML e morrem com Unexpected token '<'. 0.6.0 mudou o padrão para o gateway de demonstração. Se você está colando uma configuração de um post antigo ou resposta em cache, verifique isso primeiro — o sintoma parece um servidor quebrado e é um padrão desatualizado.

Reinicie o Claude Desktop e procure o ícone de plugue 🔌. Você deve ver sete ferramentas listadas sob signer: list_venues, get_attestation, get_verified_price, get_account, place_order, place_hedge, cancel_order. (A lista é nomeada em vez de contada de propósito — uma contagem em prosa fica desatualizada no momento em que uma ferramenta é adicionada, e esta ficou: dizia seis até get_verified_price ser lançada.)
Experimente primeiro as ferramentas somente leitura. Pergunte ao Claude:

"Liste os venues disponíveis através do Signer e depois retorne o documento de atestação atual."

Sem fundos em risco — elas não assinam nada e nenhuma precisa de token.
Quando você tiver um token e confiar na atestação, pode colocar uma primeira ordem — conscientemente. ⚠️ Isso assina uma ordem real no venue que a política do seu token permite, e você deve presumir que isso significa mainnet, dinheiro real — 0,001 BTC é uma posição real, não um exercício de testnet, a menos que a pessoa que emitiu seu token tenha dito o contrário. Comece com o menor tamanho que sua política permitir e só então:

"Obtenha minha conta da Binance e, se eu tiver pelo menos US$ 20 de margem livre, coloque uma compra a mercado de 0,001 BTC."

Se algo parecer errado, o agente pode chamar cancel_order imediatamente.

Início rápido (ElizaOS)

O ElizaOS tem um plugin nativo: @usenami/plugin-signer (mesmo contrato de gateway — um token emitido para um funciona com o outro). Prefira-o: as ações chegam diretamente ao agente, além de um provedor de atestação que mantém o PCR0 atual no contexto.

Alternativamente, o ElizaOS pode alcançar este servidor MCP através da ponte genérica @elizaos/plugin-mcp via stdio:

npm install @elizaos/plugin-mcp

Depois, na configuração do seu personagem/agente:

{
  "plugins": ["@elizaos/plugin-mcp"],
  "settings": {
    "mcp": {
      "servers": {
        "signer": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@usenami/signer-mcp@^0.6.0"],
          "env": {
            "SIGNER_GATEWAY_URL": "https://signer-demo.usenami.io:8443",
            "SIGNER_API_TOKEN": "sk_live_..."
          }
        }
      }
    }
  }
}

O agente agora expõe as mesmas sete ferramentas (list_venues, get_attestation, get_verified_price, get_account, place_order, place_hedge, cancel_order). Mesmo modelo de confiança: a chave de assinatura nunca entra no processo do Eliza — inicie o agente nas ferramentas somente leitura (list_venues / get_attestation) e verifique a atestação antes de deixá-lo colocar ordens. Apenas get_attestation alcança o gateway; list_venues é servido de um manifesto estático dentro do pacote, então um list_venues verde não diz nada sobre se seu gateway está acessível.

Configuração

Variáveis de ambiente passadas via bloco env do claude_desktop_config.json (ou equivalente do seu cliente):

Variável	Obrigatória	Padrão	Observações
`SIGNER_GATEWAY_URL`	não	`https://signer-demo.usenami.io:8443`	O enclave de demonstração atestado hospedado. Substitua para implantações self-hosted.
`SIGNER_API_TOKEN`	sim (para ferramentas de conta/ordem)	—	Token Bearer provisionado no onboarding (piloto por convite). `list_venues` e `get_attestation` funcionam sem um — mas apenas `get_attestation` contata o gateway (`list_venues` é estático, veja a seção abaixo); `get_account`, `place_order`, `place_hedge`, `cancel_order` exigem um.
`SIGNER_FETCH_TIMEOUT_MS`	não	`30000`	Timeout de fetch por requisição em ms. Reduza para CI/testes de fumaça; aumente em links lentos. Deve ser inteiro positivo.
`X402_PRIVATE_KEY`	apenas para `get_verified_price`	—	Chave do pagador para o gateway x402: cada consulta de preço custa um centavo em USDC na Base. Sem ela, a ferramenta recusa `no_payer_key` e não gasta nada — nunca envia uma requisição não paga e nunca recorre a uma fonte não verificada. Use uma carteira financiada apenas para isso; o teto por pagamento é limitado no código.

O próprio servidor MCP não armazena nada em disco. Os tokens são lidos do ambiente na inicialização e mantidos em memória durante toda a vida do processo — mate o agente, o token vai junto.

Referência de ferramentas

`list_venues`

Retorna o manifesto estático dos venues para os quais este Signer pode assinar. Somente leitura, não contata o gateway, funciona sem token. Chame primeiro para descobrir o que é suportado.

{
  "venues": [
    {
      "venue": "binance",
      "asset_class": "perp",
      "auth_scheme": "hmac_sha256",
      "status": "live",
      "notes": "..."
    }
  ],
  "count": 7
}

Cada entrada carrega um status: live (o enclave assinará para ele) ou denied (o enclave recusa por política — fornecer credenciais não mudará isso). Algumas entradas adicionam um campo network (bsc, hyperliquid-testnet, …). Leia status e notes antes de escolher um venue.

Venues suportados

id `venue`	status	classe de ativo	esquema de auth	exemplo de símbolo	observações
`binance`	ativo	perp	hmac_sha256	`BTCUSDT`	Futuros USD-M da Binance. ⚠️ Considere mainnet, fundos reais — a rede é definida pela política do seu token, não por esta tabela
`okx`	ativo	perp	hmac_sha256	`BTC-USDT-SWAP`	Swap perpétuo da OKX. Assina onde uma chave OKX está provisionada; apenas o gateway para o qual você aponta pode dizer se há uma. Tamanhos estão em contratos (1 `BTC-USDT-SWAP` = 0,01 BTC)
`asterdex`	ativo	perp	eip712 (bsc)	`BTC-USD`	Perp on-chain da Asterdex (BSC)
`kucoin`	ativo	perp	hmac_sha256	`XBTUSDTM`	Futuros da KuCoin (HMAC + frase secreta criptografada); quantidade em contratos
`bybit`	ativo	perp	hmac_sha256	`BTCUSDT`	Bybit V5 linear (`category=linear`)
`hyperliquid_testnet`	ativo	perp	eip712 (hyperliquid)	`BTC`	Mesmo código de enclave que a mainnet, fonte de agente fantasma de testnet. Não acessível via `place_order`/`cancel_order` na v0
`hyperliquid_main`	ativo	perp	eip712 (hyperliquid)	`BTC`	Apenas ordem e cancelamento — o enclave não tem ação de retirada ou transferência para este venue. A mainnet carrega um piso monetário incondicional (política assinada por autoridade + limites vinculantes por ativo por índice inteiro de ativo), não relaxável por flag de build. A leitura de conta é o `clearinghouseState` público

O bloco de configuração do agente é idêntico para todo venue — aponte SIGNER_GATEWAY_URL para seu Signer e defina SIGNER_API_TOKEN. Quais venues um determinado token pode negociar é vinculado no lado do servidor à política desse token; list_venues relata o conjunto completo que o gateway pode assinar, não sua lista de permissões por token.

`get_attestation`

Busca o documento de atestação Nitro com um nonce novo e o verifica localmente antes de retornar qualquer coisa. PCR0/PCR1/PCR2 são lidos dos bytes assinados.

🔴 Corrigido na 0.7.1, e vale dizer claramente. Até a 0.7.0 esta ferramenta não enviava nonce e não verificava nada — ela encaminhava o JSON do gateway e se descrevia como prova de que "o código que atualmente assina suas ordens corresponde ao código-fonte publicado". Nenhuma das duas metades se sustentava. Sem um nonce, o documento não está vinculado a nada, então uma repetição de uma atestação mais antiga era indistinguível de uma nova, e "atualmente" não era merecido. E nada era verificado: nem a assinatura de hardware, nem a cadeia de certificados, nem a raiz. Esta é a única superfície que um agente de terceiros consome, o que a tornava o pior lugar do produto para manter um verificador decorativo.

{
  "verified": true,
  "checks": {
    "document_readable": true,
    "nonce_echoed": true,
    "root_pinned": true,
    "chain_verified": true,
    "signature_verified": true
  },
  "pcr0": "...sha384 hex, read from the SIGNED document...",
  "nonce_sent": "...16 random bytes, hex...",
  "nonce_in_document": "...the same value, or the check above is false...",
  "root_sha256": "641a0321...bb5b",
  "pinned_root_sha256": "641a0321...bb5b",
  "proves": ["..."],
  "do_not_trust_for": ["..."],
  "document": { "attestation_doc_b64": "...", "pcr0_sha384": "...", "timestamp_ms": 0 }
}

Cada verificação pode falhar por conta própria, e verified é o E de todas as cinco. Quando qualquer coisa é falsa, o documento ainda é retornado — você pode querer olhá-lo — mas proves está vazio e do_not_trust_for começa com a única leitura honesta: um documento que não verifica não é evidência mais fraca, é nenhuma.

O que a ferramenta não pode estabelecer, declarado em sua própria saída em vez de deixado para ser inferido: que o PCR0 corresponde ao código-fonte publicado (reconstrua a partir do clone público e compare, ou pergunte ao registro on-chain), e qualquer coisa sobre uma assinatura passada — uma atestação fala sobre o código que respondeu esta requisição.

root_pinned é o que sustenta tudo. Quem responder em SIGNER_GATEWAY_URL pode cunhar sua própria CA sob o próprio nome de assunto da AWS, assinar sua própria cadeia e um documento carregando qualquer medição que quiser, e ecoar o nonce; as outras quatro verificações então passam. A impressão digital fixada é o que eles não podem forjar. Deliberadamente não há variável de ambiente para relaxá-la. Para parar de aceitar nossa palavra sobre essa única constante, compare uma vez:

curl -sO https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip
unzip -p AWS_NitroEnclaves_Root-G1.zip > aws-nitro-root
openssl x509 -in aws-nitro-root -outform DER | shasum -a 256

⚠️ O exemplo acima não mostra mais registered_onchain. Esse campo costumava estar na resposta do gateway e se foi — medido contra o endpoint ao vivo em 12 de setembro, com um nonce o corpo carrega attestation_doc_b64, nonce, pcr0_sha384 e timestamp_ms, e sem um, o mesmo menos nonce. Seria a própria configuração do operador relatada de volta como se fosse um fato sobre a cadeia, e é por isso que nada aqui depende dela. ⚠️ E o eco do nonce no corpo não vale nada como verificação. O gateway o escreve, da mesma forma que escreve o pcr0_sha384. O nonce_echoed compara com o nonce dentro do documento assinado; um cliente que comparasse o campo do corpo estaria perguntando ao operador se o operador era honesto.

Somente leitura, funciona sem token. A verificação não precisa de rede além da chamada ao gateway e não tem dependências — o crypto do próprio Node faz a cadeia e a assinatura ES384.

`get_verified_price`

Lê o preço de um token Uniswap V3 do The Graph e o retorna somente se quatro verificações passarem. É executado inteiramente fora do enclave — isto é uma leitura, não uma assinatura, e o README diz isso onde um leitor poderia, de outra forma, assumir que o enclave atestou o número.

get_verified_price(token_address="0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2")

a verificação	o que ela impede
o indexador assinou exatamente os bytes que chegaram	um corpo re-serializado tem hash diferente, então uma resposta "verificada" sobre JSON modificado
esse assinador resolve on-chain para um indexador com stake	uma assinatura de ninguém em particular
a leitura é um preço utilizável	uma assinatura verificada sobre um erro GraphQL, ou sobre um zero, não é um preço
a idade do próprio preço, medida à parte da cabeça do subgraph	uma cabeça fresca carregando um preço de um ano atrás — preços são escritos em event handlers, então um mercado morto mantém um morto sob indexação verde

Em caso de recusa, nenhum preço é retornado, e a resposta nomeia tanto a verificação que o impediu (stage) quanto o motivo dessa própria verificação (cause). price_absent_or_zero, graphql_errors e price_stale são três problemas diferentes com três correções diferentes, e é por isso que são três palavras diferentes.

Nomeie o token pelo endereço quando puder. Um ticker não é uma chave neste subgraph: pedir por WETH retorna vários tokens com esse nome, todos reais. Então cada correspondência é verificada e retornada, em vez de adivinhar a primeira. Sem endereço nem ticker, a ferramenta retorna os tokens com preço mais recente, filtrados para aqueles que realmente têm um preço.

Custa dinheiro e diz isso antecipadamente: um centavo em USDC na Base por consulta, pago através do gateway x402, que precisa de X402_PRIVATE_KEY. Sem essa chave, a ferramenta recusa no_payer_key e não gasta nada — ela não envia uma solicitação não paga e não cai silenciosamente em uma fonte não verificada.

Para onde vão os cabeçalhos assinados

🔴 Em get_account, place_order e cancel_order, os cabeçalhos de autenticação assinados passam através do seu cliente. O gateway retorna {method, url, headers}; este pacote então envia essa solicitação para essa URL ele mesmo. Esses cabeçalhos são o que autentica você na exchange: a chave da API viaja neles (X-MBX-APIKEY na Binance, OK-ACCESS-KEY na OKX) e na OKX a frase secreta viaja junto. Somente o segredo de assinatura permanece dentro do enclave — essa é a afirmação que fazemos, e ela é mais restrita do que "suas credenciais nunca saem".

O que decorre disso, declarado claramente em vez de deixado para inferência:

Qualquer coisa que possa ler a memória do seu processo, seus logs ou seu tráfego de saída naquele momento pode ler esses cabeçalhos. Eles são de curta duração e limitados a uma solicitação, o que limita o dano; não o remove.
Não há lista de permissões de host neste cliente. Ele envia para qualquer URL que o gateway nomeou. Um gateway comprometido ou personificado poderia nomear seu próprio host e coletar a chave. Fixe o gateway em que você confia (SIGNER_GATEWAY_URL) e verifique sua atestação — get_attestation existe para isso, e a medição do enclave é o que diz qual código respondeu.

place_hedge é a exceção e o modelo para o resto: ambas as pernas são assinadas e ambas as chamadas à venue são disparadas no lado do servidor, então nada autenticante chega ao seu processo. Mover as outras três para essa forma é a correção; até que isso aconteça, esta seção é a descrição honesta do que acontece hoje.

`get_account`

Retorna patrimônio líquido, margem livre e posições abertas para uma venue.

{
  "venue": "binance",
  "equity_usd": 145.32,
  "free_margin_usd": 92.10,
  "positions": [
    { "symbol": "BTCUSDT", "qty": 0.002, "entry_price": 67120.5 }
  ],
  "updated_at": "2026-05-31T18:01:11Z"
}

Somente leitura. Requer SIGNER_API_TOKEN. Os cabeçalhos assinados para esta chamada passam através do seu cliente — veja Para onde vão os cabeçalhos assinados.

`place_order`

Coloca uma única ordem de mercado ou limite. O enclave assina o payload após verificar os limites de política, e seu cliente então envia a solicitação assinada para a venue — veja Para onde vão os cabeçalhos assinados.

Args:

venue — um de binance | okx | asterdex | kucoin | bybit | hyperliquid_testnet | hyperliquid_main. ⚠️ v0 tem rotas de ordem estruturadas para binance | okx somente — outras venues retornam um erro claro (elas expõem acesso de conta somente leitura); e verifique list_venues status primeiro
symbol — canônico (BTC, BTCUSDT, BTC/USDT) ou nativo da venue (BTC-USDT-SWAP, XBTUSDTM, …). O cliente traduz para o formato nativo da venue e o ecoa de volta.
side — buy | sell
qty — sempre quantidade do ativo base (ex.: 0.001 para 0.001 BTC). Não é nocional em USD, não são contratos da venue. Venues denominadas por contrato (okx: 1 contrato = 0.01 BTC em BTC-USDT-SWAP) são convertidas automaticamente; tamanhos fora da grade de contratos da venue são rejeitados, nunca arredondados silenciosamente.
type — market | limit
price — obrigatório se type=limit, ignorado se type=market
policy_id — substituição opcional; padrão é a política vinculada ao seu token

O resultado inclui um eco de translation — verifique translation.sent para ver o símbolo + tamanho exatos nativos da venue que atingiram a exchange:

{
  "requested": { "symbol": "BTC", "qty": 0.01, "unit": "base_asset" },
  "sent": { "symbol": "BTC-USDT-SWAP", "qty": "1", "unit": "contracts", "ctVal": "0.01" }
}

{
  "venue": "binance",
  "order_id": "...",
  "status": "FILLED",
  "filled_qty": 0.001,
  "avg_fill_price": 67128.9,
  "policy_id": "default",
  "attested_at": "..."
}

Destrutivo. Requer SIGNER_API_TOKEN. ⚠️ As ordens vão para onde a política do seu token as envia — não há roteamento implícito para testnet. Na Binance, se um determinado gateway assina contra mainnet ou testnet, e com quais limites, é uma propriedade dessa implantação e da política do seu token — esta página não pode dizer, e nem list_venues pode. Na Hyperliquid, o enclave assina tanto testnet quanto mainnet, e mainnet adicionalmente requer uma política assinada por autoridade com limites vinculativos por ativo — um blob sem eles é recusado no carregamento, incondicionalmente. Observe que nenhuma venue Hyperliquid é alcançável através de place_order / cancel_order na v0: elas carregam rotas estruturadas para binance e okx somente. Uma revisão anterior desta seção dizia "v0 roteia Binance/OKX para testnet" — isso estava errado, veja CHANGELOG 0.6.0.

`place_hedge`

Coloca uma hedge de 2 pernas com assinatura atômica: ambas as pernas são assinadas dentro do enclave tudo-ou-nada (uma negação de política em qualquer perna significa que nada é sequer enviado), então o gateway dispara ambas as chamadas à venue no lado do servidor em paralelo — a lacuna entre pernas colapsa para a própria latência das venues e os cabeçalhos de autenticação assinados nunca transitam pelo seu cliente. 🔴 Essa última parte é verdadeira somente para esta ferramenta: get_account, place_order e cancel_order os transitam, pelas razões em Para onde vão os cabeçalhos assinados. Não leia esta frase como uma propriedade do pacote. ⚠️ A execução na venue não é atômica: os status partial e unknown abaixo existem precisamente porque uma exchange pode aceitar uma perna e perder ou rejeitar a outra.

Args:

legs — exatamente 2, cada {venue, symbol, side, qty, type}. Restrições v1: type: "market" somente (uma perna limite em repouso deixaria "executado" esconder uma perna não preenchida — use place_order para limites) e venues limitadas a binance | okx. Hedge típica: mesmo símbolo, lados opostos, quantidade igual do ativo base em duas venues.
Símbolos e qty usam a mesma tradução canônica/ativo base que place_order; translations por perna são ecoados de volta.

Leia o status do resultado antes de qualquer outra coisa:

executed — ambas as pernas vivas.
partial — 🔴 exatamente uma perna viva: a posição está NUA. Repare fechando a perna viva ou recolocando a perna rejected. Nunca recoloque uma perna cujo resultado é unknown.
unknown — 🔴 o recibo de uma perna foi perdido (timeout / 5xx da venue) — essa ordem pode estar viva. NÃO tente novamente place_hedge; reconcilie primeiro via get_account em ambas as venues.
failed — ambas as pernas definitivamente rejeitadas, nada vivo, seguro corrigir e tentar novamente.

Destrutivo (move posições reais em duas venues ao mesmo tempo). Requer SIGNER_API_TOKEN. Gateways mais antigos que o endpoint /hedge retornam um erro claro "use duas chamadas place_order".

`cancel_order`

Cancela uma ordem pendente pelo seu id de ordem da venue. Idempotente — cancelar uma ordem já preenchida ou inexistente retorna ok: false com um motivo da venue em vez de erro.

Disponível para binance | okx na v0 — outras venues não têm rota de cancelamento estruturada ainda e retornam um erro claro (mesma limitação que place_order). Os cabeçalhos assinados para esta chamada passam através do seu cliente — veja Para onde vão os cabeçalhos assinados.

Args:

venue — binance | okx
order_id — o id da venue retornado por place_order
symbol — obrigatório (BTC canônico ou nativo da venue; traduzido exatamente como place_order) — as rotas REST de cancelamento de ambas as venues precisam dele junto com order_id

Requer SIGNER_API_TOKEN.

Verificando a atestação

Um Signer confiável é aquele cuja medição do enclave corresponde a um build que você pode auditar. O fluxo de trabalho:

Chame get_attestation. Verifique se verified é verdadeiro e leia pcr0 — a ferramenta já o tirou do documento assinado, verificou o nonce que acabou de enviar, percorreu a cadeia de certificados e comparou a raiz com a impressão digital fixada. Se verified for falso, pare aqui: checks nomeia qual falhou.
Pergunte à chain, que não é nossa para editar. Chame isPCR0Active(pcr0) em 0x38b42eED740b0fDeb211bBDf773F2238cAEec240 (Base). Ela retorna dois valores e ambos decidem: se essa medição está ativa, e o endereço do proprietário que a registrou. Leia o que ela responde em vez de procurar uma resposta específica — o registro mantém uma medição ativa por proprietário, então qual de nossas pistas a contém muda com o tempo.
Encontre a mesma medição na tabela de tags de docs/REPRODUCIBLE-BUILD.md. As tags lá são nomeadas pcr0-<first eight hex of the measurement> e cada linha nomeia o commit do qual foi cortada e a pista para a qual foi cortada.
Reconstrua o EIF desse commit e compare o número que você obtém com aquele de onde começou: VERIFY-SIGNER-YOURSELF. Este é o passo que não precisa de nada de nós.

Pare e não negocie se qualquer uma destas condições for verdadeira — e a primeira é fácil de perder:

o registro nomeia um proprietário que você não reconhece. Uma medição pode estar ativa e registrada por outra pessoa completamente; "ativo" sozinho não é uma aprovação, e uma verificação de proprietário que só acontece na sua cabeça não é uma verificação.
o registro diz que essa medição está não ativa;
a tabela de tags não nomeia sua medição;
sua própria reconstrução produz um número diferente.

Abra uma issue em qualquer um desses casos.

🔴 Por que isto não leva mais você à nossa página primeiro. A página em usenami.io/signer/attestations lê seu valor ao vivo do gateway de demonstração público — verificado: o próprio markup da página chama signer-demo.usenami.io:8443/attestation. Isso não é necessariamente a caixa com a qual seu servidor MCP conversa. Quando duas de nossas caixas executam a mesma medição, comparar uma com a outra parece verificação e não prova nada: você estaria verificando um gateway contra outro gateway, ambos nossos.

Isso não é hipotético hoje. A tabela de tags vinculada acima lista três medições, duas delas aposentadas, e registra produção e demonstração pública compartilhando uma medição desde 2026-09-11 — então, neste momento, a comparação por acaso concorda, que é exatamente quando uma verificação vazia é mais difícil de notar.

A página ainda vale a pena ser lida: ela contém o endereço do registro e a receita de reconstrução. Mas as três coisas que podem nos contradizer — a cadeia, a tabela de tags e sua própria compilação — são as que decidem, e nenhuma delas é uma caixa que operamos.

O que o v0 deliberadamente NÃO faz

O v0 mantém a superfície deliberadamente enxuta:

Sem multi-tenant: uma conta por local por token.
Sem interface de edição de UPL: políticas são definidas fora de banda em usenami.io/signer.
Sem ferramentas WebSocket / streaming — apenas REST.
Sem roteamento entre locais (place_order aceita um local; a única ferramenta multi-local é a place_hedge fixa de 2 pernas).
Sem configuração de alavancagem (set_leverage) — usa padrões da conta.
Sem saques / transferências (o mais próximo é cancel_order).
Sem TWAP / iceberg — apenas ordens de disparo único.
Apenas transporte stdio — sem SSE ou HTTP remoto.

Se você precisar de qualquer um dos itens acima, abra uma issue descrevendo o caso de uso. O v0 mantém a superfície enxuta de propósito.

Desenvolvimento

# install deps
npm install

# typecheck + build
npm run build

# run from source against the hosted demo enclave
SIGNER_GATEWAY_URL=https://signer-demo.usenami.io:8443 \
SIGNER_API_TOKEN=sk_test_... \
npm run dev

O transporte é stdio; você precisará de um cliente compatível com MCP para realmente exercitar as ferramentas. O mcp-inspector da Anthropic é a maneira mais rápida de testá-lo localmente.

Licença

MIT. Consulte LICENSE.