Terra Classic does not fail because “the market is unfair” or because “people don’t understand the story.” It fails when investors and builders cannot verify who controls critical surfaces, whether decisions execute, and whether safety claims are evidence-grade.

Chapter 12 is investor-facing. That means validators do not get credit for intention, effort, or narrative. They only get credit for proof.

The governance data already shows why: delegator voting wallets are only ~0.24% of active wallets, meaning governance is practically validator-led. Even inside the validator layer, the observed window shows ~39.99% “votes not voted,” and “never voters” controlling ~13.38% of voting power (in the “last year” dashboard snapshot). That is not a moral judgment—it’s a measurement: responsibility concentrates, so proof requirements must tighten.

This article defines the minimum evidence pack validators must publish (or enable) for Terra Classic to be investable on a serious basis.

12.3.1 Evidence standard: “claim → artifact → verifier → timestamp”

Anything that cannot be independently verified is not evidence. It is commentary.

For Terra Classic, credibility requires a consistent structure:

• Claim (what is being asserted)

• Artifact (what exists that proves it)

• Verifier (who can independently confirm it without special access)

• Timestamp (when this proof was last current)

• Changelog (what changed since last proof)

This is not bureaucracy. It is the difference between:

• a chain that can onboard capital, builders, and exchanges, versus

• a chain that survives on attention spikes and internal consensus.

The report already acknowledges the need to harden governance and operational claims with time-series exports, repo governance snapshots, and a control-plane redundancy table (domains, key endpoints, key UIs—who operates them, with evidence). That is exactly the direction. This chapter makes it explicit and investor-grade.

12.3.2 Proof Pack #1 — Dated Control-Plane Registry (single page + changelog)

Purpose: Investors need to know who effectively “holds the keys” to Terra Classic’s public-facing and operational surfaces. If those surfaces are fragmented, informal, or undocumented, the chain becomes unpriceable as an operational system.

What must exist (minimum):

A single canonical page titled like:

Terra Classic Control-Plane Registry (Dated)

With a table that includes, at minimum:

1. Domains / Wayfinding

• Primary public gateway domains (e.g., community website, docs)

• DNS custody / registrar (redacted contact is fine; custody proof is not)

• Admin policy (who can change it, what is the recovery process)

• Changelog (domain changes are high-risk events)

2. Public endpoints

• RPC / REST endpoints used by wallets, explorers, dashboards

• Operators (who runs them, what SLA exists, what redundancy exists)

• Known failure modes (rate limits, outages, region blocks)

• Evidence: uptime dashboard links, endpoint list, last validation timestamp

3. Critical UIs

• Governance UI(s), validator dashboards, major public explorers

• Who operates, who maintains, who can ship changes

• Release logs

4. Indexers and telemetry

• Which indexer produces key public stats (governance, validators, activity)

• Whether exports exist (CSV/JSON)

• Snapshot cadence and retention policy

Why this is mandatory now: the report itself flags the need for a “control-plane redundancy table (domains, key endpoints, key UIs—who operates them, with evidence).” Until this exists, every infrastructure claim is soft.

Investor interpretation if absent:

No registry = unknown control = operational discount = higher delisting/maintenance probability in practice (because exchanges and integrators cannot reliably coordinate or verify authoritative sources).

12.3.3 Proof Pack #2 — Mandate reality: publish the “Authority Gap Statement”

Operating reality: there is no explicit Terra Classic governance mandate that authorizes any person/group to speak or act for upgrades, exchange coordination, or representation—except the implicit “execute the work you were funded/approved to do” logic around specific L1 upgrade proposals.

This is not a small footnote. It is the core reason coordination keeps collapsing into informal power.

Therefore, validators must publish one of two things (pick one):

Option 1 — A formal “Role & Mandate Charter” (best case)

• On-chain ratified scope: who is authorized to coordinate what (upgrade comms, exchange outreach, incident comms, etc.)

• Named roles, term limits, removal mechanism

• Disclosure obligations

• Conflict policy (esp. multi-validator operator groups)

• Reporting cadence

Option 2 — An explicit “Authority Gap Statement” (minimum acceptable)

If validators refuse to formalize authority, they must publish a blunt statement:

• “No one is authorized to speak for Terra Classic.”

• “All coordination is best-effort and non-binding.”

• “Exchanges and integrators should rely on X, Y, Z sources only.”

• “Upgrade announcements are valid only when published on [defined surfaces].”

• “If these sources conflict, treat the system as degraded.”

Why this is proof, not politics: investors price the risk of coordination failure. If validators won’t formalize authority, they must at least document the absence so counterparties can build safer operational assumptions.

12.3.4 Proof Pack #3 — Governance-to-execution evidence (the missing bridge)

Governance votes are not outcomes. They are inputs to outcomes.

The evidence problem is visible in the governance participation data:

• Avg wallets voting per proposal: ~279, and voter wallets are ~0.24% of active wallets.

• Validators “did not vote” share in the window: ~39.99%.

• A measurable cohort participates consistently, but there is also a large tail of non-participation.

This reality makes execution proof even more important, because legitimacy comes from delivery, not turnout.

What validators must publish (or enable):

1. Execution Register (per funded/approved initiative)
   For every initiative that touches chain state, treasury, or official surfaces:

