# Quantus ↔ Ethereum ↔ Solana Bridge Roadmap (Plonky3-Only)
## Introduction
This document outlines the roadmap for a trust-minimized bridge between Ethereum (ERC-20), Solana (SPL),
and Quantus (Substrate PoW, PQ). The design uses **Plonky3** exclusively, leveraging its transparent setup,
recursion, and alignment with a post-quantum security narrative. Groth16 and other SNARKs are not in scope.
---
## Phase 0 — Trusted MVP
- **Mechanism:** Multisig/MPC validators.
- **Ethereum side:** `TokenVault` escrows ERC-20.
- **Solana side:** `TokenVault` program escrows SPL.
- **Quantus side:** `pallet-bridge-core` + `pallet-assets`.
- **Relayers:** Submit signed events cross-chain.
- **Security:** Economic trust in validator set, strict rate limits, circuit breaker.
- **Goal:** Enable ERC-20 ↔ Quantus and SPL ↔ Quantus transfers quickly.
---
## Phase 1 — Plonky3 Light Client (Quantus → Ethereum & Solana)
- **Circuit:** Proves Quantus headers are valid descendants of a known checkpoint.
- **Consensus checks enforced:**
- Proof-of-Work validity (`hash(header) < target`).
- Difficulty adjustment algorithm correctness.
- Timestamp bounds.
- **Public inputs:** Checkpoint hash, final header hash, cumulative work.
- **Formula:**
```
W = Σ floor(2^256 / (target_i + 1))
```
- **Bridge logic:** Ethereum contract and Solana program both accept Plonky3 proofs of Quantus headers.
- **Message inclusion:** Outbound burns proven by Merkle proofs anchored in Quantus headers.
---
## Phase 2 — Ethereum & Solana → Quantus zk Verification
- **Ethereum side:** Plonky3 circuit verifies Ethereum finalized headers + Merkle Patricia proofs of events.
- **Solana side:** Plonky3 circuit verifies Solana finalized block headers + Merkle proofs of account state/events.
- **Quantus runtime:**
- `pallet-eth-lightclient` accepts Ethereum proofs.
- `pallet-sol-lightclient` accepts Solana proofs.
- **Result:** Bidirectional zk verification with both Ethereum and Solana.
- **Fallback:** Validator signatures retained for liveness.
---
## Phase 3 — Recursive Batching + Efficiency
- **Recursive composition:** Aggregate large ranges of Quantus, Ethereum, and Solana header proofs into succinct proofs.
- **Anchoring cadence:** Post these aggregate proofs periodically on Ethereum and Solana.
- **Gas/compute savings:** Lower on-chain costs; easier management of cross-chain commitments.
- **Unified relayers:** One relayer stack can submit recursive proofs to both Ethereum and Solana.
---
## Phase 4 — Full Trustless Production
- **Canonical selection:** Only proofs extending the last accepted checkpoint are valid.
- **Fork handling:**
- For Quantus (PoW): heaviest chain via cumulative work.
- For Ethereum (finality): rely on finalized headers.
- For Solana: rely on confirmed supermajority finalization.
- **Mitigations:**
- Finality delays and challenge windows.
- Rate limits, pause functionality, operator bonds/slashing.
- **Outcome:** Secure, zk-enforced interoperability across Ethereum, Solana, and Quantus.
---
## Security Assumptions
1. **Checkpoints:**
- Anchored on Ethereum and Solana.
- Prevents fake offline forks; proofs must extend accepted headers.
2. **Post-checkpoint forks:**
- **Quantus:** resolved by cumulative work (`W = Σ floor(2^256 / (target_i + 1))`).
- **Ethereum/Solana:** resolved by relying on their finality rules.
3. **Finality & Stability:**
- N-block delays on Quantus; native finality guarantees on Ethereum and Solana.
- Challenge windows allow disputes to surface.
4. **Trust model:**
- Transparent setup only (Plonky3).
- Strengthened by bonds, slashing, and governance-controlled limits.
---
## Why Plonky3?
- **Transparent setup:** No ceremony needed.
- **Recursion:** Efficient aggregation across *three chains*.
- **STARK-like security:** PQ-aligned cryptography.
- **Narrative win:** Unique positioning by unifying Ethereum, Solana, and Quantus bridging on Plonky3.
---
## Conclusion
This roadmap expands the bridge scope to Ethereum and Solana, using Plonky3 exclusively.
Checkpoints and fork-choice ensure correct chain selection, while recursive proofs reduce cost.
The design provides a secure, efficient, and narrative-strong interoperability layer across three major ecosystems.