The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Signer MCP listing page.
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.
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.
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.
Edit claude_desktop_config.json. Path is ~/Library/Application Support/Claude/claude_desktop_config.json on macOS.
Pin
@^0.6.0— earlier versions do not work out of the box. Every published version up to and including0.5.0defaultsSIGNER_GATEWAY_URLtohttps://signer.usenami.io, which301-redirects every path to the marketing landing page. The network tools then receive HTML and die withUnexpected token '<'.0.6.0changed 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.
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.)
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.
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.
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:
Then in your character / agent config:
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.
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.
list_venuesReturns 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.
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.
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_attestationFetches 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.
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:
⚠️ 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_priceReads 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.
| 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.
🔴 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:
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_accountReturns equity, free margin, and open positions for a venue.
Read-only. Requires SIGNER_API_TOKEN. The signed headers for this call pass through
your client — see Where the signed headers go.
place_orderPlace 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 firstsymbol — 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 | sellqty — 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 | limitprice — required if type=limit, ignored if type=marketpolicy_id — optional override; defaults to the policy bound to your tokenThe result includes a translation echo — check translation.sent to see the exact venue-native symbol + size that hit the exchange:
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_hedgePlaces 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.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_orderCancels 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 | okxorder_id — the venue id returned by place_ordersymbol — required (canonical BTC or venue-native; translated exactly like place_order) — both venues' REST cancel routes need it alongside order_idRequires SIGNER_API_TOKEN.
A trustworthy Signer is one whose enclave measurement matches a build you can audit. The workflow:
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.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.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.Stop and do not trade if any of these is true — and the first one is easy to miss:
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.
v0 keeps the surface deliberately tight:
place_order takes one venue; the only multi-venue tool is the fixed 2-leg place_hedge).set_leverage) — uses account defaults.cancel_order).If you need any of the above, file an issue describing the use case. v0 keeps the surface tight on purpose.
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.
MIT. See LICENSE.