Where your key lives when software trades for you

Fifteen cards sit in trading clients and bots, and almost every one of them asks, at some point in its README, for authority to spend your money. The ask arrives as one line of setup - an environment variable, a config file, a constructor argument - and the line does not say what it is asking for. A reader installs the package, pastes the credential the quickstart named, and has handed over a power they could not describe afterwards.

The word doing the work in all of those quickstarts is key, and it covers four arrangements that have almost nothing in common. They differ in what the software can do with them, in what somebody who obtains a copy can do with them, and - the question that matters most and gets asked least - in whether you can take the permission back afterwards.

This page is about that difference, and about what the clients in this catalogue actually ask for. None of them has been run against a funded account by this site; everything below is read from vendor documentation and from the repositories themselves, and dated.

How it works

A trade on any of these venues is two separable acts: authorising it and submitting it. Authorising is a signature or a signed request, and it is the act that requires the secret. Submitting is an HTTP call that anybody could make. Almost every design question here is a question about who does which, and about how narrow the authority being exercised is.

A wallet private key: signs anything the wallet can do

On the on-chain venues, the credential is an EVM private key, and it is the account. The same secret that signs an order signs a transfer, a token approval, and any other transaction on any chain that address exists on. Nothing about the key itself can be narrowed to "orders only" - narrowing, where it exists at all, is built above the key by the venue.

Two consequences follow, and both are structural rather than a matter of any vendor's care:

• A copy is the original. There is no session, no device binding and no second factor. Someone who reads the key out of a config file, a shell history, a backup or a log has exactly the authority you have.
• There is no revocation. An exchange can delete a credential it issued; nobody issued this one. The only way to end its authority is to move the funds it can reach to an address it cannot, which is a remedy that requires you to already know.

Polymarket's documentation names three wallet types for its own accounts - a Deposit Wallet for everything deployed on or after 4 May 2026, and legacy Proxy and Safe wallets created earlier through Magic Link, Google or an external signer. The distinction is not cosmetic: the scoped delegation described below works only with Deposit Wallets, and the documentation says a migration flow for the two legacy types is planned rather than available.

An exchange API key: acts inside one account, and can be withdrawn

On a venue that holds cash, the credential is issued by an account that already exists and that you can still log into. Kalshi's is the clearest published example. You create the key in profile settings and are handed two things - a Key ID and an RSA private key - and the documentation states plainly that the private key is not stored by the service and cannot be retrieved after the page is closed. Each request is then signed with it: the key ID, a millisecond timestamp and a signature over the timestamp, the HTTP method and the path travel as headers, and the secret itself never goes over the wire.

That is a different shape of exposure from a wallet key in three ways. The secret is not transmitted, so an intercepted request is not a stolen credential. The authority is bounded by the account rather than by the address, so it reaches what that account holds and nothing else. And it is revocable: the account that minted it can delete it, and every client holding a copy stops working at once.

What it is not is automatically narrow. Whether a given venue's key can place orders but not move money off the exchange is a per-venue fact to read out of that venue's API reference before you assume either way, and most venues in this catalogue do not document per-key permissions at all. "An API key rather than a private key" is a statement about revocability, not about scope.

A session or delegated key: scoped, expiring, and the one you want

The middle arrangement is a second signer that the real owner authorises to do a narrow thing. Polymarket's Session Keys are the documented example in this sector, and they are worth reading carefully because they show what narrowing can look like when a venue builds it deliberately.

A Session Key is a fresh EVM keypair - generated by you, never by the venue - which the Deposit Wallet owner then authorises. The documentation states that it cannot withdraw funds from the Deposit Wallet. It can be scoped to named trading venues (the CLOB, Combos, or a shortcut covering both and anything added later). Authorisation carries a 180-day expiry, and the documentation says configurable shorter expirations are not currently supported; to end access sooner you revoke, which stops further trading and cancels that key's open orders without touching orders placed by any other session key.

The part that surprises people is that the narrowing runs in both directions. A Session Key receives only the notifications and order updates generated by its own activity, can fetch only the orders it submitted, and lists only its own trades - and the Deposit Wallet owner cannot fetch orders submitted by its own authorised Session Keys. Delegation here is a partition, not a window. If your reconciliation job expects to see everything the account did, that is a design decision to make before you hand out the key rather than after.

The feature is in beta by the vendor's own label, and authorising a Session Key currently requires a Builder API key that Polymarket has to enable for session-key management.

No key at all: somebody else holds it

The fourth arrangement is the absence of the first three. On a custodial venue the operator holds the assets and your credential is a login; the recovery path is a support queue, and the limit of what software can do on your behalf is whatever the venue's API permits.

A second version of this is now common in phone clients, and it is easy to mistake for the first. Polycool creates a wallet for you through Privy on first run, shows no seed phrase, and handles recovery through that provider. Its documentation says you control the keys; its Terms of Service, Section 4, says the wallet is self-custodial, that the private key can be exported at any time from the app's Settings, and that the company never has custody and cannot move funds without your authorisation, recover funds sent to a wrong address, or reverse a transaction. Section 18 adds the consequence people actually care about: because the wallet is self-custodial, having your access to the service terminated does not affect your control of the funds.

