On Saturday, February 28, U.S. and Israeli forces launched coordinated strikes on Iran. Ayatollah Ali Khamenei, Iran’s Supreme Leader, was killed. On Kalshi, a $54 million market titled “Ali Khamenei out as Supreme Leader?” had been running for days, heavily promoted by the platform itself on social media. Traders who held YES shares expected a full $1.00 payout. They did not get it.
Instead, Kalshi invoked a clause buried in the contract’s fine print — what is now being called the “death carveout.” Because U.S. commodity law prohibits markets that directly settle on death or assassination, the contract specified that if Khamenei died, positions would settle at the last traded price before his death rather than resolving to YES or NO. Traders who bought YES at $0.06 expecting a $1.00 payout received approximately $0.02 per share based on the pre-strike price.
One trader who spent $303.90 on YES shares expecting a $4,588 return received $91.76.
Kalshi CEO Tarek Mansour defended the decision, stating the rules were published from the outset. The platform reimbursed all fees and covered net losses, reportedly absorbing $2.2 million. Mansour acknowledged the contract language was “grammatically ambiguous” and committed to clearer disclosures going forward. On March 2, Kalshi filed a formal rulebook amendment with the CFTC codifying the death settlement mechanism under the name “Draft Death Caveat Rulebook Amendment,” modifying Rule 6.3.
The human drama here is well-covered. The Washington Post, NPR, WIRED, Bloomberg, and Fox Business have all reported the trader outrage, the insider trading allegations on Polymarket, and Senator Chris Murphy’s pledge to introduce legislation banning these markets entirely.
What hasn’t been covered — and what matters most for the AgentBets.ai audience — is this: the Khamenei market is the first major case study in resolution risk for automated prediction market agents. And the lessons are architectural, not just emotional.
What Actually Went Wrong (Mechanically)
Let’s be precise about what happened, because the details matter for anyone writing agent logic.
The CFTC-filed contract terms said positions would settle at the “last traded price (prior to the death).” The market page said “last traded price prior to confirmed reporting of death.” Those are different things. The time between Khamenei’s actual death and confirmed public reporting was several hours — hours during which traders were actively buying YES shares at prices reflecting rumors, not confirmed facts.
Kalshi recorded the pre-death price at 1:14 AM ET on Saturday. Trading continued until Kalshi halted the market at approximately 2:59 PM ET and formally closed contracts at 10:06 PM ET. That’s a roughly 14-hour window where traders were operating on one set of assumptions while the platform’s resolution logic pointed to a different outcome.
Kalshi added a “Green Box” warning to the market page after strikes had already begun, not as a rule change but as a visual clarification. The timing meant some traders entered positions without ever seeing the warning.
Meanwhile, on Polymarket — which listed a comparable contract — the market resolved to YES and paid out normally. On Gemini’s new exchange, the contract was structured as “Khamenei remains in office through March 31,” and resolved to NO after his death, also paying out in a binary fashion.
Three platforms. The same real-world event. Three different resolution outcomes. This is the environment your agent operates in.
Why This Is an Architecture Problem, Not Just a Platform Problem
If you’re running a manual trading account on Kalshi, the death carveout cost you money and taught you to read the fine print. Frustrating, but recoverable. You update your process and move on.
If you’re running an autonomous agent that trades across prediction markets, the implications are deeper. Here’s what the Khamenei incident reveals about resolution risk for automated systems:
1. Your Agent Cannot Assume Binary Resolution
Most prediction market agent logic treats contracts as binary: the event happens or it doesn’t, and the contract resolves to $1.00 or $0.00. The Khamenei market proves that assumption is wrong. A contract can resolve to a third state — settlement at last-traded-price — that your agent may not have modeled.
What to build: Your agent’s contract parser needs to ingest resolution rules, not just price data. When your agent evaluates whether to enter a position, it should check for carveout clauses, conditional resolution criteria, and any scenario where payout does not equal $0 or $1. This is metadata that most trading bots ignore entirely. The Kalshi API exposes contract rules — your agent should read them. (See our Prediction Market API Reference for endpoint details.)
2. Cross-Platform Arbitrage Depends on Resolution Alignment
The most common agent strategy — detecting price discrepancies between Kalshi and Polymarket on the same event — assumes both platforms will resolve the same way for the same outcome. The Khamenei market proved they won’t. Kalshi resolved to last-traded-price. Polymarket resolved to YES. Gemini resolved to NO (on the inverse framing). An arbitrage agent that bought YES on Kalshi and sold NO on Polymarket expecting symmetric resolution would have lost money on Kalshi while profiting on Polymarket — potentially a net loss depending on position sizing.
What to build: Before executing cross-platform arbitrage, your agent needs a resolution-alignment check. Compare the resolution criteria across platforms for the same underlying event. If the criteria diverge — especially on edge cases like death, force majeure, or ambiguous phrasing — your agent should flag the pair as non-arbitrageable or apply a risk discount to the expected return.
3. Market Halts Are an Execution Risk Your Agent Needs to Handle
Kalshi halted trading on the Khamenei market at 2:59 PM ET. If your agent had an open order or was in the middle of a rebalancing operation when the halt occurred, it would have been stuck. Pending orders may not fill. Hedging positions on other platforms can’t be unwound against a frozen market. The API returns errors your agent may not have error-handling logic for.
What to build: Implement halt detection in your execution layer. If the API returns unexpected errors on a specific market while functioning normally on others, your agent should recognize a potential market halt, freeze activity on that contract, and avoid entering offsetting positions on other platforms until the halt resolves. This is the prediction market equivalent of a circuit breaker, and your agent needs one. (See our Security Best Practices for the full production checklist.)
4. The “Confirmed Reporting” Timing Gap Is a Data Problem
The gap between Khamenei’s death and “confirmed reporting of death” spanned hours. During that window, social media was full of unconfirmed reports, the price was moving, and traders were entering positions based on incomplete information. For a human, this is a judgment call. For an agent, it’s a data integrity problem: which sources does your agent treat as “confirmed”?
If your agent ingests Twitter sentiment or news feeds to trigger trades, it may have entered a YES position after the death but before official confirmation — exactly the window where Kalshi’s resolution logic would produce the worst outcome.
What to build: For markets involving geopolitical events, leadership changes, or any outcome that could involve death or force majeure, your agent’s intelligence layer needs a confirmation threshold — multiple independent sources confirming the event before the agent trades on it. One tweet is not confirmation. An official government statement is. Your agent needs to know the difference.
5. Platform Rule Changes Can Be Retroactive in Practice
Kalshi says the rules were not changed. Technically, that appears to be true — the death carveout was in the CFTC-filed contract terms from the start. But the “Green Box” warning was added to the user-facing market page after strikes had begun. And the rulebook amendment filed with the CFTC on March 2 (the “Draft Death Caveat Rulebook Amendment” for Rule 6.3) codifies a practice that was, at best, ambiguously documented before.
For agent operators, the takeaway is clear: platforms will evolve their rules in response to edge cases, and some of those changes will affect how markets your agent is already positioned in will resolve.
What to build: Your agent should snapshot contract rules at the time of position entry and flag if the platform’s published rules change after the position is open. This is a monitoring function, not a trading function — but it’s the kind of safeguard that prevents your agent from being caught by a resolution rule that didn’t exist (or wasn’t prominently displayed) when it entered the trade.
The Bigger Picture: Resolution Risk Is the Underpublicized Risk
Everyone talks about market risk, execution risk, and liquidity risk for trading bots. Almost nobody talks about resolution risk — the risk that the platform will resolve a contract in a way that contradicts the market’s apparent consensus. The Khamenei market put $54 million behind a resolution assumption that turned out to be wrong.
For the prediction market agent ecosystem, this is a maturity moment. The agents that survive will be the ones whose builders internalized this lesson and built resolution-awareness into every layer of the stack: the intelligence layer (data confirmation thresholds), the trading layer (resolution-alignment checks), the execution layer (halt detection and circuit breakers), and the wallet layer (position-sizing that accounts for non-binary outcomes).
Kalshi lost $2.2 million and its users’ trust. Polymarket paid out and is now dealing with insider trading allegations and a senator promising legislation. Gemini quietly resolved and moved on. The platforms are each learning their own lessons.
As an agent builder, your lesson is different: the contract is not the outcome. The resolution rules are. And your agent needs to read both.
For API endpoint documentation covering how to read contract resolution rules programmatically, see our Prediction Market API Reference. For the full agent security production checklist, see Security Best Practices.
Have a tip, a correction, or a resolution-risk war story? Reach us at [email protected].