Trade type missing outcomeId field in both SDKs

[realfishsam]

Gap

The core Trade type includes outcomeId?: string — the outcome this trade belongs to. Neither the TypeScript SDK Trade interface nor the Python SDK Trade dataclass includes this field. When the sidecar returns trade objects with outcomeId set, the field is silently dropped by the SDK mapping layer.

Core

File: core/src/types.ts line 159

export interface Trade {
    id: string;
    timestamp: number;
    price: number;
    amount: number;
    side: 'buy' | 'sell' | 'unknown';
    /** The outcome this trade is for (if known). */
    outcomeId?: string;
}

outcomeId identifies which outcome token the trade was for. This is populated by exchanges that return per-outcome trade history — for example, Polymarket trades on a specific CLOB token ID. Without it, callers who receive a flat list of trades across outcomes cannot re-group them.

Note: UserTrade extends Trade, so UserTrade also inherits this field in the core. The Python SDK UserTrade explicitly adds outcome_id (models.py line 337), but the base Trade type does not have it, creating an inconsistency.

TypeScript SDK

Missing — sdks/typescript/pmxt/models.ts Trade interface has five fields (id, timestamp, price, amount, side) but no outcomeId. The UserTrade interface (models.ts line 199) adds outcomeId?: string separately — but the base Trade type, which is what fetchTrades() returns, lacks it.

Python SDK

Missing from base — sdks/python/pmxt/models.py Trade dataclass (line 310) has five fields (id, timestamp, price, amount, side) but no outcome_id. The UserTrade dataclass (line 329) adds outcome_id: Optional[str] explicitly, but the base Trade class, which is what fetch_trades() returns, does not.

Evidence

grep -n "outcomeId" sdks/typescript/pmxt/models.ts returns line 219 (in UserTrade only, not in Trade).
grep -n "outcome_id" sdks/python/pmxt/models.py returns line 337 (in UserTrade only, not in Trade).
grep -n "outcomeId" core/src/types.ts returns line 159 (in Trade).
Both SDKs' _convert_trade / convertTrade internal helpers map to their respective Trade types — if the field is absent from the type, it is stripped from the object even if the sidecar populates it.

Impact

Callers using fetchTrades(outcomeId) receive trades already scoped to an outcome, so they may not need the field. But callers who use exchange-level trade streams (or reconstruct trade history across outcomes) cannot identify which outcome each Trade belongs to. The asymmetry with UserTrade — which does carry outcomeId — is confusing: the same underlying data is only partially typed depending on which method returned the trade.

---

Found by automated Core-to-SDK surface coverage audit