PriceDepth Valuation Methodology

1. Purpose and Scope

PriceDepth produces FMV estimates for graded collectible cards (PSA, BGS, CGC, SGC graded) and sealed products (booster boxes, sealed sets). These estimates are used for:

• Institutional portfolio valuation (mark-to-market, LP reporting)
• Collateral valuation for lending and structured products
• Reserve pricing for auction houses and marketplaces
• Settlement prices for prediction markets and derivatives
• Daily NAV calculation for collectible-focused funds

This document covers the full valuation pipeline: data ingestion, source hierarchy, price calculation, confidence scoring, liquidity tiering, and the staleness policy. All concepts referenced in API responses are defined here.

2. Data Sources and Source Hierarchy

PriceDepth aggregates completed sales from multiple sources. Sources are weighted by data quality, verification level, and institutional recognition.

2.1 Source Tiers

The full per-source roster, weighting matrix, and ingestion cadence are shared under NDA with institutional customers. Contact [email protected].

2.2 Source Selection

All available sources are included in price calculation without per-source exclusion unless:

• A source returns structurally invalid price data (e.g., lot title mismatch, non-graded item)
• An admin override is active (override becomes the price anchor; market sources inform the range)

The sources array in every API response lists which sources contributed to that price calculation.

2.3 Outlier Treatment

Sales that fall outside the rolling distribution for a given card are excluded from the calculation window. Filters target shill bids, wash trades, and obvious mislabeled listings. Specific filter thresholds and detection logic are part of PriceDepth’s proprietary methodology and are not published; institutional customers can request a methodology brief under NDA.

3. Price Calculation

3.1 Primary Window (30-Day)

For each card, PriceDepth collects all verified completed sales within the prior 30 calendar days. The fair market value is calculated as the median sale price of all sales in that window, across all contributing sources.

Why median? The median is more robust to outliers than the mean. A single anomalous sale (shill bid, distressed seller, auction lot mismatch) does not materially shift the median in a set of 5+ sales. In thin markets (1–4 sales), the median equals the single sale price or the midpoint of two sales.

3.2 Fallback Windows

If fewer than 1 sale is found in the 30-day window, PriceDepth widens the search:

The price_window field in API responses indicates which window was used. The data_staleness_days field reports the age of the oldest sale included in the calculation.

3.3 Fair Value Range (P25/P75)

In addition to the FMV midpoint (price_usd), PriceDepth returns a fair value range:

• price_range.low — 25th percentile of sales in the calculation window
• price_range.high — 75th percentile of sales in the calculation window

In thin-market windows the range collapses toward the midpoint (P25 = P75 = median when only a single sale is observed). The range should be interpreted as an indicative spread, not a precise bid/ask.

3.4 Population Adjustment

PriceDepth does not population-adjust the FMV price in v1.0.0. PSA 10 population data from PSA's published reports is included alongside pricing for market cap calculation and as context for lenders (higher-pop cards carry greater liquidity risk). Population-adjusted pricing curves are planned for v1.1.0.

4. Confidence Score

Every price response includes a 5-level confidence score reflecting underlying data quality. The score is a function of recent sale volume and source diversity within the calculation window.

The exact volume and source-diversity thresholds that map to each score are part of PriceDepth’s proprietary calibration and are reviewed each methodology version.

Confidence score is a data quality indicator, not a price accuracy guarantee. A confidence: 5 price reflects deeper, more diverse observations; a confidence: 1 or 2 price should be treated as an indicative estimate for thin markets.

5. Liquidity Tier

The liquidity field rates the ease of liquidation based on observed market activity.

Volume bands defining each tier are part of the proprietary calibration and may be re-tuned per methodology version.

Liquidity tier informs expected time-to-exit and bid-ask spread estimates. Cards at tier 4–5 may require extended marketing periods (30–180+ days) to achieve the quoted FMV. This is not reflected in the price itself but should inform lending LTV ratios and fund liquidity policies.

6. Admin Override

For cards where market data is absent or structurally inadequate, a PriceDepth analyst may set an admin override price. Overrides are:

