HunchExchange has no fetchMyTrades, fetchClosedOrders, or fetchAllOrders despite a working createOrder/fetchBalance/fetchPositions path

[realfishsam]

Gap

HunchExchange implements a full trade-execution path (createOrder with the x402/EIP-3009 USDC micropayment flow), fetchBalance, and fetchPositions, but never implements fetchMyTrades, fetchClosedOrders, or fetchAllOrders. All three fall through to PredictionMarketExchange's base stub and throw "Method X not implemented." Since Hunch is parimutuel/instant-execution (no resting order book — fetchOpenOrders correctly always returns [] and cancelOrder/fetchOrder correctly always throw, since there's nothing to cancel or look up mid-flight), fetchMyTrades in particular is the only way a user could retrospectively see what they've traded — and it's entirely absent.

Core

• core/src/exchanges/hunch/index.ts (449 lines) implements: fetchMarketsImpl (238), fetchEventsImpl (243), fetchOHLCV (250), fetchOrderBook (259), fetchTrades (264, public trade tape sourced from research.oddsHistory), createOrder (272), cancelOrder (346, always throws — correct for parimutuel), fetchOrder (350, always throws — correct), fetchOpenOrders (354, always [] — correct), fetchPositions (358), fetchBalance (364), watchOrderBook (372), watchTrades (377), close (382).
• No override exists for fetchMyTrades, fetchClosedOrders, or fetchAllOrders anywhere in the file — confirmed via full-file read. Each resolves to the base stub in core/src/BaseExchange.ts (fetchMyTrades at line 1237, fetchClosedOrders at 1252, fetchAllOrders at 1267), all of which throw.
• Unlike cancelOrder/fetchOrder/fetchOpenOrders (which are legitimately no-ops/empty for a parimutuel venue with no resting orders — each is explicitly implemented to return the correct trivial value), fetchMyTrades/fetchClosedOrders/fetchAllOrders have no implementation at all, not even a trivial one. Given createOrder already writes a completed trade (there is no "open" state), the natural analogue of "my order history" for this venue is exactly what fetchMyTrades should return, and the raw material (research.oddsHistory, already used to build the public fetchTrades tape) appears to be per-market rather than per-user, so a per-user filtered view isn't currently wired up anywhere.

TypeScript SDK

N/A — core-level gap. sdks/typescript/pmxt/client.ts's generated fetchMyTrades/fetchClosedOrders/fetchAllOrders proxy to core and would work immediately once core implements them for this venue.

Python SDK

N/A — same; sdks/python/pmxt/client.py's fetch_my_trades/fetch_closed_orders/fetch_all_orders proxy to core with no SDK-side change needed.

Evidence

Full read of core/src/exchanges/hunch/index.ts (449 lines): the class implements every other member of the unified order/trade surface, including the harder x402 payment-authorization flow for createOrder, but has zero call sites for a per-user trade or order history endpoint. No capabilityOverrides entry documents these three as an intentional 'emulated' or false exclusion (contrast with e.g. Rain's capabilityOverrides.fetchClosedOrders = 'emulated' in core/src/exchanges/rain/index.ts:79-81) — the omission looks unintentional rather than a documented venue limitation.

Impact

Neither SDK can retrieve a Hunch user's own trade history or "closed order" equivalent record — a bot that executes trades via createOrder/create_order has no way to programmatically confirm or audit what it has actually traded on this venue, beyond re-deriving state from fetchPositions/fetchBalance deltas. This breaks the standard "place a trade, then verify it in history" pattern that works on every other venue.

---

Found by automated Core-to-SDK surface coverage audit