> ## Documentation Index
> Fetch the complete documentation index at: https://pmxt.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Security & Credential Handling

> How PMXT handles credentials in hosted vs self-hosted modes, what risks to understand, and how to protect yourself.

PMXT has two execution modes, and they have **different credential surfaces**. Most of the confusion about "does my key touch PMXT's server" comes from mixing them up. This page is scoped explicitly to each mode.

| Mode                                             | What you give PMXT                                                          | What touches PMXT's server                        | Custody                                                                                         |
| ------------------------------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| [**Hosted**](/concepts/hosted-trading) (default) | An EIP-712 signature per order — **never your private key**                 | Outcome target, signatures, public wallet address | USDC in the on-chain [`PreFundedEscrow`](/concepts/hosted-trading) you control via the timelock |
| [**Self-hosted**](/guides/self-hosted)           | Raw venue credentials — given to a PMXT process **you run** on your machine | Nothing — PMXT's cloud is not in the loop         | Your venue account / wallet, directly                                                           |

If you're picking one, hosted is the default for almost everyone. Self-hosted is for users who need raw venue credentials (Polymarket L2 API keys, Kalshi RSA, etc.), sub-100ms latency, or regulatory custody constraints.

## Hosted mode: how credentials flow

In hosted mode, **your private key never leaves your process.** PMXT's server sees signatures, never the key that produced them.

```
Your app  ──HTTPS──>  trade.pmxt.dev  ──submits──>  venue API
   │
   └── signs EIP-712 locally with your private key (key never sent)
```

1. The SDK calls `POST /v0/trade/build-order` with the outcome target and order parameters. The target is either a catalog UUID or a `venue` + `venue_outcome_id` pair. No key, no signature yet.
2. The server returns an unsigned EIP-712 typed-data payload bound to the Polygon [`PreFundedEscrow`](/concepts/hosted-trading) domain.
3. The SDK signs the payload **locally**, in your process, with your private key.
4. The SDK calls `POST /v0/trade/submit-order` with the signature. The server forwards the signed order to the venue.

What PMXT's server receives on the wire: the outcome target, your public wallet address, and the signature. **Not the private key.**

Funds custody: USDC sits in the on-chain `PreFundedEscrow`. Withdrawals are timelocked and user-only — PMXT's operator key cannot move USDC without your EIP-712 signature. See [Hosted trading](/concepts/hosted-trading) for addresses and the raw exit path.

The `pmxt_api_key` authorizes calls to `trade.pmxt.dev`. The key alone cannot move funds. Keep it server-side.

## Self-hosted mode: how credentials flow

In self-hosted mode, you run `pmxt-core` as a local sidecar on your own machine. The SDK talks to your local sidecar; the sidecar talks directly to the venue. **PMXT's cloud is not in the request path.**

```
Your app  ──localhost──>  pmxt-core (your machine)  ──HTTPS──>  venue API
                          ▲
                          └── holds venue credentials in process memory
```

Venue credentials passed to the sidecar live in your process's RAM for the duration of the request and are garbage-collected after; the sidecar does not persist, log, or cache them. "In process memory" here means **your process, on your machine** — not PMXT's cloud.

For on-chain venues (Polymarket, Limitless, Probable, Opinion, Baozi), "venue credential" means a raw private key — there is no scoped API-key alternative at the protocol layer.

## What each venue requires

Credential type is a property of the venue, not of PMXT. See [Supported Venues](/concepts/venues) for the full credential matrix. The difference between modes is **where the credential lives**:

* **Hosted (Polymarket, Opinion, Limitless):** PMXT never sees the venue private key. You sign EIP-712 locally against the `PreFundedEscrow` domain; PMXT's operator submits with its own key for gas. See [Hosted trading](/concepts/hosted-trading).
* **Self-hosted (any venue):** the venue credential lives on your machine, in your `pmxt-core` process.

## Recommendations

<Note>
  **Use a separate trading wallet** holding only the float you're actively trading. PMXT is non-custodial, but limiting wallet balances limits blast radius from any host compromise on your end.
</Note>

<Note>
  **Pick hosted unless you have a specific reason not to.** Self-host when you need raw venue credentials, sub-100ms latency, or regulatory custody requirements.
</Note>

### Best practices

* **Rotate credentials regularly.** If a venue supports key rotation (Kalshi, Polymarket L2 API keys), rotate on a schedule.
* **Monitor your positions.** Set up alerts on your venue accounts for unexpected trades or withdrawals.
* **Limit wallet balances.** Keep only active trading capital in the wallet you use with PMXT.
* **Revoke unused PMXT API keys.** If you stop using hosted, revoke your key from the [dashboard](https://pmxt.dev/dashboard) so it cannot be used to make calls on your behalf. (Self-hosted does not need a `pmxt_api_key`.)

## Disclaimer

**PMXT is provided "as is" without warranty of any kind.** By using PMXT in either mode, you acknowledge and accept the following:

* **You are responsible for the security of your credentials.** In hosted mode, your private key never reaches PMXT, but your `pmxt_api_key` and your signing wallet are still yours to protect. In self-hosted mode, the entire venue credential surface is on your machine and on you.
* **PMXT is not responsible for any lost, stolen, or mismanaged funds.** This includes but is not limited to losses from unauthorized trades, venue API changes, software bugs, service outages, smart-contract bugs in the unaudited `PreFundedEscrow` (see [Hosted trading](/concepts/hosted-trading)), or security incidents.
* **On-chain transactions are irreversible.** Blockchain transactions cannot be reversed or charged back. Funds sent or traded through on-chain venues are final.
* **You should only risk what you can afford to lose.** Prediction markets carry inherent financial risk independent of the software used to access them.

For users who require full custody and zero third-party trust, [self-hosted](/guides/self-hosted) is the right mode.