potd-trader v0.4.0 can buy a manually reviewed Kalshi contract for a Pick of the Day. Start with a separate demo account and dry runs. The 0xinsider signal remains Polymarket-backed; the trader does not discover equivalent Kalshi contracts automatically.
Install v0.4.0
Use Python 3.12+ and uv on macOS or Linux, including WSL. Keep each setup on a local filesystem. Separate machines and copied folders do not share order reservations.kalshi init creates a private folder with .env.kalshi. It starts with KALSHI_ENVIRONMENT=demo and LIVE=no, and does not ask you to paste secrets. The release identifies the shipped commit; uv sync --locked uses the dependency versions in that checkout.
Add your demo credentials
Create a dedicated account at demo.kalshi.co, then create a demo API key using Kalshi’s API key instructions. Demo credentials are separate from production credentials. Kalshi’s demo environment uses mock funds, and its prices and market coverage can differ from production. Use an RSA key of at least 2,048 bits or an Ed25519 key. Save its private PEM locally, restrict it to your user withchmod 600, and edit .env.kalshi in your editor.
Keep the private key in its file. Do not paste it into a chat, shell command, issue, or mapping file.
status reads account state and local order controls. picks shows the current Polymarket picks, including the source token IDs you need to identify a mapping.
Review and map a contract
Find a Kalshi listing for the current pick. You can inspect candidates within a Kalshi series:KALSHI_SERIES_TICKER with the series you want to inspect. Matching team names does not establish that 2 contracts settle the same way. Only binary, $1 Kalshi contracts with default settlement bounds are supported; combo contracts are skipped.
Compare the game, backed team, date, overtime, cancellation, postponement, and tie rules for both providers.
Keep orders disabled while reviewing mappings; run kalshi live off first if you previously enabled them. For each pick you want to trade, choose the Kalshi market ticker, its yes or no outcome, and your own maximum purchase price:
the same event, outcome and settlement rules only after that review.
The command stores the mapping in kalshi-mappings.json. Changed rules or a changed source pick require another mapping. The review also fingerprints the official contract PDFs; missing, unreadable, or changed terms prevent submission.
The destination ceiling is an additional limit. The trader applies the lowest of your mapped Kalshi ceiling, local MAX_PRICE, the source pick’s entry_authorization.max_entry_price, and the source backed price plus local MAX_SLIPPAGE_PCT. These source limits remain conservative guards; they do not estimate a Kalshi return.
The trader does not calculate Kalshi wallet grades or a Kalshi-native pick.
Skip a pick when you cannot establish contract equivalence or find suitable Kalshi liquidity. Demo listings can use fixture events without real settlement rules; those do not qualify merely because their names look similar.
Try a dry run
Ctrl+C to stop the watcher.
The trader buys whole contracts. It checks your destination price ceiling, available funds, and daily reservation limit before submission. A market with insufficient executable liquidity, a stale mapping, or missing safety data is skipped. Available account funds are checked again before a live submission.
Before submission, the trader refuses reported positions or resting orders in the target Kalshi market. Kalshi’s account reads can lag, and there is no atomic check that the market remains flat when an order arrives.
Use a dedicated Kalshi account and its default subaccount 0, the only subaccount this release supports. Do not trade manually or run another trading tool on that account while this trader is active. The shared local ledger coordinates only instances of this tool.
The fee reserve is deliberately larger than an estimated trading fee: it adds 5 setup can buy fewer contracts than you expect from the market price alone. Unsupported or missing fee data prevents submission.
Use API credentials for your own Kalshi account. Broker accounts with external commissions are unsupported; those charges are not included in the exchange fee reserve.
Enable demo orders yourself
After reviewing the dry run, you can enable order submission in the demo folder:live on asks you to type place demo orders in a demo setup. An agent can install the release and perform read-only or dry-run checks; enabling orders remains your action. Live mode in a demo setup submits orders using mock funds.
Each submission is an immediate-or-cancel order. It can fill partly, and the unfilled part does not remain as a resting order. An uncertain submission keeps its reservation and blocks a repeat order until reconciliation establishes its state.
A zero-fill submission response without a complete terminal order record also stays reserved. reconcile must establish that the order cannot fill before the reservation is released.
Stop and reconcile
live off writes a persistent HALT file and prevents new submissions from watchers using the same folder. An order already sent can still fill. reconcile reads provider order state; it does not submit a replacement order. Incomplete records or mismatched identity, outcome, price, or fee bounds keep the entry unresolved.
Orders and reservations are stored in kalshi-ledger.json. Keep uncertain entries in the ledger. Do not delete a ledger, mapping, or lock file while a process is running.
All instances using the same Kalshi account must use one shared setup folder on one local filesystem. Once a ledger exists, changing its environment, account identity, or file paths stops trading until you restore the original setup.
Use a separate production setup
Stop the demo watcher before creating a production setup. From the release checkout:.env.kalshi, review new mappings there, and repeat the dry run. The new folder starts with orders disabled. Demo mappings and ledger entries do not transfer to production.
In the production folder, kalshi live on asks you to type spend real money on Kalshi.
Production orders spend real funds. Kalshi’s account and regional eligibility requirements apply. The tool does not guarantee profit or that a Kalshi contract exists for every pick.
Settings and spending limits
The Kalshi workflow loads.env.kalshi from the active folder. Inherited environment variables do not override its settings. Keep Kalshi and Polymarket setups separate.
The ledger reserves spending before submission. Uncertain orders keep consuming budget until reconciliation proves what happened, including across a UTC date change.
A confirmed fill keeps the full original reservation against its UTC submission day, including a partial fill. A confirmed zero-fill terminal order releases its reservation. Separate folder copies do not coordinate this limit.
What leaves your machine
Your PEM private key stays local and signs authenticated Kalshi requests. Package installation also contacts package hosts. See the trader repository for source, release verification, and the complete command reference.