Arguments for not updating Terra Classic (LUNC & USTC) “website” link to terra-classic.io
1) Critical flaws
1.1 Centralization of power at ecosystem-critical level / Single point of failure risk
StrathCole, the creator and domain owner of terra-classic.io (domain custody = ultimate control over the destination), is simultaneously positioned across multiple high-impact infrastructure surfaces within Terra Classic.
Based on publicly observable roles and repos, StrathCole is:
- One of ~2–3 individuals with effective control over the official Terra Classic GitHub (core chain code governance surface).
- Operating and controlling the Astroport Classic interface deployment at http://astro.terra-classic.io (domain/subdomain + deployment). The code deployed is in his repositories under his GitHub.
- A key contributor to Market Module 2.0 code that is planned for Terra Classic implementation.
- Connected to other ecosystem tooling (e.g., luncdash / related infrastructure) where maintenance and operational access materially affect user experience and information routing.
Even if all parties act in good faith, stacking multiple critical “control planes” (core code + canonical link destination + major tooling) under one operator materially increases systemic risk and sets a precedent that contradicts the stated goal of reducing single points of failure.
Transparency request (for voter risk assessment):
@StrathCole - for transparency and risk management (single-point-of-failure and incentive alignment), can you disclose any other Terra Classic roles or assets you control that materially intersect with routing users/partners via the canonical link (e.g., major infra/tools, endpoints, aggregators), so voters can evaluate concentration risk?
Additionally, the current visible “contributors/maintainers” set for terra-classic.io appears to include multiple validators and project operators. If those contributors are also effectively the maintainers/reviewers (merge rights), that introduces direct incentive alignment and conflict-of-interest risk: the canonical link can influence traffic, reputation, delegations, and downstream revenue.
2) Important omissions
2.1 Failure to adhere to governance rules and etiquette
Two governance-process issues are material:
- Material revision mid-thread: The proposal’s core rationale and framing were substantially rewritten after the discussion had already started, and then moved to deposit/voting shortly after. This undermines voter clarity because participants were reacting to one version during discussion, while the vote proceeds on a different version.
- Discussion window: The proposal moved to deposit/voting roughly 3 days after introduction, despite the widely understood governance norm/expectation that proposals should have ~1 week minimum discussionbefore voting to allow review, rebuttals, and disclosures.
- Proposer voting: Hexxagon/affiliates voting “Yes” on their own proposal is not inherently forbidden, but it does raise governance-hygiene concerns when combined with a shortened discussion period and unresolved disclosure questions. In practice, it reinforces the perception that this process is being rushed rather than consensus-built.
Governance should be especially careful when the decision affects a canonical ecosystem “front door” that many third parties mirror.
2.2 Attempting to construct a misleading narrative (“banner controversy”)
The rationale has been heavily anchored to a narrative that an informational banner linking to a forum fundraising discussion is inherently improper or “non-neutral.”
Key clarifications for voters:
- A banner that says “v2 in development—read the Agora discussion; support is appreciated” is not inherently a governance breach. It is standard practice across open ecosystems and public goods.
- Bitcoin.org (the most recognized and arguably most decentralized crypto ecosystem) runs a prominent banner stating the site is community funded and that donations are appreciated. This is widely accepted as normal public-goods funding behavior, not “grifting” or misconduct.
- Therefore, the “banner = disqualification” logic is not a neutral governance standard. It is a subjective preference held by a small subset of participants, amplified into a governance rationale.
If governance wants standards for canonical destinations, those standards should be operational and symmetric(custody, maintainers, approval policy, incident response), not based on selective optics narratives.
2.3 Distortions regarding decentralization and governance of terra-classic.io
A GitHub PR flow enables contribution proposals; it does not automatically create decentralization.
What matters for decentralization is:
- who has merge rights,
- how many approvals are required,
- how maintainers are appointed/removed,
- who controls the domain and hosting credentials,
- what happens in disputes/incidents.
At present, terra-classic.io is still structurally centralized:
- Domain custody is held by a single operator (StrathCole), meaning ultimate control remains unilateral at the DNS/hosting level.
- The effective maintainer set appears small (5 people) and includes parties with direct economic incentives (validators/service providers), creating an incentive concentration problem rather than eliminating it.
Calling this “community-owned” without a formalized governance model is, at best, an overstatement.
2.4 Proposal lacks minimum information required for an informed vote
For a canonical destination change, voters need a minimum operating specification. The proposal still does not clearly and explicitly publish, in a voter-visible place:
- Custody & control (domain registrar, hosting, credentials)
- Maintainer/reviewer list + merge rights
- Approval thresholds and policy
- Maintainer add/remove process
- Incident response & dispute resolution
- Migration/comms plan for third parties and users
- Conflict-of-interest disclosure (validator operations and related infra roles)
Absent these, the vote is not evaluating a governance model; it is evaluating assertions.
3) Arguments of slightly less significance
3.1 User impact and communication chaos across third-party platforms
Changing the canonical link again is not a clean “flip.” It creates months of inconsistent user experience across:
- exchanges,
- aggregators,
- market data sites,
- wallets,
- press references,
- SEO and backlink structure.
Even after a vote passes, third parties update asynchronously. Users will encounter contradictory “official website” links across the internet for an extended period, which is reputationally costly for a chain that already carries post-2022 trust damage.
3.2 Step backward in UX and brand strategy relative to what Terra Classic needs
This is not merely “design preference.” The canonical destination is an onboarding and credibility surface.
Terra Classic is still rebuilding reputation and needs a front door that can compete with top L1 ecosystems on:
- narrative clarity,
- onboarding paths for investors/stakers/builders/institutions,
- conversion-oriented information architecture,
- consistent brand credibility.
terra-classic.io may be functional as a resource hub, but it does not materially move Terra Classic toward an institution-grade onboarding experience. Meanwhile, terra-classic.money v2 is explicitly being designed to address those shortcomings (multilingual structure, integrated docs UX, guided journeys, stronger narrative/credibility).
Replacing the canonical link with a destination that is not designed to address reputation and onboarding as a first-class goal is a strategic downgrade.
