Our Prediction-Market Research Methodology

Prediction markets change faster than a conventional product comparison. A contract expires, an API adds a field, a fee schedule takes effect, a program changes tiers, and a government series is revised. Our research method is designed around that reality: preserve what was observed, identify the controlling source, show the limits of the evidence, and correct the record when the evidence changes.

1. Start with a source hierarchy

Not every link plays the same role. We record what a source can establish instead of collecting citations that merely look authoritative. Our default hierarchy is:

1. Controlling contract and primary data: the market's rules, named resolution source, official fee schedule, official API response, exchange notice, regulatory filing, statute, or government dataset.
2. First-party operational documentation: official API guides, support pages, status notices, program terms, release notes, and product announcements.
3. First-party vendor claims: claims about a company's reach, security, performance, customers, or roadmap. We attribute these to the vendor unless independently demonstrated.
4. Independent primary research: papers, datasets, and measurements with enough methods to inspect or reproduce.
5. Secondary reporting and commentary: useful for discovery and context, but not a substitute for the current contract, filing, schedule, or payload.

A source can be authoritative for one fact and irrelevant to another. An exchange fee schedule can establish its published formula; it cannot establish the spread an order would have paid at 14:03 UTC. A company announcement can establish what the company announced; it cannot by itself prove adoption or user outcomes. We prefer the narrow claim the evidence supports.

2. Preserve observation time and publication time

We distinguish when something happened, when we observed it, when its source became effective, and when our article was published. Those dates are often different. Time-sensitive observations use an explicit date and, where intraday movement matters, a timestamp and timezone. Our internal datasets use UTC; public prose may also show the relevant market or agency timezone.

Catalog totals, market status, open interest, volume, bid/ask quotes, fees, product availability, API schemas, program tiers, and geographic eligibility are point-in-time facts. We do not turn “observed on July 23” into “always” or “everywhere.” When pagination can change during collection, we retain the reported total, raw row count, unique identifier count, duplicates, and collection window rather than publishing one context-free number.

3. The title is not the contract

Two pages can ask similar questions without representing the same economic contract. Before treating contracts as comparable, we map:

• venue, distribution surface, and underlying exchange or protocol;
• series, event, market, token, and tradable instrument identifiers;
• yes/no condition, threshold, comparison operator, and unit;
• observation timestamp, timezone, averaging window, and market close;
• resolution source, verification index, rounding, fallback, and dispute rule;
• collateral, settlement path, custody model, and access restrictions.

We keep source identity as data. A crypto contract referencing one benchmark is not automatically fungible with a similarly titled contract using another index. A third-party interface distributing an exchange contract is not automatically a new venue. When equivalence is uncertain, we call it a candidate match and describe the unresolved basis risk.

4. Separate facts, vendor claims, and inference

Our prose should make the evidence class visible. “The documentation says” is a first-party statement. “The public payload returned” is an observation. “This may reduce integration work” is an inference. “This strategy earns” would require much stronger evidence and a defined test. We do not convert roadmap language into a shipped feature, an application into an approval, a leaderboard into a safety audit, or a sandbox order into production performance.

When we make an inference, we state the premises and plausible alternatives. When a claim cannot be independently verified, we attribute it. Anonymous social posts can identify leads to investigate, but they do not become evidence simply because several accounts repeat them.

5. Normalize fees without hiding exceptions

Fee comparisons start with the current official schedule and its effective date. We retain contract count, execution price, maker/taker role, applicable series or category, formula coefficient or multiplier, rounding rule, and fee currency. We calculate the order as the venue specifies and keep spread, slippage, funding, transfer, settlement, and likely exit cost separate from the published transaction fee.

Temporary rebates, rewards, and grants are separate layers—not silent reductions to the base fee. A category rate does not override a market-specific configuration. A general formula does not override a nonstandard series table. An application-level builder fee is additive where the documentation says it is additive. Our Gemini Predictions vs Kalshi comparison applies this principle, the Polymarket Builder Program guide separates platform fees from application charges, and the public calculator exposes the assumptions in executable form.

6. Make calculations reproducible

A quantitative claim should identify the input data, filters, formula, units, rounding, missing-data treatment, and calculation date. For API research, we prefer retaining the response body or a privacy-safe fixture, request parameters, collection timestamp, unique identifiers, and a cryptographic hash when redistribution terms permit. For public datasets, we record series codes, releases, vintages, seasonal adjustment, nominal or real units, and whether the agency can revise history.

We avoid false precision. A chart based on four market cycles remains a four-observation comparison no matter how elegant its trend line looks. A paper result does not automatically survive real spreads, latency, failed fills, revisions, taxes, or a new market regime. Calculation examples teach the method; they are not promises that an order will execute at that price.

7. Respect licenses and sensitive data

Publicly reachable does not mean unrestricted for redistribution. We check the provider's terms, copyright notice, API rules, and rate limits before republishing a dataset or building a downloadable resource. Where raw redistribution is unclear, we publish a source map, method, schema, or small derived example and link readers to the controlling source.

We do not publish private API keys, wallet secrets, account identifiers, non-public user data, or raw payloads that expose them. Security research favors the smallest safe proof. A read-only inventory does not authorize an external application, a funded-wallet test, or a live order.

8. Define experiments before reading the result

An experiment needs a question, owner, input set, baseline, success threshold, failure or kill condition, maximum time and cost, and a next decision. Examples include: “Does a source-map page earn qualified search impressions within 90 days?” or “Does a read-only comparison retain complete contract identity across three venues?” “Publish more content” is activity, not a falsifiable experiment.

Trading research adds training and evaluation windows, leakage controls, fees, spread and slippage assumptions, capital and loss limits, out-of-sample evaluation, and a paper-first gate. We report negative and null results when they change the decision. We do not promote live money merely because a backtest or sandbox test passes.

9. Review, corrections, and revision history

Before publication, a research page receives a source check, claim-to-source pass, calculation check where applicable, link and indexing check, and a review for language that is broader than the evidence. Publication records the date. A material update advances the visible updated date.

We correct a page when a controlling source changed, a calculation was wrong, a quotation or attribution was inaccurate, the text confused different contracts or venues, or a reasonable reader could make a materially different decision because of the error. Material corrections add a dated note explaining what changed. Minor spelling, grammar, formatting, and broken-link fixes can be made without a correction note when they do not change meaning.

We do not silently preserve a known error for the sake of an old screenshot, and we do not erase a material mistake without acknowledging it. If the original evidence remains important, we preserve it in a dated research artifact or repository history while updating the public page readers are likely to find.

10. What readers should expect

Expect dated claims, direct links to controlling sources, explicit uncertainty, and narrower conclusions than promotional content usually offers. Expect comparisons to change when products change. Expect us to say “we do not know” when identity, eligibility, licensing, or cost cannot be established from the available evidence.

If you find a material error, send the page URL, disputed sentence, and strongest available primary source through our contact channel. We will investigate the claim, preserve the evidence, and update the page when warranted. This method is a floor, not a claim of infallibility; its purpose is to make our reasoning inspectable and our mistakes correctable.