• Sourced from verifiable comp references (auction lot numbers, dealer floor prices, show sales)
• Documented with a source_description field (e.g., "Auction lot reference, Feb 2026, PSA 10 hammer $18,500")
• Marked is_override: true in all API responses
• Set with an optional expires_at date; expired overrides revert to market data
• Visible in the override_note field of any price response

Admin overrides carry a confidence score of 2 (low) regardless of the quality of the underlying comp. Lenders and funds should require analyst sign-off before accepting override-priced collateral in binding valuations.

7. Staleness Policy

data_staleness_days in API responses reports the number of days since the oldest sale used in the current calculation. This differs from price_window (which is a categorical label):

For daily NAV calculation and audit trail purposes, PriceDepth records a daily FMV snapshot in the daily_prices table at midnight UTC. Historical snapshots can be retrieved via GET /v1/cards/:id/price?date=YYYY-MM-DD.

8. Grade Normalization Planned v1.1.0

In v1.0.0, PriceDepth treats each grader-grade combination as distinct. A PSA 10 and a BGS 10 for the same card are not interchangeable in price calculation.

v1.1.0 will introduce cross-grader equivalency curves for thinly-traded grades:

• PSA 9 ≈ BGS 8.5 ≈ CGC 9 (indicative; card-specific curves will vary)
• BGS 10 (Black Label) treated separately from BGS 9.5
• Grade normalization applied only when primary grade has < 2 comps in 90 days

Until grade normalization is live, all prices reflect the specific grader-grade combination of the queried card.

9. Methodology Version History

Future versions will be documented here. The methodology_version field in all API responses corresponds to the version under which that price was calculated. Historical daily_prices snapshots include the methodology version used at calculation time for full audit reproducibility.

10. Limitations and Known Gaps

PriceDepth does not guarantee that prices reflect what any specific card would achieve in a negotiated sale. Market prices for graded collectibles can move rapidly in response to IP events, athlete news, and population report releases. All valuations should be treated as estimates for a fair market transaction between willing parties.

11. Contact and Methodology Questions

For questions about this methodology document, valuation disputes, or to request a custom coverage assessment:

• Email: [email protected]
• API documentation: See README.md or /docs/api/
• To report a suspected data error: POST /v1/feedback (planned endpoint)

12. Index Methodology

PriceDepth publishes two signed price indexes. Each index is computed nightly at 02:00 UTC, signed with an ECDSA key on the secp256k1 curve (same as Ethereum), and published via the REST API. Off-chain signed feeds — consumers pull the signed payload independently.

12.1 Overview

12.2 Signature Verification

Every index snapshot returned by the API includes a cryptographic signature. This allows oracle consumers to verify that the payload was produced by PriceDepth and has not been tampered with.

• Algorithm: ECDSA on the secp256k1 curve (same curve as Ethereum / Bitcoin).
• Public key URL: https://pricedepth.com/.well-known/pricedepth-oracle.pub (PEM format).
• Signature format: Base64-encoded DER.

Canonical JSON Shape

The signature covers a deterministic JSON string. The exact canonical form is:

• Exactly four fields, sorted by key in ASCII order: as_of_timestamp, methodology_version, slug, value.
• No extra whitespace (whitespace-stripped).
• UTF-8 encoded.
• Example: {"as_of_timestamp":"2026-04-11T02:00:00Z","methodology_version":"v1.0.0","slug":"pdi-pokemon","value":1234.56}

For full code examples (Node.js + Python) see docs.html#indexes.

12.3 Methodology Versioning

• Current version: v1.0.0
• Any change to inclusion rules, weighting, or rebalance cadence increments the version (semver).
• Historical rows retain the methodology_version in effect at computation time.
• No retroactive recomputation — history is immutable once signed.
• Version changes are announced via the API changelog and this document.

12.4 Known Limitations (v1.0.0)

• Daily cadence only — intraday streaming is a later phase.
• No custom user-defined indexes — custom baskets are a later phase.
• Key rotation is manual — automated key rotation is a later phase. Current key is at .well-known/pricedepth-oracle.pub.