Skip to main content
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.
ModeWhat you give PMXTWhat touches PMXT’s serverCustody
Hosted (default)An EIP-712 signature per order — never your private keyOutcome target, signatures, public wallet addressUSDC in the on-chain PreFundedEscrow you control via the timelock
Self-hostedRaw venue credentials — given to a PMXT process you run on your machineNothing — PMXT’s cloud is not in the loopYour 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 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 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 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.
  • Self-hosted (any venue): the venue credential lives on your machine, in your pmxt-core process.

​
Recommendations

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.
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.

​
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 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 is the right mode.