← Back to blog
·5 min read·SettleRisk Team

Retroactive Rule Changes: The Highest-Impact Risk Driver

Deep Dive

Executive Summary

RETROACTIVE_RULE_CHANGE carries 18 base points — the highest in SettleRisk's driver taxonomy — and the highest max_points cap at 28. The reason: in the dataset of disputed markets going back to 2024, retroactive changes are by far the highest-loss bucket per occurrence, with a median frozen-capital duration of 31 days and a 47% probability of resolution reversal. This post walks through the detection patterns, the documented case studies, and the early-warning subscription strategy.

Core Concept

A retroactive rule change is any modification to a market's resolution rules after the market has accepted bets. SettleRisk's extractor detects three patterns that enable retroactive changes (even before any change has occurred):

| Pattern | Example | |---------|---------| | Explicit reservation clause | "Platform reserves the right to amend rules" | | Vague rule binding | "Rules current as of resolution date" (vs. trade date) | | Open-ended discretion | "Subject to platform interpretation" |

The driver also detects three patterns that indicate a change has already happened:

| Pattern | Example | |---------|---------| | Rules-text diff | Frontmatter hash changed mid-market | | Methodology update notice | Platform posted a methodology change | | Resolver-published clarification | Resolution rationale references new criteria |

The combination of enabling patterns + observed change is what pushes the driver toward max_points.

Worked Example

The 2024 Bitcoin "approximately $100K" case is canonical. The original rules said the market would resolve YES if Bitcoin reached "approximately $100,000" by year-end. When BTC peaked at $99,800 and traders disputed the resolution, the platform's resolution committee retroactively defined "approximately" as "within 0.5% of $100,000" — which excluded the $99,800 print and resolved the market NO. Traders who took the YES side based on a reasonable reading of the original rules absorbed the loss.

SettleRisk's tracking:

from settlerisk import SettleRiskClient

client = SettleRiskClient(api_key="sk-...")
snapshots = client.get_score_snapshots("polymarket", "0xbtc100k-2024")

for s in snapshots:
    print(f"{s.scored_at}  score={s.aggregate_risk_score}  rules_sha256={s.rules_sha256[:12]}...")

2024-11-15  score=58  rules_sha256=a4b2c98e1f33...
2024-12-22  score=58  rules_sha256=a4b2c98e1f33...
2024-12-30  score=84  rules_sha256=d7f9e21a5c08...  # Rules changed
2024-12-31  score=84  rules_sha256=d7f9e21a5c08...

The Dec 30 jump in score and rules_sha256 change is the signal. Markets that crossed this pattern in the SettleRisk dataset had a 47% reversal-on-dispute rate.

Webhook subscription for early warning:

// Receiver pattern that fires immediately on a rules.changed event
case "rules.changed":
  const { market_id, old_rules_sha256, new_rules_sha256 } = data;
  console.log(`RULES CHANGED on ${market_id}: ${old_rules_sha256.slice(0,12)} -> ${new_rules_sha256.slice(0,12)}`);

  // Lock positions in the affected market until manual review
  await lockMarket(market_id, "rules_changed_review");

  // Re-pull the score to capture the new driver attribution
  const newScore = await settleriskClient.getRiskScore(/* ... */);
  await reprice(market_id, newScore);
  break;

Implementation Notes

Subscribe to rules.changed. This is the highest-signal webhook event in the SettleRisk catalog. Operators who don't subscribe miss the early warning by 2-6 hours on average.

Persist rules_sha256 with every traded position. If rules change post-trade, the SHA-256 mismatch is the audit-trail anchor. Without it, you cannot prove the rules differed at execution.

Treat enabling patterns as MEDIUM-tier minimum. Even without an observed change, a market with an explicit reservation clause carries enough latent risk to warrant elevated tier.

Use historical snapshots for backtests. GET /v1/markets/.../score-snapshots returns the full history. Markets that crossed the rules-change pattern are detectable from the snapshot sequence.

| Pattern | Recommended action | |---------|--------------------| | Reservation clause in rules | Size at 60% of base | | Observed rules change mid-life | Lock position, manual review | | Methodology update post-resolution | Treat as confirmed retroactive | | Resolver clarification with new criteria | Flag for dispute likelihood | | Multiple snapshot transitions | Treat as high-volatility rules base |

Don't trade markets near platform policy-update cycles. Some platforms batch methodology updates quarterly. Markets resolving within 7 days of a planned update carry elevated retroactive risk by construction.

Failure Modes

1. Trusting the original rules. Traders who size based on the rules at trade time and don't monitor for changes get caught when rules update. Subscribe to rules.changed.

2. Ignoring the SHA-256 hash. Two rule texts that look the same can differ in whitespace or a single phrase. The hash is the only reliable change detector.

3. Treating reservation clauses as boilerplate. Some are; some aren't. The pricing engine treats any reservation clause as a real risk input. So should you.

4. Skipping the snapshot sequence. Score snapshots are append-only. A market with multiple score transitions before resolution is high-volatility — even if the latest score looks reasonable.

5. Failing to lock positions on rules change. Mid-market rule changes invalidate prior pricing. Auto-locking the position pending manual review is the right operational stance.

Checklist

  • [ ] Subscribe to rules.changed webhook
  • [ ] Persist rules_sha256 with every position
  • [ ] Lock positions automatically on rules-change event
  • [ ] Treat reservation clauses as latent risk, not boilerplate
  • [ ] Audit score-snapshot history before sizing
  • [ ] Avoid trading near platform methodology cycles

Sources + Further Reading

  • SettleRisk methodology — RETROACTIVE_RULE_CHANGE driver detail
  • Webhooks post — rules.changed subscription
  • Driver attribution post — how this combines with other drivers
  • Polymarket dispute archive — retroactive change case studies
  • Rule Stability in Prediction Market Design — Hanson (2007)

Free key at /signup — subscribe to rules.changed from day one.

Get weekly risk analysis in your inbox

Market risk scores, emerging dispute patterns, and settlement delay trends — delivered every Monday.