13.3 Data Sources (Sources Register)
This appendix is the inventory of major data sources referenced and/or used to compute, verify, or triangulate claims in Terra Classic Four Years After: State of the Chain Report (2022–2026). It mirrors the report’s evidence hierarchy and explicitly includes the “primary corpus” items (dashboards, forums, Telegram logs, independent research), plus the concrete third-party tools and web references used in specific chapters.
How to read this register (so it’s usable by everyone)
Each source below is tagged with:
Type
Measured = quantitative extraction (on-chain dashboards, analytics, Trends/GA, market APIs).
Documented = verifiable public artifacts (governance records, repo history, audits, advisories).
Reported = stakeholder testimony (chat logs, forum posts) used for context and triangulation, never as sole proof.
Use in report (what it supported)
Access form (dashboard, PDF screenshot pack, API, forum archive, etc.)
Key limitations (bias, exportability, refresh cadence, pruning, ambiguity)
C.1 Canonical entrypoints & ecosystem wayfinding (trust surface audit)
Used to define the official-ish trust surface (“what newcomers and partners click first”) and to audit onboarding integrity and profile mismatches.
C.1.1 terra-classic.io — ecosystem hub / curated resource entrypoint
Type: Documented (presentation surface) + Measured (via screenshot evidence packs)
Use: Primary “front door” surface: apps/tools/docs/endpoints wayfinding; onboarding integrity checks.
Limitations: Directory breadth claims can overstate readiness; treated as discovery surface requiring verification via activity metrics.
C.1.2 terra-classic.money — community site + report publication surface
Type: Documented + Measured (GA)
Use: Publication surface + ecosystem mapping + structured wayfinding; also provides distribution metrics via Google Analytics.
Limitations: Site traffic measures distribution, not chain adoption; interpreted cautiously.
C.1.3 classic-docs.terra.money — documentation hub (often mislabeled as “whitepaper”)
Type: Documented
Use: Canonical-ish documentation surface; specifically used for expectation mismatch auditing when third-party profiles label it “whitepaper.”
Limitations: “Docs” ≠ “whitepaper”; mislabeling is an integrity/partner-readiness risk signal.
C.1.4 finder.terra.money — Terra Classic explorer surface
Type: Measured + Documented
Use: Verification workflows: transactions, accounts, contracts, governance objects where visible; cited as a key chain inspection surface.
Limitations: Explorer reliability/indexing lag can create “phantom outages,” and is treated as part of operational maturity.
C.1.5 Additional directory surfaces (comparison / integrity checks)
Used primarily for profile integrity audits and cross-checking canonical routing claims.
terraclassic.featurebase.app (also used for feature/feedback tracking)
Type: Documented (presentation)
Use: Comparison / integrity-check surfaces to detect outdated links, wrong “official” routing, and UX confusion vectors.
Limitations: Not treated as authoritative truth; used to show what users see.
C.2 On-chain data, network endpoints, explorers, and chain observability
Used wherever the report asserts “what is true on-chain” (supply, transactions, validators, governance objects, contract activity) and wherever it diagnoses “effective outages” caused by access-layer failures.
C.2.1 Public endpoints lists (LCD / RPC / gRPC / FCD) via Terra Classic documentation and hub
Type: Documented + Measured (operator mapping)
Use: Public access layer inventory and dependency analysis (endpoint types, operator redundancy, “no SLA / light workloads” positioning).
Observed operators referenced in the report corpus: PublicNode, BiNodes, Hexxagon, LuncBlaze.
Limitations: Public endpoints can be rate-limited, lack SLA, and create concentration risk even if the validator set is decentralized.
C.2.2 finder.terra.money (explorer)
(see C.1.4) — also used as a primary verification surface.
C.2.3 validator.info — validator set / staking/APR / chain status snapshots
Type: Measured (snapshot + statements surfaced)
Use: Decentralization and concentration statements used in Chapter 5 exhibits (e.g., top-4 stake concentration callouts), validator overview context.
Limitations: Treated as a supporting “truth surface”; concentration/clustering still requires careful attribution rules.
C.2.4 StakeBin and other validator-related dashboards (secondary unless cross-validated)
Type: Measured (snapshot)
Use: Block time snapshot (~6s) and decentralization visuals (e.g., Nakamoto index chart screenshot in report exhibits).
Limitations: Snapshot evidence is not a multi-year exported dataset; report explicitly calls out historical reproducibility constraints due to pruning/export limits.
C.3 Governance records and governance-discussion archives
Used for “what the chain decided” (proposal objects, votes, tallies) and the human debate layer (warnings, incident reports, scam-proposal waves).
C.3.1 classic-agora.terra.money (Commonwealth / Agora)
Type: Documented (public posts) + Reported (testimony layer)
Use: Proposal debates, incident warnings, scam-proposal wave documentation, governance discourse context.
Limitations: Forums are not chain truth; used to locate issues and timestamp discourse, then verified via Measured/Documented sources.
C.3.2 On-chain governance objects via wallets/explorers
Type: Documented (on-chain artifacts)
Use: Proposal text, deposits, voting records, metadata (primary whenever directly pulled from chain displays or explorer mirrors).
Limitations: “Proposal passed” ≠ “implemented”; execution must be verified via releases/transactions/observable state change.
C.3.3 Feature request / feedback tracking surfaces
terraclassic.featurebase.app
Type: Documented
Use: UX/onboarding context and product feedback visibility checks (where referenced).
Limitations: Feedback presence doesn’t imply delivery.
C.3.4 Additional governance discussion archives declared in the corpus
Classic Agora, Common.xyz, New Agora (full history/archives)
Type: Documented + Reported
Use: Chronology confirmation, provenance tracking of debates and claims.
Limitations: Selection bias and loud-minority effects explicitly controlled for in the methodology.
C.4 Engineering delivery and developer-activity evidence
Used to ground “what shipped,” “who shipped it,” and whether activity is maintenance vs net-new delivery.
C.4.1 GitHub (github.com) — repos, commits, releases
Type: Documented + Measured (counts/velocity where extracted)
Use: Release cadence, patches, merge evidence, repository authority/control-point analysis.
Limitations: Repo activity is gameable and fragmentable; report treats commit counts as supporting indicators, not definitive proof of productivity.
C.4.2 Developer coordination channels (qualitative; see C.7.1)
Type: Reported
Use: Constraints, coordination norms, incentive friction—never treated as authoritative technical truth unless linked to code or on-chain actions.
C.5 Market structure and off-chain activity (price, volume, exchange metadata)
Used to quantify attention cycles, venue concentration, and off-chain distribution surfaces that matter in Terra Classic’s current demand regime.
C.5.1 CoinMarketCap
Type: Measured + Documented
Use: Market snapshots; “official links” integrity audits (wrong/outdated socials, misclassified docs/whitepaper links).
Limitations: Attention/market data ≠ on-chain adoption; official-links section can be wrong or stale.
C.5.2 CoinGecko
Type: Measured + Documented
Use: Market snapshots + profile integrity audits similar to CMC; also a volume feed underpinning the Truth Dashboard’s volume chart.
Limitations: Exchange-reported volume noise; interpret as off-chain activity indicator only.
C.5.3 Binance — asset pages + metadata + Binance Square
Type: Documented + Reported (posts)
Use: Distribution surface analysis; high-signal misinformation/phishing incident evidence captured from Binance Square.
Limitations: Social-post evidence is treated as incident surface proof, not chain truth.
C.5.4 Other CEX surfaces appearing in the corpus (venue context)
KuCoin
Bybit
MEXC
Type: Documented (listings/status pages) + Measured (market metadata where captured)
Use: “Where users actually trade” context; venue concentration / access risk narratives when supported by evidence pack.
Limitations: Exchange behavior must be supported by primary announcements/status where possible; otherwise labeled Reported.
C.5.5 Vyntrex DEX volume chart snapshot (monthly, Feb 2026)
Type: Measured (screenshot evidence)
Use: DEX throughput and venue breakdown evidence supporting “thin on-chain DeFi footprint” claims.
Limitations: Snapshot-only unless repeated captures or exportable indexer exists.
C.6 Analytics dashboards and derived datasets
Used to consolidate indicators and keep cross-chapter definitions consistent.
C.6.1 Truth Dashboard — “Terra Classic Data & Governance Research (2022–2026)”
Type: Measured + Documented (where it embeds primary artifacts)
Use: KPI backbone (time series, cross-chapter consolidation, evidence-pack exports).
Limitations: Only decision-grade when definitions and reproducibility steps are explicit (metric dictionary governs).
C.6.2 luncmetrics.com — LUNC Metrics
Type: Measured
Use: Supporting analytics for supply/burn/community-relevant tracking, cross-checked where possible.
Limitations: Treated as a secondary analytics surface unless raw computation/export is clear.
C.6.3 Monthly Active Wallets (MAW) dashboard
Type: Measured
Use: Primary adoption trend metric.
Limitations: Wallet != user; susceptible to botting/sybil patterns; used with retention and tx-mix controls.
C.6.4 Governance participation / Community Pool / Validator dashboards
Type: Measured
Use: Treasury, governance legitimacy, validator health/economics context as declared in the corpus.
C.6.5 Google Trends
Type: Measured
Use: Search attention proxy (indexed 0–100), explicitly labeled as attention not adoption.
C.6.6 Google Analytics for terra-classic.money
Type: Measured
Use: Acquisition mix / distribution channel decomposition (GA-AcqMix KPI).
Limitations: Distribution proxy only; sensitive to “dark social” and campaign behavior.
C.7 Community and social channels (distribution, narrative, incident surface)
Used primarily for: (1) narrative prevalence, (2) misinformation/phishing sampling, (3) onboarding-path reality checks, (4) evidence of reputation debt and impersonation pressure.
C.7.1 Telegram (group histories / exports)
Type: Reported
Use: Coordination + qualitative signal; explicitly includes “L1 Devs & Validators,” “LUNC Validators,” “Terra Classic Founders” groups in the declared corpus.
Limitations: High bias/selection effects; used to identify issues and stakeholder experience, not to prove measurable facts.
C.7.2 X (x.com)
Type: Reported + Documented (screenshots with timestamps where archived)
Use: Narrative prevalence sampling, impersonation cases, bounded incident evidence (archived screenshots).
Limitations: Highly gameable; always bounded to specific windows + archived proof.
C.7.3 Reddit
Type: Reported
Use: Incident corroboration (user reports), sentiment snapshots, newcomer confusion patterns.
Limitations: Anecdotal and selection-biased; used for triangulation.
C.7.4 YouTube
Type: Reported
Use: Narrative amplification and onboarding content sampling; treated as secondary unless it cites primary artifacts.
C.7.5 Discord servers (where referenced in corpus)
Type: Reported
Use: Onboarding and coordination flow evidence when the corpus references specific servers.
C.7.6 Binance Square
(also listed in C.5.3)
Type: Reported + Documented (screenshots)
Use: High-signal misinformation and phishing/hoax incident surface evidence.
C.8 Media, research outlets, and third-party commentary
Used for context, chronology confirmation, and “how Terra Classic is framed externally”—never as sole basis for an on-chain claim.
C.8.1 Crypto/markets journalism (chronology + external framing)
CoinDesk
Cointelegraph
The Block
Decrypt
Type: Documented (published reporting)
Use: External framing and timeline corroboration when needed.
Limitations: Not used as primary evidence for on-chain facts.
C.8.2 Commentary/education outlets (external “zombie chain” narrative evidence)
The Defiant
CCN
Type: Documented
Use: Document how Terra Classic is described externally (reputation/brand ceiling context).
Limitations: Narrative evidence only; not chain truth.
C.8.3 Security awareness pages for scam pattern mechanics (risk evidence)
PCRisk (pcrisk.com)
Type: Documented
Use: Phishing mechanics and wallet pop-up/clone scam pattern evidence as part of onboarding integrity risk analysis.
Limitations: Used as attack-pattern evidence, not as protocol facts.
C.9 Evidence packs and internal working corpus (production artifacts)
These are not “public sources,” but they are part of the report’s evidence chain because they contain curated excerpts, screenshots, structured audits, and bounded sampling windows used in final writing.
C.9.1 Primary-source excerpt pack — “Work-for-Free pressure” & builder funding backlash (2022–2026)
Type: Mixed (Documented excerpts + Reported testimony)
Use: Incentive-alignment claims in Chapter 7.
C.9.2 “Onboarding audit — Terra Classic” structured audit
Type: Mixed (Documented surfaces + Measured checks where applicable)
Use: End-to-end onboarding path integrity: canonical vs dangerous entrypoints; UX meets reputation/trust surface.
C.9.3 Web research report (gap-filling compilation)
Type: Mixed
Use: Filling defined gaps (misinformation incidents, profile integrity proof pack, narrative sampling windows).
C.9.4 Screenshot packs (proof of presentation)
Type: Documented (what users see)
Use: Captured from key surfaces (terra-classic.io, exchange pages, CoinMarketCap/CoinGecko link sections, docs, etc.) to evidence routing reality.
C.10 Untrusted / adversarial domains and scam artifacts (archived as risk evidence)
A portion of the research corpus includes malicious/spoofed domains and scam content. These are included only as evidence of attack surface, onboarding integrity failures, and reputation debt—never as factual sources about the chain.
Type: Documented (archived artifacts/screenshots) + Reported (victim/user reports)
Use: Demonstrate existence, frequency, and vectors of attacks (lookalike wallet sites, pop-up credential theft, spoof “station” variants, scam proposal links).
Limitations: Not trusted; handled as adversarial evidence only.