Fact-Checking Policy
Fact-checking standards
This Fact-Checking Policy explains how Event Trading Hub checks platform facts, fees, limits, dates, market rules, source priority, corrections, and update notes for prediction-market and event-trading content.
Last updated: July 3, 2026
How Facts Are Verified
Fact-checking starts by identifying the exact claim. A claim about a platform fee, a regulatory status, a market outcome, or a tool calculation needs a stronger source trail than a general educational definition.
- Find the claim type. The editor separates factual claims from interpretation, examples, opinion, and risk framing.
- Find the strongest source. Platform and rule claims are checked against official or primary sources before being presented as facts.
- Check the date and context. Many event-trading facts change, so the source date, access date, product scope, and jurisdiction matter.
- Keep uncertainty visible. If a source does not answer the question clearly, the page should say so instead of filling the gap with an assumption.
- Review before publication. Material claims are reviewed before publication or before a major update goes live.
Fees, Limits, Dates, And Platform Rules
Fees, limits, dates, availability, funding methods, settlement rules, and market-resolution criteria are treated as time-sensitive facts. They should not be copied forward from old notes without rechecking the source path.
Platform data checks
- Fees and limits are checked against official fee, help, terms, or product pages where available.
- Availability and eligibility claims are checked against platform terms, official support pages, or regulator context.
- Funding and withdrawal claims are checked against current platform documentation.
Market rule checks
- Market examples should preserve the exact market question and resolution criteria when those details affect interpretation.
- Dates should distinguish publication date, source access date, market close date, resolution date, and page update date where relevant.
- Live or cached data should be labeled so readers know it may change after capture.
Source Priority
The site uses a source hierarchy. Stronger sources are used first, and weaker sources are used only as leads or background context.
Official Platform Sources
Official platform home pages, product pages, help centers, fee pages, terms, market rules, API documentation, and official announcements are preferred for platform-specific claims.
Regulatory And Legal Sources
Regulatory pages, CFTC materials, exchange/entity records, court documents, formal filings, and official enforcement or approval materials are preferred for legal, regulatory, and entity-status context.
Help Centers And Market Pages
Help-center articles and market pages are useful when the claim depends on how a platform explains rules to users, how a market resolves, or how a product currently behaves. These sources still need date and scope context.
Archived Market Data
Archived market pages, cached market snapshots, saved screenshots, and local artifacts can support historical examples when the capture date and source path are clear. They should not be used to claim that a live market, fee, or rule is still current.
Reputable News Sources
Reputable reporting can help explain timelines, disputes, product launches, or regulatory events. News coverage is treated as supporting context unless it is the strongest available source for a specific historical fact.
Search snippets, social posts, forums, unaudited screenshots, and competitor pages can suggest what to check, but they do not verify Event Trading Hub platform facts by themselves.
Tools, Calculators, And Data Pages
Tool pages are checked for calculation logic, labels, units, assumptions, and risk framing. When a calculator uses a simplified model, the page should explain the assumption rather than imply that the result covers every platform fee, tax treatment, or settlement case.
Data pages such as Prediction Market Platforms, Platform Finder, and the Prediction Market Scanner should keep source context visible and avoid turning uncertain data into definitive recommendations.
How To Report An Error
Readers can report a factual error, outdated platform detail, broken source link, unclear disclosure, or confusing risk statement through the Contact page.
A useful correction request includes the page URL, the exact claim in question, the proposed correction, and the strongest available source. Official platform documentation, regulator materials, and primary sources are the most useful.
Correction Timing
Material factual errors are prioritized ahead of new content once the correction is supported by a strong source. Examples include wrong fees, wrong access restrictions, wrong settlement criteria, broken disclosure context, or outdated legal/regulatory framing.
Minor wording, formatting, or clarity issues may be handled during the next editorial pass. If a claim cannot be verified quickly, the page may be updated to mark the issue as unclear, partial, or needing recheck while the source trail is reviewed.
How Updates Are Marked
Updates may be marked through a last-updated date, last-verified language, update notes inside a review, a platform-database source note, or a project checkpoint. The right format depends on the page type and how material the change is for readers.
- Stable explainers may only need a page-level last-updated date after meaningful edits.
- Reviews and comparison pages should identify material changes to fees, rules, access, funding, settlement, or source status.
- Database and tool pages should preserve source or refresh context where the data can change.
- Accepted corrections should change the live page directly, not just the private work log.