• Proposal ID(s)

• Scope summary (deliverables, boundaries)

• Responsible operator(s)

• Start date, expected completion date

• Delivery artifacts (PRs, releases, endpoints, dashboards)

• Acceptance criteria (how completion is determined)

• Post-delivery audit note (what changed, what risks remain)

2. Time-series KPIs export
   The report already calls out the need for time series exports (e.g., Nakamoto Index export, not screenshots).
   The Truth Dashboard approach demonstrates this “exportable, windowed telemetry” style by deriving governance participation metrics and explicitly labeling time windows and sources.

Minimum export requirement:

• governance participation (validator + delegator)

• proposal throughput (counts by type/outcome)

• execution lag metrics (vote end → delivery start → delivery completion)

• change failure rate (rollback/incident after change)

Investor interpretation if absent:

No execution register + no KPI exports = governance is narrative, not a control system.

12.3.5 Proof Pack #4 — Security posture proof (binary, evidence-grade)

We have already locked the key fact for this report: Terra Classic has no post-2022 audits or bounty programs. Treating that as confirmed is not “harsh”—it is simply an evidence state.

So the proof requirement is not “tell us you’re safe.” It is:

Publish the Security Assurance Delta statement:

• “No post-2022 audit”

• “No active bounty”

• “Therefore: risk is managed by X (code review discipline / upstream patching / dependency monitoring / test coverage / release process)”

And then, crucially:

Publish the process evidence that compensates for the missing external assurance:

• Release security checklist (per upgrade)

• Dependency advisory monitoring approach

• Emergency response plan (incident owner + comms surfaces)

• Upgrade testnet validation protocol

• Post-upgrade verification checklist (including exchange coordination steps)

Investor interpretation if absent:

No audit + no bounty + no compensating process evidence = security risk is unknown, and unknown risk is always priced as high.

12.3.6 Proof Pack #5 — Exchange surface coordination: the “maintenance truth table”

Even if market access risk is “low” most days, exchanges care about operational trust:

• Are deposits/withdrawals stable?

• Are upgrades communicated with lead time?

• Are there authoritative sources?

Validators must publish (or enable) a minimal operational artifact:

Terra Classic Exchange Maintenance Truth Table

• Chain upgrade schedule (planned)

• Required action by exchanges (if any)

• Known maintenance incidents (date/time, exchange, resolution time)

• Canonical links to upgrade instructions

• Named “exchange coordination point” or explicit disclaimer that none exists (see Authority Gap)

This converts exchange risk from rumor into a dated, auditable log.

12.3.7 Proof Pack #6 — Contributor accountability: repo governance snapshot + bus factor

The report calls out the need for a repo governance snapshot (maintainers/merge rights; bus factor).

This is not optional for investor confidence.

Validators must publish:

• Which repositories matter for L1 maintenance

• Who has merge rights

• Review rules (2-of-N, required checks, etc.)

• Bus factor narrative (what happens if key maintainer disappears)

• Changelog of governance changes (new maintainer, removed maintainer)

Investor interpretation if absent:

No repo governance snapshot = unknown upgrade risk + unknown continuity risk.

12.3.8 Proof Pack #7 — Delegation reality: disclose operator groups and concentration

The Truth Dashboard shows significant governance non-participation and concentration patterns.

The report also discusses clustering / multi-validator operator behavior as a decentralization risk multiplier and recommends transparency and labeling as the pragmatic minimum.

Therefore validators must enable:

• Operator-group disclosure norm

• Dashboard tags for known operator groups (where publicly known)

• “Unique operator set” guidance for delegators (so delegators can diversify operators, not just validator names)

This is not ideology. It is basic risk disclosure.

12.3.9 Proof Pack #8 — Metrics export endpoints: investors must be able to re-run claims

A report is only as strong as its reproducibility.

The Truth Dashboard concept explicitly anchors metrics to a source and time window (“derived from validator.info indexer API (offline snapshot)”). That approach must be generalized:

Validators must ensure:

• All critical metrics can be exported (CSV/JSON)

• Endpoints are stable and documented

• “What the metric means” is defined (to prevent metric theatre)

• Time windows are explicit and consistent

• Snapshots are archived (so claims remain verifiable later)

If a metric cannot be exported, it must be labeled as non-verifiable and treated as informational only.

12.3.10 The bottom line: proof is the product

Terra Classic cannot “market” its way out of an evidence deficit.

Right now, the measurable governance participation data implies a system where responsibility and effective power concentrate (delegators are mostly absent; validator participation is structurally incomplete). In that world, the only path to credibility is proof-grade operations:

• Who controls key surfaces (registry)

• Who is authorized (or explicit statement that no one is)

• How governance turns into execution (register + KPIs)

• How security is handled absent audits/bounties (process evidence)

• How exchanges can coordinate safely (truth table)

• Who can merge code and what the continuity risk is (repo snapshot)

• What is actually measurable and reproducible (export endpoints)

If validators publish (or enable) this proof pack, Terra Classic becomes auditable. And once it is auditable, it becomes investable.

If they do not, the chain remains in the category investors reserve for:

“high narrative, low verifiability” — which is another way of saying: priced as fragile