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 (default) | An EIP-712 signature per order — never your private key | Catalog UUIDs, signatures, public wallet address | USDC in the on-chain PreFundedEscrow you control via the timelock |
| 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 |
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)
- The SDK calls
POST /v0/trade/build-order with catalog UUIDs and parameters. No key, no signature yet.
- The server returns an unsigned EIP-712 typed-data payload bound to the Polygon
PreFundedEscrow domain.
- The SDK signs the payload locally, in your process, with your private key.
- 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: catalog UUIDs, your public wallet address, and the signature. Not the private key. Even if PMXT’s server were fully compromised, an attacker could not extract your key from a signature.
Funds custody: USDC sits in the on-chain PreFundedEscrow. Withdrawals are timelocked and user-only — PMXT’s operator key cannot move USDC without a per-order EIP-712 signature from you. See Hosted Custody Model for the deployed addresses, the full admin model, and the raw contract calls that get your USDC out without PMXT’s server.
The on-wire authorization to call trade.pmxt.dev is the pmxt_api_key. The key alone cannot move funds; it can only forward signed orders and read public position data. Keep it server-side, never in a browser bundle.
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
What each venue requires
Same table for both modes — the credential type is a property of the venue, not of PMXT:
| Venue | Credential type | Controls funds? |
|---|
| Polymarket | EVM private key | Yes |
| Limitless | EVM private key | Yes |
| Probable | EVM private key | Yes |
| Opinion | EVM private key | Yes |
| Baozi | Solana keypair | Yes |
| Kalshi | RSA key pair (API-scoped) | No |
| Smarkets | Email + password (session-scoped) | No |
| Myriad | API key (read-scoped) | No |
- Hosted (Polymarket, Opinion): PMXT never sees the venue private key. You sign EIP-712 orders locally against the Polygon
PreFundedEscrow domain; PMXT’s operator key submits the resulting transactions on Polygon (and BSC for Opinion’s cross-chain leg) using its own key for gas. Funds are constrained by the contract — see Hosted Custody Model.
- Self-hosted (any venue): the venue credential lives on your machine, in your
pmxt-core process. PMXT’s cloud is not involved.
Hosted mode does not currently support every venue (see Hosted trading). For unsupported venues, self-hosted is the only path and you provide the venue’s raw credential to your local sidecar.
Recommendations
Use a dedicated trading wallet. Do not use your primary wallet or one holding funds beyond what you intend to trade. Create a separate wallet, fund only what you need, and use that wallet’s private key with PMXT — for signing EIP-712 in hosted mode or as a venue credential in self-hosted mode.
Pick hosted unless you have a specific reason not to. Hosted gives you on-chain custody you control via the timelock, and PMXT’s server never sees a private key. Self-host when you need raw venue credentials, sub-100ms latency, or have regulatory custody requirements.npm install pmxtjs
# or
pip install pmxt
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 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 Custody Model), 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 is the right mode. 
