Post-Quantum Roadmap RFC (Pre-Formal Discussion)

General
1

Post-Quantum Roadmap RFC for Terra Classic (Pre-Formal Discussion)

Summary

This RFC defines a structured roadmap for how Terra Classic can prepare for long-term cryptographic risk from future quantum-capable attacks against widely used classical signature schemes.

The purpose is to give the community a clear, auditable decision framework before implementation starts: what the target states are, how migration is phased, where security and audit gates are mandatory, how live-chain migration risk is handled, and how governance decisions are documented and escalated.

In short, this document is intended to move Terra Classic from ad-hoc discussion to a coherent, risk-aware transition plan, especially for the consensus path and interchain dependencies.

Why this is needed

Terra Classic relies on cryptographic signatures in its most critical system paths, and changing those paths safely cannot be handled as a simple software update. It requires staged planning, explicit risk controls, and governance-visible checkpoints. Without that structure, migration decisions would be fragmented, harder to audit, and more likely to introduce avoidable operational risk.

The need is even stronger because of IBC. Parts of the migration impact do not sit only on Terra Classic, but depend on counterparty chains and their client upgrade decisions. That means the roadmap must include external dependency handling, fallback modes, and clear Go/No-Go logic. This RFC provides that structure so preparation can happen early, transparently, and with documented accountability rather than under future time pressure.

What this post is

This post opens an informal, non-binding discussion on the document before formal kickoff of the actual RFC workflow.

What this post is not

  • Not the formal RFC feedback window
  • Not a governance proposal
  • Not a freeze decision

Document

Feedback requested

Please focus on:

  1. Overall logic and clarity of the roadmap
  2. Risk treatment (especially IBC counterparty dependency)
  3. Practical feasibility of migration flow and fallback modes
  4. Governance/escalation clarity
  5. Missing high-impact risks or decision points

Suggested comment format

  • Section
  • Issue type (clarity, risk, missing, inconsistency, other)
  • Comment
  • Suggested change (optional)

Timeline

Informal discussion is open until 5th of June 2026. After consolidation of this round, I plan to submit governance (including formal Discourse discussion) to formally start the official RFC feedback window.

4 Likes
2

Thank you for your hard work Till.

I will try to find the time to read the document but I really believe we should try to get you real peer review, from experts.

Anybody know anyone, who could help?

3

yes I think it should be peer reviewed. but i also want to point out, that this is an unofficial discussion round that likely will not gain much academic attention. for that matter: this is an “RFC” document - literally a “request for comments”. expert and enterprise level review comments will likely be most valuable in an official request-for-comments flow that I am planning to kick-off with a separate governance proposal. the proposal will officially ask Terra Classic stakeholders to pass their comments through official channels (tbd) in order to get coordinated feedback and editorial value harness.

1 Like
4

Have you checked on a solution to the IBC challenge?

5

Roger that. Now back to reading :saluting_face:

6

Hey Strath. Thank you for your comment. The challenge is still there and pretty much unsolved currently. I explicitly mentioned it as a Phase A go/no-go criterium and research item. In my opinion, counterpart chains must show a sense of willingness here. As a backup solution Terra Classic would be able to develop a 08-wasm client solution that is able to replace the 07-tendermint client with an L2 contract written in rust. Then ask the counterparty chains to deploy this client - then open a new connection and migrate existing locked vouchers to the new connection pair.

1 Like
7

Okay, makes sense yes.

8

This is exactly the kind of forward thinking, mature infrastructure work the LUNC community needs. The formal phased structure (Omega → Phase A: Consensus Path PQ-Enabled → Phase B: Wallet/Tx hybrid → Phase C: PQ-Native Clients), mandatory audit gates, clear target states (PQ-only for consensus, hybrid for wallet/tx), and detailed live chain migration paths with IBC fallbacks make the proposal pragmatic and low disruption.

A couple of polite notes for the formal version:

• Performance & gas-cost benchmarks for ML-DSA (especially larger signatures and verification costs on high-volume paths) will be important for broad holder confidence, the RFC already flags this as needing measurement and audit.

• Ecosystem coordination (wallets, explorers, bridges, dApps) is well covered in Phases B and C, an explicit high level checklist or timeline in the next iteration could help even more.

Other than those minor points, this looks rock solid and positions Terra Classic as one of the few chains actually future-proofing itself. Happy to help test, review, or support the next steps.

Great work Frag!

1 Like
9

Thank you for your valuable input. I think performance and gas cost is something that I can (and SHOULD) mention in Omeaga and Phase A specifically. You’re right about flagging it.

I am not sure what you mean with “high level checklist or timeline”? Are you referencing only to Phases B and C (infra coordination) or the whole document?

1 Like
10

100% full support :right_facing_fist:t2::left_facing_fist:t2::folded_hands:t2:

1 Like
11

Hello my friend just for phases B and C :folded_hands:

1 Like