Gap
core/docs/SETUP_KALSHI.md states: "Tip: Kalshi supports both file paths and raw PEM strings as the private key value." No code anywhere in core, the TypeScript SDK, or the Python SDK reads a private key from a file path. KalshiAuth passes credentials.privateKey directly into Node's crypto.createSign(...).sign({ key: privateKey, ... }), with the only transformation being an escaped-\n fix for values pasted into .env files — there is no fs.readFileSync/existsSync call anywhere in the Kalshi integration.
Core
core/src/exchanges/kalshi/auth.ts:50-77 — comment: "Allow input of private key in both raw string or PEM format... We assume the user provides a valid PEM." No filesystem read anywhere in core/src/exchanges/kalshi/.
TypeScript SDK
N/A — the private key string is passed straight through to core; no client-side file-path handling exists to compensate for the doc's claim.
Python SDK
N/A — same.
Evidence
Doc: core/docs/SETUP_KALSHI.md:15-16. Source: core/src/exchanges/kalshi/auth.ts:50-77 shows the private key is used directly as PEM content in crypto.sign(), with no file-path resolution step (grep -rn "readFileSync\|existsSync" core/src/exchanges/kalshi/ returns no matches).
Impact
A user who follows the doc's tip and passes a file path (e.g., ~/keys/kalshi.pem) as the private key value would have that literal path string handed straight to crypto.sign() as if it were PEM content, which fails at signing time with an opaque crypto error — not the documented, graceful behavior.
Found by automated Core-to-SDK surface coverage audit
Gap
core/docs/SETUP_KALSHI.mdstates: "Tip: Kalshi supports both file paths and raw PEM strings as the private key value." No code anywhere in core, the TypeScript SDK, or the Python SDK reads a private key from a file path.KalshiAuthpassescredentials.privateKeydirectly into Node'scrypto.createSign(...).sign({ key: privateKey, ... }), with the only transformation being an escaped-\nfix for values pasted into.envfiles — there is nofs.readFileSync/existsSynccall anywhere in the Kalshi integration.Core
core/src/exchanges/kalshi/auth.ts:50-77— comment: "Allow input of private key in both raw string or PEM format... We assume the user provides a valid PEM." No filesystem read anywhere incore/src/exchanges/kalshi/.TypeScript SDK
N/A — the private key string is passed straight through to core; no client-side file-path handling exists to compensate for the doc's claim.
Python SDK
N/A — same.
Evidence
Doc:
core/docs/SETUP_KALSHI.md:15-16. Source:core/src/exchanges/kalshi/auth.ts:50-77shows the private key is used directly as PEM content incrypto.sign(), with no file-path resolution step (grep -rn "readFileSync\|existsSync" core/src/exchanges/kalshi/returns no matches).Impact
A user who follows the doc's tip and passes a file path (e.g.,
~/keys/kalshi.pem) as the private key value would have that literal path string handed straight tocrypto.sign()as if it were PEM content, which fails at signing time with an opaque crypto error — not the documented, graceful behavior.Found by automated Core-to-SDK surface coverage audit