@usenami/signer-mcp

Sign CEX orders from any MCP-aware AI agent — the signing secret never leaves the AWS Nitro Enclave.

signer-mcp is the public face of Usenami Signer. It gives Claude Desktop, Cursor, ElizaOS, and any other MCP-aware client a six-tool surface for trading real CEX/DEX perp accounts (Binance, OKX, Asterdex, KuCoin, Bybit, Hyperliquid) without the signing secret ever entering the agent's process — or yours.

Status: v0 (alpha), invite-based pilot. Venue manifest, attestation, account read, place/cancel order, and a two-leg hedge. ⚠️ Assume orders are real. Which venue and network your orders hit is decided by the policy bound to your token, and neither this page nor list_venues can tell you which — ask whoever issued the token. There is no implicit testnet safety net, so treat every order as mainnet money until you have confirmed otherwise. Read place_order before sending anything.

Why this exists

Every agent framework that touches a CEX today loads the API key into the agent process. That puts the secret on disk, in env vars, in npm packages, in prompt-engineered tool calls, and in your shell history. One prompt injection, one supply-chain compromise, one accidental log line, one curious co-worker — and the key leaks.

Signer takes the opposite approach. The signing key is generated inside an AWS Nitro Enclave attested by AWS itself. The enclave's measurement (PCR0) is published on https://usenami.io/signer/attestations. The MCP server you install here can ask the enclave to sign a specific order — bounded by an explicit policy (per-asset cap, per-period cap, allowed venues) — but it cannot read the key. Neither can the agent, your laptop, your IaC, or our own engineers.

If the agent gets compromised, the worst it can do is place orders inside your policy window. The key itself stays attested.

Quick start (Claude Desktop)

1. Get a token. Access is invite-based during the pilot — there is no self-serve signup yet; request access via usenami.io/signer (contact link at the bottom) and your token is provisioned at onboarding, bound to a policy with per-venue caps. No token yet? Steps 2–4 still work: list_venues and get_attestation need no token. Note what each one actually does, because only one of them talks to us: get_attestation fetches a live, NSM-signed document from the gateway, while list_venues answers from a static manifest compiled into this package and makes no network call at all.

2. Edit claude_desktop_config.json. Path is ~/Library/Application Support/Claude/claude_desktop_config.json on 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_..."
         }
       }
     }
   }

Pin @^0.6.0 — earlier versions do not work out of the box. Every published version up to and including 0.5.0 defaults SIGNER_GATEWAY_URL to https://signer.usenami.io, which 301-redirects every path to the marketing landing page. The network tools then receive HTML and die with Unexpected token '<'. 0.6.0 changed the default to the demo gateway. If you are pasting a config from an older post or cached answer, check this first — the symptom looks like a broken server and is a stale default.

3. Restart Claude Desktop and look for the 🔌 plug icon. You should see seven tools listed under signer: list_venues, get_attestation, get_verified_price, get_account, place_order, place_hedge, cancel_order. (The list is named rather than counted on purpose — a count in prose goes stale the moment a tool is added, and this one did: it said six until get_verified_price shipped.)

4. Try the read-only tools first. Ask Claude:

   "List the venues available through Signer, then return the current attestation document."

   No funds at risk — these don't sign anything, and neither needs a token.

5. Once you have a token and trust the attestation, you can place a first order — knowingly. ⚠️ This signs a real order on the venue your token's policy allows, and you should assume that means mainnet, real money — 0.001 BTC is a real position, not a testnet exercise, unless the person who issued your token told you otherwise. Start with the smallest size your policy allows, and only then:

   "Get my Binance account, then if I have at least $20 of free margin, place a market buy for 0.001 BTC."

If anything looks wrong, the agent can call cancel_order immediately.

Quick start (ElizaOS)

ElizaOS has a native plugin: @usenami/plugin-signer (same gateway contract — a token issued for one works with the other). Prefer it: actions land directly in the agent, plus an attestation provider that keeps the current PCR0 in context.

Alternatively, ElizaOS can reach this MCP server through the generic bridge @elizaos/plugin-mcp over stdio:

npm install @elizaos/plugin-mcp

Then in your character / agent config:

{
  "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_..."
          }
        }
      }
    }
  }
}

