# Where your key lives when software trades for you

Four different credentials are all called a key, and they differ in what a copy permits. What the clients in this catalogue ask for, and what to ask them back.

*https://predictionmarkets.tools/guides/where-your-key-lives · background to Trading Clients, SDKs & Bots*

**Answer:** Four different things are called a key. A wallet private key signs orders and can move everything the wallet holds. An exchange API key acts inside one account and can be deleted. A session key is scoped, expiring and revocable. A custodial arrangement hands you no key at all. They differ in what a copy permits and in whether the permission can be taken back, and the install command says none of it.

Fifteen cards sit in [trading clients and bots](https://predictionmarkets.tools/categories/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](https://predictionmarkets.tools/tools/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

| Arrangement | What the software can do | What a copy permits | Taking it back |
|---|---|---|---|
| Wallet private key | Sign orders, transfers, approvals | Everything you can do, on every chain | Nothing but moving the funds first |
| Exchange API key | Whatever that account's API allows | Act inside that one account | Delete the key in settings |
| Session or delegated key | The scopes granted, for a fixed term | Trade within the scope; on Polymarket, not withdraw | Revoke; expires anyway |
| Custodial or provider-held | Whatever the venue's interface allows | Depends entirely on the login and its factors | Change the credential, close the account |

## 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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/polymarket-alpha-bot) - 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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/polyrama) exposes ten tools of which the only write is `place_paper_order`, and
[Limitless](https://predictionmarkets.tools/tools/limitless-api)'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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/tools/ccxt) ships trading,
withdrawals and raw endpoints as separate opt-in tiers, off by default, over stdio. And
[PMXT](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/collections/mcp-servers), 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](https://predictionmarkets.tools/guides/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](https://predictionmarkets.tools/tools/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](https://predictionmarkets.tools/guides/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](https://predictionmarkets.tools/categories/trading-clients-and-bots) page.

## Tools this bears on

- [polymarket-client](https://predictionmarkets.tools/tools/polymarket-client.md) — Polymarket's own unified Python SDK - sync and async, data through order signing.
- [Polymarket CLI](https://predictionmarkets.tools/tools/polymarket-cli.md) — Polymarket's Rust command line - MIT in the manifest, with no LICENSE file in the repo.
- [PMXT](https://predictionmarkets.tools/tools/pmxt.md) — CCXT-shaped client for prediction markets, with a hosted API and a self-hosted mode.
- [Predictefy](https://predictionmarkets.tools/tools/predictefy.md) — Sixteen venues behind one verb family, priced in credits, with nothing readable for free.
- [Polycool](https://predictionmarkets.tools/tools/polycool.md) — Phone-sized Polymarket client with copy trading, parlays and a fee of its own.

## FAQ

### Is an API key safer than a private key?

Usually, and for one specific reason - it can be withdrawn. An exchange key is issued by an account you still control, so deleting it in settings stops every client holding it. A wallet private key has no issuer and no revocation - the only way to end its authority is to move the funds it can reach. Ask what a copy permits, then ask how you take it back.

### What does non-custodial actually mean for my key?

That nobody can move your funds without your signature, and that nobody can restore them either. Polycool's terms put both halves in one section - self-custodial, exportable private key, and no ability on the company's part to recover funds sent to a wrong address or reverse a transaction. The absence of a custodian is the absence of an appeal.

### Does a tool need my key to show me prices?

Almost never. Polymarket's Python SDK ships a PublicClient that holds no key material, Polymarket's CLI runs its whole discovery and order-book surface without a wallet configured, and several MCP servers in this catalogue answer an unauthenticated tools/list. If a reader or a dashboard asks for a signing key, that is a question to put to the vendor.

### Can I give a bot permission to trade but not to withdraw?

On one venue in this catalogue you can, as a documented feature. Polymarket's Session Keys are a separate signer authorised by a Deposit Wallet owner, scoped to named trading venues and stated in the documentation to be unable to withdraw funds from the wallet. Elsewhere the honest answer is to fund a separate wallet with the amount you are prepared to lose.

## Sources

1. [README](https://github.com/Polymarket/polymarket-cli) — Polymarket, read 2026-09-21
2. [Wallets and Authentication](https://docs.polymarket.com/trading/wallets-auth) — Polymarket, read 2026-09-21
3. [Session Keys](https://docs.polymarket.com/trading/session-keys) — Polymarket, read 2026-09-21
4. [API Keys](https://docs.kalshi.com/getting_started/api_keys) — Kalshi, read 2026-09-21
5. [Test In The Demo Environment](https://docs.kalshi.com/getting_started/demo_env) — Kalshi, read 2026-09-21
6. [Hosted Trading](https://pmxt.dev/docs/concepts/hosted-trading) — PMXT, read 2026-09-21
7. [Self-hosted](https://pmxt.dev/docs/guides/self-hosted) — PMXT, read 2026-09-21
8. [README and .env.example](https://github.com/chainstacklabs/polymarket-alpha-bot) — Chainstack Labs, read 2026-09-21
9. [Terms of Service, Section 4 - Self-Custodial Wallet](https://polycoolapp.com/terms) — Polycool, read 2026-09-21
10. [Wallet & Funding](https://polycoolapp.com/docs/getting-started/wallet) — Polycool, read 2026-09-21
11. [Transports, specification revision 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) — Model Context Protocol, 2025-06-18

*Last updated 2026-09-21. A reference page, corrected in place — not a dated post.*