Skip to main content
A pod is a segregated book of capital. It is the primary organizing object in ParlayX, and most of what you configure, you configure on a pod. Without pods, a fund running four strategies across two venues is running them out of the same account balance, with the same credentials, and with no way to tell one strategy’s exposure from another’s. Pods restore the structure a desk already has internally but cannot express at the venue.

What belongs to a pod

Pod readiness

A pod moves through four states before it can trade. The console shows where each pod stands.
1

Created

The pod exists and can be named and configured. No capital, no venue access yet.
2

Wallet delegated

The pod’s wallet is in place and authorized to execute on on-chain venues.
3

Funded

Capital has reached the pod and is available to trade.
4

Venue-ready

Venue connections resolve. The pod can place orders.
A pod that is not venue-ready will reject orders rather than route them somewhere unintended. Failures at this layer are explicit; they do not fall back to another pod’s capital or another pod’s credentials.

Adding actors to a pod

Actors are granted to a pod, not to the organization at large. Granting an actor a pod mints an API key bound to that pairing, and the grant can be withdrawn at any time — which severs that actor from that pod immediately, without affecting their access to any other pod. See Actors and Permissions.

Controls

Two controls sit on the pod itself:
  • Pause — stops the pod from placing new orders while leaving existing positions untouched.
  • Revoke access — withdraws ParlayX’s ability to execute for the pod.
Neither closes a position. ParlayX does not close positions under any circumstance. See Offboarding and Revocation.

How separation actually works

Pod separation is enforced differently depending on the venue, and it is worth being precise about it. On wallet venues, the boundary is enforced by the chain. Each pod holds its own wallet, that wallet cannot be moved to another pod, and no pod can spend another pod’s balance. Separation is absolute. On account venues such as Kalshi, the venue’s unit of truth is the account, and accounts are KYC’d to your entity — you cannot mint them freely. ParlayX’s default is one account to one pod, which preserves the boundary. If instead you tie a single venue account to several pods, ParlayX will attribute activity to the correct pod, but at the venue the capital is one commingled balance. That is an advanced configuration, and it should be chosen deliberately.
If you need hard capital isolation between pods on an account-based venue, it requires either a separate venue account per pod, or venue-side subaccounts where the venue supports them. Software attribution alone does not isolate capital.
Venues and credentials covers this in more detail.

Choosing how many pods

There is no single right answer, but the useful test is: would you want this book funded, measured, and permissioned on its own? If yes, it is a pod. Common patterns:
  • One pod per strategy, when strategies should not share capital.
  • One pod per trader, when attribution matters more than strategy separation.
  • One pod per client or counterparty book, for hedging and insurance desks.
  • One pod per venue, when you want venue exposure ring-fenced.

Pod counts are set by plan. Email contact@parlayx.com to discuss what your desk needs.