Gap
In core, getExecutionPrice is a thin wrapper around getExecutionPriceDetailed, so both functions always agree on sorting (best price first) and zero-size-level filtering. The TypeScript SDK instead reimplements both methods independently on the Exchange class, and getExecutionPrice skips the sort + zero-filter that its sibling getExecutionPriceDetailed applies — so the two SDK methods can disagree on the same order book if it isn't already sorted or contains zero-size levels.
Core
core/src/utils/math.ts:3-10 — getExecutionPrice simply calls getExecutionPriceDetailed(orderBook, side, amount) and returns result.fullyFilled ? result.price : 0. getExecutionPriceDetailed (core/src/utils/math.ts:18-54) filters l.size > 0 and sorts levels best-price-first before walking them.
TypeScript SDK
sdks/typescript/pmxt/client.ts:2896-2908 — getExecutionPrice walks orderBook.asks/orderBook.bids directly with no .filter(l => l.size > 0) and no .sort(...), unlike its own sibling getExecutionPriceDetailed at client.ts:2918-2953, which does both (matching core exactly).
Python SDK
Not checked in this pass — reported as matching core field-for-field by a prior check in this audit, but that check did not specifically re-verify sort/filter behavior line-by-line; worth a quick spot check.
Evidence
Read client.ts:2896-2908 against client.ts:2918-2953 in the same file — the sort and zero-filter present in the latter are absent from the former, while core's two functions (math.ts:3-54) are guaranteed consistent because one calls the other.
Impact
If a caller passes an OrderBook whose asks/bids aren't pre-sorted by price (e.g. built manually, or from a venue that doesn't guarantee order), exchange.getExecutionPrice() and exchange.getExecutionPriceDetailed() can return different results for the same inputs on the TypeScript SDK, whereas core guarantees they never diverge.
Found by automated Core-to-SDK surface coverage audit
Gap
In core,
getExecutionPriceis a thin wrapper aroundgetExecutionPriceDetailed, so both functions always agree on sorting (best price first) and zero-size-level filtering. The TypeScript SDK instead reimplements both methods independently on theExchangeclass, andgetExecutionPriceskips the sort + zero-filter that its siblinggetExecutionPriceDetailedapplies — so the two SDK methods can disagree on the same order book if it isn't already sorted or contains zero-size levels.Core
core/src/utils/math.ts:3-10—getExecutionPricesimply callsgetExecutionPriceDetailed(orderBook, side, amount)and returnsresult.fullyFilled ? result.price : 0.getExecutionPriceDetailed(core/src/utils/math.ts:18-54) filtersl.size > 0and sorts levels best-price-first before walking them.TypeScript SDK
sdks/typescript/pmxt/client.ts:2896-2908—getExecutionPricewalksorderBook.asks/orderBook.bidsdirectly with no.filter(l => l.size > 0)and no.sort(...), unlike its own siblinggetExecutionPriceDetailedatclient.ts:2918-2953, which does both (matching core exactly).Python SDK
Not checked in this pass — reported as matching core field-for-field by a prior check in this audit, but that check did not specifically re-verify sort/filter behavior line-by-line; worth a quick spot check.
Evidence
Read
client.ts:2896-2908againstclient.ts:2918-2953in the same file — the sort and zero-filter present in the latter are absent from the former, while core's two functions (math.ts:3-54) are guaranteed consistent because one calls the other.Impact
If a caller passes an
OrderBookwhoseasks/bidsaren't pre-sorted by price (e.g. built manually, or from a venue that doesn't guarantee order),exchange.getExecutionPrice()andexchange.getExecutionPriceDetailed()can return different results for the same inputs on the TypeScript SDK, whereas core guarantees they never diverge.Found by automated Core-to-SDK surface coverage audit