Read those two sentences together and the arrangement is clear. You did not choose the key and you did not see it at creation, but it is yours, it is exportable, and there is nobody to appeal to. "Non-custodial" is a statement about who can move your money and a statement about who can save you, and it is the same statement.

The four, side by side

How this looks on the cards in this catalogue

The five clients below are all in the same category and ask for four different things. Each claim here is read off the vendor's own repository or documentation on the date given.

Polymarket CLI - a fresh private key in a config file, in the clear. The binary resolves a wallet through three sources in order: a --private-key flag, then POLYMARKET_PRIVATE_KEY, then ~/.config/polymarket/config.json. The README's own sample of that file shows a private_key field holding the key as a JSON string beside chain_id and signature_type, and polymarket wallet create generates a new random key and writes it there. There is no passphrase in the file's shape, no keychain path and no hardware-wallet option documented. Read that as what it is: a design that puts a funded account into a plain file that backup software, a shared machine and a synced dotfiles repository all treat as ordinary. The same README is equally clear that most of the tool - discovery, order books, prices, price history - needs no wallet at all, so the exposure is one you opt into per task rather than per install.

polymarket-client - the shape to copy. Polymarket's own Python SDK ships four clients, and the split is at the credential rather than at the convenience: PublicClient and AsyncPublicClient read public data and hold no key material, while SecureClient and AsyncSecureClient take a private key and can trade. A notebook that charts prices imports the first pair and there is nothing in its process to steal. That is the property worth looking for in any library here, and it is the reason this card is the one to hold the others against.

PMXT - one constructor, two credentials, and a documented signing path. The hosted quickstart takes a pmxt_api_key and a venue private_key in the same call, which is the arrangement that should make a reader stop. The documentation's answer, read on 21 September 2026, is a build-sign-submit split: the service prepares the venue's EIP-712 payload, your process signs it locally - the documentation says this step never leaves your process - and the signature goes back for submission. The same pages describe the pmxt_api_key as a service-role credential whose holder can read associated hosted data and forward signed orders but which "alone cannot move funds", and state that the escrow contracts were unaudited as of 9 June 2026. Self-hosted mode is the other half: no PMXT key, a local process, and venue-native credentials that the documentation says stay on your machine. Two credentials in one constructor is not the same claim as two credentials in one place, and here the documentation distinguishes them - which is exactly the thing to check rather than assume.

Alphapoly - four credentials, one of which signs. The README asks for an OpenRouter API key and a Polygon RPC endpoint in .env, and for trading an EOA signing key plus a Relayer API key minted in Polymarket account settings; the app then deploys a per-user deposit wallet gaslessly, with the relayer paying gas. Two of those four buy compute, one reads a chain, and one moves money - and they arrive in the same setup step, at the same apparent level of ceremony. Worth knowing what else leaves the machine while it runs: market text and prompts go to whichever model you point it at, and JSON-RPC traffic goes to your node provider.

Polycool - a key you are given rather than one you bring. Covered above. The card's separate warning is the one a key discussion does not cover: copy trading is an instruction to place positions you did not individually approve, and the terms say the traders you follow are not vetted or supervised and that submitted orders cannot be recalled. Authority over money is not only a key question.

MCP servers, the newest layer and the fastest-moving one

An MCP server hands an agent a list of named tools with typed arguments, and the agent calls what is on the list. That makes the tool inventory the whole of the security question, and the inventory is published by the server itself - the protocol's tools/list call answers it, and several servers in this catalogue answer without credentials at all.

Two things about the transport decide where your credential ends up. The specification defines exactly two standard transports: stdio, where the client launches the server as a subprocess on your machine and speaks over standard input and output, and Streamable HTTP, where the server is an independent process behind a URL. A stdio server reads its key from your environment and the exposure is your machine. An HTTP server takes the credential over the wire, and then the question is which part of the request carries it - a header, or a query string. A credential in a query string is a credential in somebody's access log, in their analytics, and in any proxy between you and them. Adjacent's server takes an apiKey query parameter for its realtime tier and answers without one at a 15-minute delay; several others take a header or a bearer token. Dune's takes neither and authenticates your whole account over OAuth, which is broader than a key rather than narrower.

The write question is separate from the transport question, and the spread across this catalogue is wide. Most servers here are read-only. A couple sit deliberately in the middle - Polyrama exposes ten tools of which the only write is place_paper_order, and Limitless's server prepares orders that a human approves in a browser and holds no keys at all. At the far end, writes exist and are fenced by configuration rather than by architecture: Predictefy publishes the most explicit inventory in the catalogue, where ten execution and collateral tools do not appear at all unless MCP_ENABLE_TRADE is set, new keys are read-only until a trade scope is added, and spend caps default to 100 US dollars per order and 1,000 per key per rolling 24 hours. CCXT ships trading, withdrawals and raw endpoints as separate opt-in tiers, off by default, over stdio. And PMXT's server takes the venue-native credentials themselves - a Polygon private key for Polymarket, an API key plus an RSA key for Kalshi.

