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

# Venues

> One integration across Kalshi and Polymarket.

ParlayX connects to Kalshi and Polymarket. You integrate once and reach both. New venues are added on customer request, typically in one to two weeks.

## Two shapes of venue

Venues differ in a way that matters more than their APIs do: what identity you trade under.

<CardGroup cols={2}>
  <Card title="Wallet venues" icon="wallet">
    **Polymarket**

    You trade under a wallet. Wallets can be created freely. Each pod is tied to its own wallet and its own set of permissions. 
  </Card>

  <Card title="Account venues" icon="building-columns">
    **Kalshi**

    You trade under a KYC'd account belonging to your entity. Accounts cannot be created freely.
  </Card>
</CardGroup>

That difference determines how each venue reaches a pod, and how strong the separation between pods is.

## Connecting a wallet venue

Nothing to connect. Each pod is created with its own wallet, and on-chain venues execute through it. The wallet belongs to the pod permanently.

Separation between pods is enforced by the chain. One pod cannot spend another pod's balance, regardless of configuration.

## Connecting an account venue

Three steps, done once per account:

<Steps>
  <Step title="Connect the account at the organization">
    An admin supplies the venue API credential. It is verified on intake and stored encrypted, with the signing key held in a hardware module.
  </Step>

  <Step title="Tie it to a pod">
    An explicit grant that lets that pod trade through that account. Untied pods cannot reach it.
  </Step>

  <Step title="Actors trade through the tie">
    Actors in the pod place orders. They never see or handle the credential.
  </Step>
</Steps>

You can connect a different account per pod, or tie one account to several pods. The choice has consequences.

## Separation between pods, stated plainly

|                                       | Wallet venues               | Account venues                                        |
| ------------------------------------- | --------------------------- | ----------------------------------------------------- |
| Where venue truth sits                | The pod's wallet            | Your organization's account                           |
| Pod boundary                          | Hard, enforced by the chain | Soft, enforced by attribution                         |
| Isolation with one credential per pod | Complete                    | Complete                                              |
| Isolation with a shared credential    | Not applicable              | Attribution only — capital is commingled at the venue |
| Blast radius of removing a credential | One pod                     | Every pod tied to it                                  |

<Warning>
  Tying one venue account to several pods gives you correct per-pod attribution in ParlayX, but the venue still sees one balance. If a strategy in one pod draws the account down, the other pods tied to it feel it. Use one account per pod when the separation needs to be real.
</Warning>

We are direct about this because the alternative — implying every pod is a hard boundary everywhere — would not survive contact with your first margin call.

## Order sizing rules per venue

Each venue quantizes order sizes to its own grid and enforces its own minimum. We reject a size the venue cannot execute rather than sending it and letting the venue round it down silently.

**Polymarket**

| Rule                 | Value                                                        |
| -------------------- | ------------------------------------------------------------ |
| Share size precision | 2 decimal places                                             |
| Minimum order size   | Set per market by the venue — 5 shares on the markets we see |
| Price precision      | The market's tick size                                       |

A share-denominated size finer than 2 decimal places is rejected, and the error names the size that does execute. This applies to the shares on a sell and the size on a limit order of either side; a market buy is sized in dollars and is not affected.

<Warning>
  **Closing a position can leave a residue, and the residue cannot be sold.** Selling 14.28 of a 14.285713-share position leaves 0.005713 shares behind. That remainder rounds to zero on the size grid and sits under the venue's minimum order size, so no further sell order can ever clear it — retrying will only be rejected.

  The remainder is not lost. It is redeemed with the rest of the position once the market resolves, at which point it pays out or expires worthless like any other holding. Treat a sub-share leftover as awaiting resolution, not as a failed close.
</Warning>

## Connection health

Venue credentials are monitored and surfaced in the console:

| State       | Meaning                                                     |
| ----------- | ----------------------------------------------------------- |
| **Active**  | Working. Orders route normally                              |
| **Failed**  | A transient problem on our side. Recovers on its own        |
| **Revoked** | The venue rejected the credential. Reconnect with a new one |
| **Invalid** | Never authenticated. Check what was supplied and replace it |

Revoked and invalid are terminal — they are resolved by supplying a new credential, not by retrying.

<Note>
  A credential that has expired or been rotated at the venue cannot be detected until a call fails. If you rotate a key on the venue side, update it here at the same time.
</Note>