The agent now exposes the same seven tools (list_venues, get_attestation, get_verified_price, get_account, place_order, place_hedge, cancel_order). Same trust model: the signing key never enters the Eliza process — start the agent on the read-only tools (list_venues / get_attestation) and verify the attestation before letting it place orders. Only get_attestation reaches the gateway; list_venues is served from a static manifest inside the package, so a green list_venues says nothing about whether your gateway is reachable.

Configuration

Environment variables passed via the env block of claude_desktop_config.json (or your client's equivalent):

| Variable | Required | Default | Notes | |---|---|---|---| | SIGNER_GATEWAY_URL | no | https://signer-demo.usenami.io:8443 | The hosted attested demo enclave. Override for self-hosted deployments. | | SIGNER_API_TOKEN | yes (for account/order tools) | — | Bearer token provisioned at onboarding (invite-based pilot). list_venues and get_attestation work without one — but only get_attestation contacts the gateway (list_venues is static, see its section below); get_account, place_order, place_hedge, cancel_order require it. | | SIGNER_FETCH_TIMEOUT_MS | no | 30000 | Per-request fetch timeout in ms. Lower for CI / smoke tests; raise on slow links. Must be positive integer. | | X402_PRIVATE_KEY | only for get_verified_price | — | Payer key for the x402 gateway: each price query costs one cent in USDC on Base. Without it the tool refuses no_payer_key and spends nothing — it never sends an unpaid request and never falls back to an unverified source. Use a wallet funded for this and nothing else; the ceiling per payment is capped in code. |

The MCP server itself stores nothing on disk. Tokens are read from environment on startup and held in memory for the lifetime of the process — kill the agent, the token goes with it.

Tool reference

list_venues

Returns the static manifest of venues this Signer can sign for. Read-only, does not contact the gateway, works without a token. Call this first to discover what's supported.

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

Every entry carries a status: live (the enclave will sign for it) or denied (the enclave refuses by policy — supplying credentials will not change it). Some entries add a network field (bsc, hyperliquid-testnet, …). Read status and notes before choosing a venue.

Supported venues

| venue id | status | asset class | auth scheme | symbol example | notes | |---------------------|--------|-------------|---------------|-----------------|-------| | binance | live | perp | hmac_sha256 | BTCUSDT | Binance USD-M futures. ⚠️ Assume mainnet, real funds — the network is set by your token's policy, not by this table | | okx | live | perp | hmac_sha256 | BTC-USDT-SWAP | OKX perpetual swap. Signs where an OKX key is provisioned; only the gateway you point at can say whether one is. Sizes are in contracts (1 BTC-USDT-SWAP = 0.01 BTC) | | asterdex | live | perp | eip712 (bsc) | BTC-USD | Asterdex on-chain perp (BSC) | | kucoin | live | perp | hmac_sha256 | XBTUSDTM | KuCoin Futures (HMAC + encrypted passphrase); qty in contracts | | bybit | live | perp | hmac_sha256 | BTCUSDT | Bybit V5 linear (category=linear) | | hyperliquid_testnet | live | perp | eip712 (hyperliquid) | BTC | Same enclave code as mainnet, testnet phantom-agent source. Not reachable via place_order/cancel_order in v0 | | hyperliquid_main | live | perp | eip712 (hyperliquid) | BTC | Order and cancel only — the enclave has no withdrawal or transfer action for this venue. Mainnet carries an unconditional money floor (authority-signed policy + binding per-asset caps by integer asset index), not relaxable by a build flag. Account read is the public clearinghouseState |

The agent config block is identical for every venue — point SIGNER_GATEWAY_URL at your Signer and set SIGNER_API_TOKEN. Which venues a given token may trade is bound server-side to that token's policy; list_venues reports the full set the gateway can sign, not your per-token allow-list.

get_attestation

Fetches the Nitro attestation document with a fresh nonce and verifies it locally before returning anything. PCR0/PCR1/PCR2 are read out of the signed bytes.

🔴 Corrected in 0.7.1, and worth saying plainly. Until 0.7.0 this tool sent no nonce and verified nothing — it forwarded the gateway's JSON and described itself as proof that "the code currently signing your orders matches the published source". Neither half held. Without a nonce the document is bound to nothing, so a replay of an older attestation was indistinguishable from a fresh one, and "currently" was unearned. And nothing was checked: not the hardware signature, not the certificate chain, not the root. This is the only surface a third-party agent consumes, which made it the worst place in the product to keep a decorative verifier.

{
  "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 }
}

Every check can fail on its own, and verified is the AND of all five. When anything is false the document is still returned — you may want to look at it — but proves is empty and do_not_trust_for leads with the only honest reading: a document that does not verify is not weaker evidence, it is none.

What the tool cannot establish, stated in its own output rather than left to be inferred: that PCR0 corresponds to the published source (rebuild from the public clone and compare, or ask the on-chain registry), and anything about a past signature — an attestation speaks about the code that answered this request.

root_pinned is the load-bearing one. Whoever answers on SIGNER_GATEWAY_URL can mint their own CA under AWS's own subject name, sign their own chain and a document carrying any measurement they like, and echo the nonce; the other four checks then pass. The pinned fingerprint is what they cannot forge. There is deliberately no environment variable to relax it. To stop taking our word for that one constant, compare it once:

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

⚠️ The sample above no longer shows registered_onchain. That field used to be in the gateway's response and is gone — measured against the live endpoint on 12 September, with a nonce the body carries attestation_doc_b64, nonce, pcr0_sha384 and timestamp_ms, and without one the same minus nonce. It would have been the operator's own configuration reported back as if it were a fact about the chain, which is why nothing here depends on it.

⚠️ And the body's nonce echo is worth exactly nothing as a check. The gateway writes it, the same way it writes pcr0_sha384. nonce_echoed compares against the nonce inside the signed document; a client that compared the body field instead would be asking the operator whether the operator was honest.

Read-only, works without a token. Verification needs no network beyond the gateway call and no dependencies — Node's own crypto does the chain and the ES384 signature.

get_verified_price

Reads a Uniswap V3 token price from The Graph and returns it only if four checks pass. Runs entirely outside the enclave — this is a reading, not a signature, and the README says so where a reader might otherwise assume the enclave vouched for the number.

get_verified_price(token_address="0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2")

| the check | what it stops | |---|---| | the indexer signed the exact bytes that arrived | a re-serialised body hashes differently, so a "verified" answer over modified JSON | | that signer resolves on chain to an indexer with stake | a signature from nobody in particular | | the reading is a usable price | a verified signature over a GraphQL error, or over a zero, is not a price | | the price's own age, measured apart from the subgraph head's | a fresh head carrying a year-old price — prices are written in event handlers, so a dead market keeps a dead one under green indexing |

On refusal no price is returned, and the answer names both the check that stopped it (stage) and that check's own reason (cause). price_absent_or_zero, graphql_errors and price_stale are three different problems with three different fixes, which is why they are three different words.

Name the token by address when you can. A ticker is not a key in this subgraph: asking it for WETH returns several tokens with that name, all of them real. So every match is checked and returned rather than the first one being guessed at. With neither an address nor a ticker, the tool returns the most recently priced tokens, filtered to those that actually carry a price.

It costs money and says so up front: one cent in USDC on Base per query, paid through the x402 gateway, which needs X402_PRIVATE_KEY. Without that key the tool refuses no_payer_key and spends nothing — it does not send an unpaid request, and it does not quietly fall back to an unverified source.

get_account

Returns equity, free margin, and open positions for a 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"
}