On the on-chain venues that last case is the whole difficulty in one sentence: the key that signs an order is the key that moves the collateral, so there is no read-only version of it to hand over. The per-card inventories, scopes and defaults are in the MCP servers collection, and the reason that page tells you to ask the server rather than to trust the page is that this field moves faster than any other on these cards - a server that exposed four read tools in September can expose a write one in November without the product changing its name.

What it costs

The price of the wrong arrangement is not a fee, so it is worth being concrete about what each one puts at stake. What follows is the documented boundary in each case, not an estimate of risk.

• A wallet private key exposes the wallet. Everything at that address, plus anything a previously signed token approval lets a contract pull, plus the same address on any other chain. There is no cap, no reversal and no clawback. The one number you control is the balance you chose to leave there.
• A Polymarket Session Key exposes trading, for 180 days. It cannot withdraw from the Deposit Wallet, it is limited to the scopes granted, and revocation cancels its own open orders. The residual exposure is bad trades rather than an empty wallet.
• A Predictefy trade-scoped key is capped by default at 100 US dollars per order and 1,000 per key per rolling 24 hours, with every write requiring an idempotency key. Those numbers are defaults you can raise, which is the point - the ceiling is a decision somebody made, and by default that somebody was the vendor.
• A hosted MCP key costs you whatever it is metered on. Dune's OAuth session draws on the same credit allowance as everything else in your account, so an agent that loops spends credits rather than hitting a rate limit. Adjacent's realtime key sits in a query string.
• A client that routes your fills can also charge for them. Polycool takes a percentage of every successful trade on top of the venue's own charge, on a ladder from 1.00% down to 0.50% with a floor of three cents per execution. That is a custody-adjacent cost rather than a key one, and what a trade actually costs is the page for it.
• Reading costs nothing and needs no key. The keyless surface of the Polymarket CLI, the PublicClient in the Python SDK, the unauthenticated tiers of several MCP servers, and Kalshi's demo environment are all free, and none of them can be wrong about your balance.

What you can do about it

Keep a separate wallet, funded per session. This is the only control that works against a credential with no revocation, and on the on-chain venues it is the control. Fund it with what the strategy needs this week, sweep the rest to an address whose key has never been on that machine, and treat the balance as the cap you chose. Every other measure below narrows what can be done; this one bounds how much.

Use the read client for read work. Split your own code the way polymarket-client splits its classes: research, dashboards, alerting and backfill run in a process with no key material in it at all. If a notebook holds a signing key only because the library's quickstart did, that is a process to fix in ten minutes.

Prefer a credential you can take back, and ask for one before you assume there is none. In descending order of preference: a scoped, expiring delegated key; an exchange API key you can delete; a wallet key held only by software you run. The four questions to put to any vendor whose documentation does not already answer them are narrow enough to send in an email - can this key be scoped to reading, or to trading without withdrawal? What happens when I revoke it, and how long does that take? Where is it stored on disk, and in what form? Does it leave my machine, and to which host? A vendor that cannot answer the last two has answered them.

Rehearse where a rehearsal exists. Kalshi runs a demo environment with mock funds and states that credentials are not shared between demo and production, which is the property that makes a rehearsal worth anything - a demo key that also works in production is not a sandbox.

Check where the key landed, immediately after setup. Look at the file the tool wrote, look at its permissions, and decide whether that file is in a backup set or a synced directory. A plaintext private_key in ~/.config is not a defect the tool is hiding - the Polymarket CLI's README prints the file's shape - but it is a fact about your machine, not about the tool. Prefer an environment variable sourced from a secret store over a file that persists, and never paste a key as a command-line flag on a shared machine, where it lands in shell history and in the process list.

Rotate on events, not on a calendar. A laptop leaving your hands, a contractor leaving a project, a dependency advisory, a repository you cloned and ran without reading - each of those is a rotation. On a venue with revocation that is two minutes of work; on a wallet key it means moving funds, which is the asymmetry this page is about.

Five minutes in the source, before the first funded run. Not an audit - four greps:

1. Search for the credential's own name (private_key, PRIVATE_KEY, api_key) and read every line it appears on. You are looking for where it is read, where it is stored and whether it is ever interpolated into a URL or a log line.
2. Find the signing call and see where it happens. A library that builds a payload, signs it locally and posts the signature is doing the right thing; a client that sends the key itself to a host it controls is a different product. PMXT's documentation describes the first and says the signing step never leaves your process - that is a claim you can check in the code.
3. Count the dependencies and look at the ones you have never heard of. The key sits in the same process as all of them, and supply-chain risk here is not theoretical - it is the ordinary case of running unfamiliar code with a funded credential in memory.
4. Check the read path really is keyless. If the "public" client instantiates the signing stack anyway, you do not have the separation you think you have.

And remember what a key cannot protect you from. A perfectly scoped credential on a well-behaved client still loses money when a market resolves against you on a technicality - who decides the outcome is the other half of the question of what you agreed to when you deposited. The rest of the category's liveness and maintenance questions, which decide whether the client is still speaking the venue's current API at all, are on the trading clients and bots page.