STATUS AND PURPOSE
This is a discussion draft for the Terra Classic community to examine, challenge and improve before any on-chain submission. It proposes a mandatory validator identity and control standard as the intended end state, reached through a funded, legally reviewed and technically tested implementation. It does not claim that this forum post creates an enforceable protocol restriction.
The objective is to make validator responsibility verifiable, identify undisclosed common control, and give delegators better information about who secures the chain and exercises governance influence.
All validators, including the proposer, would be subject to the same requirements. Validator size, commission, reputation, political alignment, exchange affiliation and governance voting history would not create exemptions.
The final intended programme includes community-pool-funded bulk verification and an enforceable active-set eligibility requirement. No funds, removals or software changes are authorised merely by this discussion draft.
1. WHY THIS DISCUSSION IS NEEDED
LUNC governance should reward evidence, accountability and independent decision-making. Delegators should be able to verify that a validator has a responsible operator and understand when several validator brands are controlled by the same people.
False accusations, impersonation, misleading claims of independence and unsupported narratives can damage confidence. However, identity verification cannot establish whether every public statement is true or whether a verified person is honest. Claims of misconduct must still be assessed against evidence.
The proposal therefore addresses two specific gaps:
-
Identity accountability: a qualified independent verifier privately confirms the responsible person or entity and binds the result to the validator operator address.
-
Control accountability: operators disclose the people and entities that ultimately own, direct or materially control their validator operation, including other validator identities under the same control.
This must be accompanied by strong privacy, appeal and decentralisation protections. It must not become a means of punishing criticism or removing validators because of unpopular votes.
2. RELEVANT LUNC HISTORY
Proposal 12033, “Compulsory KYC for all L1 developers,” is shown as passed by the governance explorer. That is developer history, not evidence of an existing validator KYC requirement. [1]
Proposal 12058, “Add Certik as a recognized KYC provider,” is also shown as passed. [2]
Proposal 12129, “Integrated Ruleset for Secure and Inclusive Terra Classic L1 Development,” is shown as passed. Its repository text keeps contribution and review open while restricting direct commits and governing merge/release access; it identifies CertiK and SolidProof as recognised providers in that developer process. This draft would establish a separate validator standard rather than assuming that developer approval automatically qualifies either vendor for every validator requirement. [3][4]
Proposal 12101, “Rules to prevent double & network validating,” is shown as rejected. The explorer records 37.57% Yes, 37.10% No, 20.86% NoWithVeto and 4.47% Abstain, with the approval threshold not reached. A new proposal must address feasibility and scope rather than describe the rejected proposal as an existing prohibition. [5]
A December 2025 validator KYC forum discussion raised the enforcement problem directly. This draft acknowledges that objection and distinguishes an information registry from a change to validator eligibility. [6]
3. WHAT IS BEING PROPOSED
The intended standard is:
“Every active Terra Classic validator must maintain a current independent private identity verification, prove control of its operator account through an approved safe procedure, and disclose its ultimate ownership and control structure. No independent controller or common-control group may maintain more than one active validator identity on the Terra Classic mainnet after the approved transition.”
During an initial pilot, participation is voluntary and does not change chain eligibility. The final rollout is proposed to cover the entire active set together, funded from the community pool through a negotiated bulk contract. A mandatory rule would require a later, explicit implementation proposal approving its scope, cost, administration, code and activation conditions. Supporting this discussion must not be represented as authorising an unspecified upgrade.
The community should decide whether KYC and the one-active-validator restriction should be voted on separately. The recommendation is separate votes for separate obligations, with a shared definition of control. This prevents agreement with private verification from being mistaken for agreement with an untested exclusion mechanism.
4. DEFINITIONS: VALIDATOR IDENTITIES, NODES AND CONTROL
A validator identity means an on-chain validator record identified by its terravaloper address and associated consensus public key. A moniker, website or social account is a label, not proof of an independent operator.
A node means an infrastructure instance. A validator may legitimately use multiple full nodes, sentries, archive nodes, RPC nodes, monitoring systems and properly configured failover infrastructure. Terra’s legacy validator documentation describes sentry architecture as a security measure. The proposed restriction concerns multiple active validator identities under common control, not the number of servers. [7]
Common control means that the same person, entity or coordinated controlling group has the practical ability to direct validator business or governance decisions across more than one identity. Assessment must consider actual authority, contractual rights and economic arrangements, not only registered company names.
Evidence can include control over governance signing, operator-account authority, appointment of decision-makers, controlling ownership, contractual direction, and rights to validator commission income. No single indicator automatically determines the result.
Technical signing access is recorded separately. A hosting provider able to sign consensus messages creates an important operational dependency, but it does not automatically own every customer’s validator or direct every customer’s governance vote.
A beneficial owner means the natural person who ultimately owns or benefits from the business, subject to a documented definition. The standard must also identify people who exercise effective control without meeting a shareholding threshold. A 25% ownership disclosure threshold, if used, must not become a loophole for control through smaller holdings, agreements or nominees.
An authorised representative is someone permitted to act for the validator entity. Verifying that representative alone is insufficient to verify the ultimate controllers.
5. WHO MUST BE VERIFIED
Individuals and sole traders: verify the responsible natural person and their control of the validator operation.
Companies: verify the legal entity, its existence and registration where applicable, authorised representatives and relevant ultimate beneficial owners and controllers. A company certificate alone is insufficient.
Partnerships, associations, foundations and DAOs: document the actual decision rights, legal form where one exists, accountable representatives and controlling parties. A DAO label does not by itself establish independence or remove responsibility.
Multisignature operations: document the authority structure, threshold and parties with decisive powers. Publicly identifying every ordinary employee or minority participant is not required; the verifier must establish who can direct or block relevant actions.
Managed and white-label validators: verify the customer responsible for the brand and disclose the service provider’s actual powers. Record separately who controls consensus signing, governance signing, operator-account transactions, commission withdrawal and business decisions.
No seed phrase, private key, remote signing credential or infrastructure access is ever submitted to a KYC provider or community reviewer.
6. THE ONE-ACTIVE-VALIDATOR RULE
The proposed end state is one active validator identity per independent controller or common-control group on Terra Classic mainnet.
Different monikers, shell companies, nominee operators, relatives acting as fronts and branding arrangements do not create genuine independence where the same party retains effective control. Conversely, relatives or employees should not be assumed to share control solely because of a relationship; each case requires evidence.
An operator may run validators on other chains. Those do not occupy additional Terra Classic active-set places, although relevant shared infrastructure risks may be disclosed.
The same Terra Classic controller may retain historical, unbonded records where necessary for migration or recordkeeping. They must remain linked and cannot activate additional identities while the controller’s designated validator is active. The implementation must specify how status changes, acquisitions and pending migrations are handled.
Shared use of a hosting company, data centre, software, price feed or maintenance contractor is not conclusive proof of common business control. Hosting providers must disclose their role accurately. A provider that actually directs customer governance or controls their businesses cannot claim independence merely by calling them customers.
There is no proposed automatic stake cap and no change to stake-weighted voting. Splitting one stake across identities does not inherently create additional total voting weight. The concern is hidden concentration, misleading decentralisation claims, use of multiple active-set places and possible avoidance of rules aimed at individual validators.
For transparency, publish grouped voting power for verified common-control relationships alongside ordinary address-level figures. State the snapshot height and methodology. Do not claim that unresolved or unverified validators are independent. Keep business control, consensus-key dependency and infrastructure concentration as separate measurements.
7. TRANSITION FOR EXISTING MULTI-VALIDATOR OPERATORS
Existing operators should disclose all related Terra Classic validator addresses. Disclosure during the transition is not an admission of past misconduct under a rule that did not exist.
If the restriction is later adopted, give existing common-control groups a proposed 180-day consolidation period measured from implementation readiness, not from this forum post. The community may amend this duration based on redelegation constraints and migration testing.
The operator nominates one continuing validator and provides clear notices to affected delegators. Delegators retain their own choice of destination. No forced transfer to the proposer’s validator, an approved favourite, or a default committee selection is permitted.
Consolidation does not necessarily reduce concentrated voting power. All stake moving to the continuing identity may leave concentration unchanged. Transition reports must therefore measure controller-level power and infrastructure risk, not celebrate fewer addresses as proof of decentralisation.
Temporary overlap for an audited migration requires a published expiry, explicit approval procedure and inability to use the exception indefinitely. No permanent exception based on brand size or political influence is proposed.
8. PRIVATE VERIFICATION, LIMITED PUBLIC DISCLOSURE
Identity documents go directly to the approved independent verification provider through its secure process. They do not go to the proposer, validators, forum moderators or an informal community committee.
For each validator, the public registry should show only:
-
Terra Classic chain identifier and validator operator address;
-
current and relevant previous monikers;
-
verification provider, standard version and verification date;
-
credential expiry, current status and last status check;
-
proof-of-control result and its date;
-
relevant linked validator addresses and common-control grouping;
-
a coarse description of the operational model and material signing dependencies;
-
a public operational contact and a provider-verifiable credential reference.
Legal entity names or jurisdictions should be published only where necessary and legally justified. Personal legal names need not be public to establish a privately verified common-control relationship. Public grouping itself can identify people indirectly and requires a privacy assessment.
Do not publish passport numbers, document scans, home addresses, full birth dates, personal telephone numbers, biometric templates or document hashes. Identity-derived hashes are not automatically anonymous. The EDPB’s adopted July 2026 blockchain guidance recommends keeping additional personal data off-chain and addresses the continuing privacy risks of identifiers and hashes. [8]
Start with an off-chain, independently verifiable registry. Do not put additional identity credentials, status histories or control identifiers on-chain until necessity, retention, correction and erasure issues have been resolved. Even signed off-chain credentials remain subject to applicable privacy requirements.
9. PROVING THE LINK TO THE VALIDATOR
A person passing an ID check does not prove that they control the validator being advertised.
Require an independently reviewed challenge procedure binding the verification result to the operator account. A proposed challenge includes the verifier, chain identifier, operator address, standard version, unpredictable nonce, purpose and short expiry. The procedure must demonstrate appropriate operator authority, handle multisig arrangements and prevent replay or substitution.
Never ask the operator to sign arbitrary consensus messages or expose the consensus private key. Use an approved operator-account proof procedure, which may be a supported off-chain signature or a narrowly scoped transaction if the implementation review finds that necessary. It must display clearly what the user is signing and must not approve spending, delegation, governance changes or remote access.
Key control is evidence of account authority; it does not by itself establish beneficial ownership or prove the absence of undisclosed arrangements. Those are separate checks.
Recheck the binding after a relevant account-authority change, sale or operational takeover. A moniker change alone should update the record rather than automatically require full document collection again.
10. PROVIDER SELECTION AND CROSS-PROVIDER MATCHING
Request competitive proposals from at least two capable independent providers. Existing developer recognition makes SolidProof and CertiK reasonable candidates to assess, not automatic winners.
SolidProof describes manual and automated checks, a live call, Veriff involvement and encrypted offline storage. CertiK describes private identity and role checks and explicitly states that its badge is not a safety guarantee. These are vendor descriptions, not independent evidence that either already supplies this draft’s cross-validator control service. [9][10]
The procurement must establish:
-
a documented identity assurance standard and accepted evidence;
-
company and controller checks, including nominee-risk handling;
-
methods for linking credentials to validator addresses;
-
lawful, effective matching of common controllers across all accepted providers;
-
alternatives for unsupported documents and accessible human review;
-
security testing, subprocessors, storage locations and breach procedures;
-
narrow lawful-disclosure terms and protection from retaliatory requests;
-
signed status information, correction, expiry and revocation procedures;
-
a transparent fee schedule, service levels and orderly exit arrangements;
-
conflicts of interest, ownership and commercial connections to validators.
A multi-provider design must not allow the same controller to acquire unrelated credentials from different providers and appear independent. Conversely, an opaque universal identity database would create substantial privacy and capture risks. Providers must propose a lawful matching mechanism and demonstrate it in the pilot. No claim of complete duplicate detection is justified until this exists, and even a working mechanism cannot guarantee discovery of every hidden controller.
NIST SP 800-63A-4 supplies useful identity-proofing and redress benchmarks. It is a reference for procurement, not a declaration that LUNC or a chosen vendor is NIST-certified. W3C verifiable credentials provide a possible interoperable data model, but signatures attest to an issuer’s statements rather than proving every underlying claim is true. [11][12]
11. LEGAL RESPONSIBILITY AND PRIVACY
Before the pilot collects documents, identify the actual contracting party, relevant data controllers and processors, governing jurisdictions, privacy contacts and complaint routes. Saying “the community owns the data” is not a sufficient legal arrangement.
Commission a jurisdiction-specific review covering the participating operators, providers and registry administrator. Address lawful basis, necessity, proportionality, retention, security, international transfers and rights requests. A governance vote does not create statutory authority to collect sensitive data.
Provide a genuine non-biometric route where required and technically viable. If special-category biometric recognition is used, establish both the ordinary lawful basis and the applicable additional condition. Consent must not simply be assumed valid when refusal would prevent someone operating their validator. ICO guidance identifies these distinctions. [13]
Specify retention by data category and purpose. Do not assume an exchange-style five-year retention obligation applies to every validator. Keep identity evidence only as long as the relevant lawful purpose or legal obligation requires, with documented handling of legal holds.
Neither verification nor this proposal automatically makes every validator a regulated financial institution. FATF’s 2021 guidance distinguishes operation of a network, including validating blocks, from undertaking covered VASP services for customers. Other business activities and local laws can change the analysis. Present the standard as a proposed governance accountability measure, not as a universal AML law already binding on validators. [14]
12. CORRECTIONS, APPEALS AND PROTECTION AGAINST ABUSE
Publish neutral statuses: Verified; Renewal due; Pending; Expired; Suspended pending review; Revoked after review; Not verified. Explain the meaning of each. Administrative expiry or an unavailable document is not a finding of fraud.
Give an operator private written notice, the specific basis for an adverse decision, access to sufficient evidence to respond, and an opportunity to correct mistakes. Protect other people’s private data and investigation methods where justified, but do not rely on an unanswerable secret accusation.
Proposed consultation defaults are 30 days to cure ordinary administrative problems, 14 days to lodge an appeal and a target 30 days for independent appeal resolution. These are proposed service standards, not existing chain rules. Missing a provider deadline must not automatically turn a disputed case into a proven violation.
Appeals must be handled by reviewers independent of the original decision and without a commercial or governance conflict involving the parties. Reviewers should have relevant competence and defined terms of appointment. Community representatives may oversee process and published metrics but should not receive raw identity documents.
Specify who appoints reviewers, what happens if no independent reviewer is available, how legal disclosure requests are assessed and how decisions can be corrected. These must be resolved before mandatory activation.
A specific challenge requires supporting evidence. A funding transfer, common website designer, shared hosting company, social follow, voting agreement or personal relationship alone is insufficient to establish common control or fraud.
No credential is revoked because an operator criticised the proposer, voted No or NoWithVeto, declined a commercial partnership or expressed an unpopular opinion. A provider may restrict service where law requires it; such restrictions need an accurate reason and a lawful alternative route where available.
13. FALSE ACCUSATIONS AND MISLEADING PUBLIC CLAIMS
This framework must not operate a “truth committee.” Identity verification cannot determine the truth of every social media claim.
Encourage a separate evidence standard for serious public accusations: identify the specific conduct, relevant addresses or transactions, dates and attributable sources; distinguish verified facts from allegations and inferences; allow a response; correct materially false information visibly.
Disputed claims about scams, theft, criminality or secret affiliations should go through appropriate evidence-based processes. Do not embed unproven allegations about named validators in this proposal. ICO guidance also treats criminal allegations as potentially protected criminal-offence data, so any formal complaint database needs its own legal assessment. [15]
Identity information must not be disclosed to an accuser simply because they demand it. Lawful disclosure must follow the relevant provider’s obligations and a legally reviewed procedure. Verification may support identification in a valid investigation, but does not guarantee recovery of funds, prosecution or cross-border legal recourse.
14. NON-COMPLIANCE, REMOVAL AND BARRING FROM THE ACTIVE SET
The proposed mandatory end state is that a validator which does not complete the approved private KYC and control-verification requirements within the applicable deadline may be removed from the active set through the governance-approved enforcement process, and barred from re-entering while non-compliant.
This includes refusal to participate after reasonable notice, failure to complete verification after supported alternatives and cure periods have been offered, and a final substantiated failure under the approved standard after independent appeal. Pending verification, administrative delay and a disputed decision must be distinguished from a final non-compliance finding.
For the first mandatory rollout, the proposed completion window is 90 days from funded programme readiness and formal operator notice, subject to amendment after provider quotations and the pilot. Provider-caused delay, unsupported documents and properly lodged appeals require the defined extension procedure. The separate proposed 180-day consolidation window concerns existing multi-validator operations, not a blanket extension of the KYC deadline.
Governance must approve the eligibility standard, transition Discussion: Mandatory Private Validator KYC, Ownership Transparency and One Active Validator per Independent Controller