Read-only. Requires SIGNER_API_TOKEN.

place_order

Place a single market or limit order. The enclave signs the payload after checking policy caps.

Args:

• venue — one of binance | okx | asterdex | kucoin | bybit | hyperliquid_testnet | hyperliquid_main. ⚠️ v0 has structured order routes for binance | okx only — other venues return a clear error (they expose read-only account access); and check list_venues status first
• symbol — canonical (BTC, BTCUSDT, BTC/USDT) or venue-native (BTC-USDT-SWAP, XBTUSDTM, …). The client translates to the venue's native format and echoes it back.
• side — buy | sell
• qty — always base-asset quantity (e.g. 0.001 for 0.001 BTC). Not USD-notional, not venue contracts. Contract-denominated venues (okx: 1 contract = 0.01 BTC on BTC-USDT-SWAP) are converted automatically; sizes off the venue's contract grid are rejected, never silently rounded.
• type — market | limit
• price — required if type=limit, ignored if type=market
• policy_id — optional override; defaults to the policy bound to your token

The result includes a translation echo — check translation.sent to see the exact venue-native symbol + size that hit the 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": "..."
}

Destructive. Requires SIGNER_API_TOKEN. ⚠️ Orders go where your token's policy sends them — there is no implicit testnet routing. On Binance the hosted whether a given gateway signs against mainnet or testnet, and with what caps, is a property of that deployment and of your token's policy — this page cannot tell you, and neither can list_venues. On Hyperliquid the enclave signs both testnet and mainnet, and mainnet additionally requires an authority-signed policy carrying binding per-asset caps — a blob without them is refused at load, unconditionally. Note that neither Hyperliquid venue is reachable through place_order / cancel_order in v0: those carry structured routes for binance and okx only. An earlier revision of this section said "v0 routes Binance/OKX to testnet" — that was wrong, see CHANGELOG 0.6.0.

