@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.

Related MCP server: Openterms-mcp

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):

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

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")

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.

Where the signed headers go

🔴 On get_account, place_order and cancel_order the signed auth headers pass through your client. The gateway returns {method, url, headers}; this package then sends that request to that URL itself. Those headers are what authenticates you to the exchange: the API key travels in them (X-MBX-APIKEY on Binance, OK-ACCESS-KEY on OKX) and on OKX the passphrase travels with it. Only the signing secret stays inside the enclave — that is the claim we make, and it is narrower than "your credentials never leave".

What follows from that, stated plainly rather than left to inference:

• Anything that can read your process memory, your logs, or your outbound traffic at that moment can read those headers. They are short-lived and scoped to one request, which limits the damage; it does not remove it.

• There is no host allow-list in this client. It sends to whatever URL the gateway named. A gateway that has been compromised or impersonated could name its own host and collect the key. Pin the gateway you trust (SIGNER_GATEWAY_URL) and verify its attestation — get_attestation exists for this, and the enclave measurement is what tells you which code answered.

place_hedge is the exception and the model for the rest: both legs are signed and both venue calls are fired server-side, so nothing authenticating ever reaches your process. Moving the other three onto that shape is the fix; until it lands, this section is the honest description of what happens today.

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. The signed headers for this call pass through your client — see Where the signed headers go.

place_order

Place a single market or limit order. The enclave signs the payload after checking policy caps, and your client then sends the signed request to the venue — see Where the signed headers go.

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. 🔴 That last part is true of this tool only: get_account, place_order and cancel_order do transit them, for the reasons in Where the signed headers go. Do not read this sentence as a property of the package. ⚠️ 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). The signed headers for this call pass through your client — see Where the signed headers go.

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. Ask the chain, which is not ours to edit. Call isPCR0Active(pcr0) on 0x38b42eED740b0fDeb211bBDf773F2238cAEec240 (Base). It returns two values and both decide: whether that measurement is active, and the address of the owner who registered it. Read what it answers rather than looking for a particular answer — the registry keeps one active measurement per owner, so which of our lanes holds it moves over time.

3. Find the same measurement in the tag table of docs/REPRODUCIBLE-BUILD.md. Tags there are named pcr0-<first eight hex of the measurement> and each row names the commit it was cut from and the lane it was cut for.

4. Rebuild the EIF from that commit and compare the number you get against the one you started from: VERIFY-SIGNER-YOURSELF. This is the step that needs nothing from us at all.

Stop and do not trade if any of these is true — and the first one is easy to miss:

• the registry names an owner you do not recognise. A measurement can be active and registered by somebody else entirely; "active" alone is not a pass, and an owner check that only happens in your head is not a check.

• the registry says that measurement is not active;

• the tag table does not name your measurement;

• your own rebuild produces a different number.

Open an issue in any of those cases.

🔴 Why this no longer sends you to our page first. The page at usenami.io/signer/attestations reads its live value from the public demo gateway — checked: the page's own markup calls signer-demo.usenami.io:8443/attestation. That is not necessarily the box your MCP server talks to. When two of our boxes run the same measurement, comparing one against the other looks like verification and proves nothing: you would be checking a gateway against a gateway, both of them ours.

That is not hypothetical today. The tag table linked above lists three measurements, two of them retired, and records production and the public demo as sharing one measurement since 2026-09-11 — so right now the comparison happens to agree, which is exactly when a hollow check is hardest to notice.

The page is still worth reading: it carries the registry address and the rebuild recipe. But the three things that can contradict us — the chain, the tag table, and your own build — are the ones that decide, and not one of them is a box we operate.

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.