@nadohq/nado-mcp 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,232 @@
1
+ # nado-mcp
2
+
3
+ ![version](https://img.shields.io/npm/v/@nadohq/nado-mcp?color=blue)
4
+
5
+ MCP server for the [Nado Protocol](https://nado.xyz) — perpetual futures, spot trading, and liquidity provision on the Ink blockchain.
6
+
7
+ Gives AI assistants tools to query market data, manage positions, place orders, and access historical trading data. Works with Cursor, Claude Desktop, VS Code, Windsurf, Codex, Gemini CLI, and any MCP-compatible client.
8
+
9
+ > [!CAUTION]
10
+ > Experimental software. Interacts with the live Nado Protocol on the Ink blockchain and can execute real financial transactions including leveraged perpetual futures. Read [DISCLAIMER.md](DISCLAIMER.md) before using with real funds or AI agents.
11
+
12
+ ## Contents
13
+
14
+ - [Installation](#installation)
15
+ - [MCP Client Setup](#mcp-client-setup)
16
+ - [Security](#security)
17
+ - [Environment Variables](#environment-variables)
18
+ - [Development](#development)
19
+ - [Contributing](#contributing)
20
+ - [Disclaimer](#disclaimer)
21
+
22
+ ## Installation
23
+
24
+ No manual install needed. MCP clients like Cursor and Claude Desktop resolve the package automatically when configured with `bunx` (see [MCP Client Setup](#mcp-client-setup)).
25
+
26
+ ## MCP Client Setup
27
+
28
+ ### Cursor
29
+
30
+ Add to your `.cursor/mcp.json` (project-level) or `~/.cursor/mcp.json` (global):
31
+
32
+ ```json
33
+ {
34
+ "mcpServers": {
35
+ "nado": {
36
+ "command": "bunx",
37
+ "args": ["@nadohq/nado-mcp"],
38
+ "env": {
39
+ "DATA_ENV": "nadoMainnet",
40
+ "PRIVATE_KEY": "0xLINKED_SIGNER_PRIVATE_KEY",
41
+ "SUBACCOUNT_OWNER": "0xMAIN_WALLET_ADDRESS"
42
+ }
43
+ }
44
+ }
45
+ }
46
+ ```
47
+
48
+ ### Claude Desktop
49
+
50
+ Add to your `claude_desktop_config.json`:
51
+
52
+ ```json
53
+ {
54
+ "mcpServers": {
55
+ "nado": {
56
+ "command": "bunx",
57
+ "args": ["@nadohq/nado-mcp"],
58
+ "env": {
59
+ "DATA_ENV": "nadoMainnet",
60
+ "PRIVATE_KEY": "0xLINKED_SIGNER_PRIVATE_KEY",
61
+ "SUBACCOUNT_OWNER": "0xMAIN_WALLET_ADDRESS"
62
+ }
63
+ }
64
+ }
65
+ }
66
+ ```
67
+
68
+ Set `DATA_ENV` to `nadoTestnet` to connect to the [testnet](https://testnet.nado.xyz) instead.
69
+
70
+ ## Security
71
+
72
+ MCP servers run **locally on your machine** as child processes spawned by the MCP client (Cursor, Claude Desktop, etc.). Communication happens over stdio - there are no open ports and no network exposure. Environment variables like `PRIVATE_KEY` stay on your machine and are never sent to any AI provider; the model only sees tool definitions and tool results.
73
+
74
+ That said, **never put your main wallet private key in the MCP config.** The config file is stored in plain text on disk, readable by any process running as your user. If accidentally committed to version control, the key is permanently exposed.
75
+
76
+ The server supports three operating modes, from most to least secure:
77
+
78
+ ### 1. Read-Only Mode (No Key)
79
+
80
+ Omit `PRIVATE_KEY` entirely. All query tools work (market data, account info, history), but any tool that submits a transaction will return an error.
81
+
82
+ ```json
83
+ {
84
+ "env": {
85
+ "DATA_ENV": "nadoMainnet"
86
+ }
87
+ }
88
+ ```
89
+
90
+ ### 2. Linked Signer (Recommended for Mainnet)
91
+
92
+ Use a **linked signer** — a disposable hot key that is authorized to sign transactions on behalf of your main wallet. Your main wallet key never touches the MCP config.
93
+
94
+ #### How It Works
95
+
96
+ Nado allows any subaccount to designate a **linked signer address**. Once linked, the engine accepts EIP-712 signatures from either the subaccount owner or the linked signer for off-chain operations (placing/cancelling orders, withdrawals, transfers).
97
+
98
+ #### Setup
99
+
100
+ **Step 1: Generate a hot key**
101
+
102
+ Any tool that creates an Ethereum keypair will work. Pick whichever you have available:
103
+
104
+ **Option A - Node.js (no extra install, uses viem from this project)**
105
+
106
+ ```bash
107
+ node -e "const{generatePrivateKey,privateKeyToAddress}=require('viem/accounts');const k=generatePrivateKey();console.log('Address: '+privateKeyToAddress(k)+'\nPrivate key: '+k)"
108
+ ```
109
+
110
+ **Option B - OpenSSL (available on most systems)**
111
+
112
+ ```bash
113
+ openssl rand -hex 32 | awk '{print "0x"$1}'
114
+ ```
115
+
116
+ This gives you a private key. To derive the address, paste the key into any wallet (e.g. MetaMask import) or use Option A.
117
+
118
+ **Option C - Foundry (`cast`)**
119
+
120
+ If you have [Foundry](https://book.getfoundry.sh/) installed:
121
+
122
+ ```bash
123
+ cast wallet new
124
+ ```
125
+
126
+ Save the printed address and private key.
127
+
128
+ **Step 2: Link the hot key to your subaccount**
129
+
130
+ From your **main wallet**, authorize the hot key address. You can do this via:
131
+
132
+ - The Nado frontend (Settings → Linked Signer)
133
+ - The `link_signer` tool in this MCP server (requires the main key to be configured temporarily)
134
+ - A direct contract call
135
+
136
+ **Step 3: Configure the MCP server**
137
+
138
+ ```json
139
+ {
140
+ "env": {
141
+ "DATA_ENV": "nadoMainnet",
142
+ "PRIVATE_KEY": "0xHOT_KEY_PRIVATE_KEY",
143
+ "SUBACCOUNT_OWNER": "0xMAIN_WALLET_ADDRESS"
144
+ }
145
+ }
146
+ ```
147
+
148
+ `PRIVATE_KEY` is the hot key (used for signing). `SUBACCOUNT_OWNER` is the main wallet (used to identify the subaccount for queries and order parameters).
149
+
150
+ **Step 4 (if compromised): Revoke**
151
+
152
+ From your main wallet, call `link_signer` with the zero address (`0x0000000000000000000000000000000000000000`). This immediately invalidates the hot key.
153
+
154
+ #### What a Linked Signer Can Do
155
+
156
+ - Place, cancel, and modify orders
157
+ - Place trigger orders (stop-loss, take-profit, TWAP)
158
+ - Withdraw collateral (off-chain signed via the engine)
159
+ - Transfer between subaccounts
160
+
161
+ #### What a Linked Signer Cannot Do
162
+
163
+ - Deposit collateral (on-chain `msg.sender` must be the wallet holding the tokens)
164
+ - Link or revoke signers (requires the subaccount owner's signature)
165
+ - Any on-chain transaction that checks `msg.sender`
166
+
167
+ #### Limitations
168
+
169
+ - **No permission scoping**: a linked signer has full access to all off-chain operations, including withdrawals. The security boundary is **revocability**, not restriction. If the key leaks, act fast to revoke it.
170
+ - **One signer per subaccount**: each subaccount can have at most one linked signer. Linking a new address replaces the previous one.
171
+ - **Rate limits**: linked signers may have separate rate limits from the subaccount owner.
172
+
173
+ ### 3. Direct Key
174
+
175
+ You can use your wallet key directly. Omit `SUBACCOUNT_OWNER` and the server derives it from `PRIVATE_KEY`:
176
+
177
+ ```json
178
+ {
179
+ "env": {
180
+ "DATA_ENV": "nadoMainnet",
181
+ "PRIVATE_KEY": "0xYOUR_PRIVATE_KEY"
182
+ }
183
+ }
184
+ ```
185
+
186
+ Because MCP servers run locally as child processes with no network exposure, your key never leaves your machine. This is a valid option for users who prefer simplicity over the revocability that a linked signer provides.
187
+
188
+ That said, the key is stored in plain text in your MCP client config, so keep these risks in mind:
189
+
190
+ - Any process running as your OS user can read the config file.
191
+ - If accidentally committed to version control, the key is permanently exposed.
192
+ - If the key is compromised, you must move funds — there is nothing to "revoke".
193
+
194
+ For mainnet with significant funds, a linked signer (Option 2) is still recommended because it limits the blast radius to a disposable key you can revoke instantly.
195
+
196
+ ## Environment Variables
197
+
198
+ Set these in the `"env"` block of your MCP client config (recommended). A `.env` file can be used as a fallback for local development.
199
+
200
+ | Variable | Required | Default | Description |
201
+ | ------------------ | -------- | ------------- | ------------------------------------------------ |
202
+ | `DATA_ENV` | Yes | — | `nadoMainnet` or `nadoTestnet` |
203
+ | `RPC_URL` | No | Chain default | Custom RPC URL |
204
+ | `PRIVATE_KEY` | No | — | Private key for signing (linked signer recommended) |
205
+ | `SUBACCOUNT_OWNER` | No | — | Main wallet address (required when using a linked signer) |
206
+ | `SUBACCOUNT_NAME` | No | `default` | Default subaccount name |
207
+
208
+ ## Development
209
+
210
+ ```bash
211
+ git clone https://github.com/nadohq/nado-mcp.git && cd nado-mcp
212
+ bun install
213
+ bun run build
214
+ ```
215
+
216
+ ```bash
217
+ bun run dev # Watch mode
218
+ bun run build # Build for production
219
+ bun run typecheck # Type check
220
+ bun run lint # Lint and format
221
+ ```
222
+
223
+ ## Contributing
224
+
225
+ 1. Fork the repo and create a feature branch
226
+ 2. Install dependencies: `bun install`
227
+ 3. Make your changes and ensure `bun run typecheck && bun run lint:check && bun run build` passes
228
+ 4. Open a pull request against `main`
229
+
230
+ ## Disclaimer
231
+
232
+ See [DISCLAIMER.md](DISCLAIMER.md).
@@ -0,0 +1,2 @@
1
+
2
+ export { }