place_hedge

Places a 2-leg hedge with atomic signing: both legs are signed inside the enclave all-or-nothing (a policy denial on either leg means nothing is even sent), then the gateway fires both venue calls server-side in parallel — the leg gap collapses to the venues' own latency spread and the signed auth headers never transit through your client. ⚠️ Venue execution is not atomic: the partial and unknown statuses below exist precisely because an exchange can accept one leg and lose or reject the other.

Args:

• legs — exactly 2, each {venue, symbol, side, qty, type}. v1 constraints: type: "market" only (a resting limit leg would let "executed" hide an unfilled leg — use place_order for limits) and venues limited to binance | okx. Typical hedge: same symbol, opposite sides, equal base-asset qty on two venues.
• Symbols and qty use the same canonical/base-asset translation as place_order; per-leg translations are echoed back.

Read the result's status before anything else:

• executed — both legs live.
• partial — 🔴 exactly one leg live: the position is NAKED. Repair by closing the live leg or re-placing the rejected one. Never re-place a leg whose outcome is unknown.
• unknown — 🔴 a leg's receipt was lost (timeout / venue 5xx) — that order may be live. Do NOT retry place_hedge; reconcile first via get_account on both venues.
• failed — both legs definitively rejected, nothing live, safe to fix and retry.

Destructive (moves real positions on two venues at once). Requires SIGNER_API_TOKEN. Gateways older than the /hedge endpoint return a clear "use two place_order calls" error.

cancel_order

Cancels an outstanding order by its venue order id. Idempotent — cancelling an already-filled or non-existent order returns ok: false with a venue reason instead of erroring.

Available for binance | okx in v0 — other venues have no structured cancel route yet and return a clear error (same limitation as place_order).

Args:

• venue — binance | okx
• order_id — the venue id returned by place_order
• symbol — required (canonical BTC or venue-native; translated exactly like place_order) — both venues' REST cancel routes need it alongside order_id

Requires SIGNER_API_TOKEN.

Verifying the attestation

A trustworthy Signer is one whose enclave measurement matches a build you can audit. The workflow:

1. Call get_attestation. Check verified is true and read pcr0 — the tool has already taken it out of the signed document, checked the nonce it just sent, walked the certificate chain and compared the root against the pinned fingerprint. If verified is false, stop here: checks names which one failed.
2. Visit usenami.io/signer/attestations.
3. Cross-reference the PCR0 against the published build for the current production version.
4. Optionally rebuild the EIF from source and verify the measurement yourself — step-by-step instructions: VERIFY-SIGNER-YOURSELF.

If the published PCR0 doesn't match what get_attestation returns, don't trade. Open an issue.

What v0 deliberately does NOT do

v0 keeps the surface deliberately tight:

• No multi-tenant: one account per venue per token.
• No UPL editing UI: policies are set out-of-band on usenami.io/signer.
• No WebSocket / streaming tools — REST only.
• No cross-venue routing (place_order takes one venue; the only multi-venue tool is the fixed 2-leg place_hedge).
• No leverage configuration (set_leverage) — uses account defaults.
• No withdrawals / transfers (closest is cancel_order).
• No TWAP / iceberg — single-shot orders only.
• stdio transport only — no SSE or remote HTTP.

If you need any of the above, file an issue describing the use case. v0 keeps the surface tight on purpose.

Development

# 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

The transport is stdio; you'll need an MCP-aware client to actually exercise the tools. The Anthropic mcp-inspector is the fastest way to poke at it locally.

License

MIT. See LICENSE.