Quantova's post-quantum interoperability layer — the verifiable, proof-based bridge that connects the Quantova Layer 1 to external networks. Cross-chain transfers settle against cryptographically proven finalized state on both sides, not against a trusted custodian, and the Quantova side of that verification is post-quantum end to end.
Quantova builds on the Hyperbridge interoperability-proof framework and upgrades it for a post-quantum network: the verification path, the authority and signing primitives, and the settlement anchoring are reworked so the bridge inherits the same quantum-resistant guarantees as the rest of the protocol. The result is a cross-chain layer engineered for a world where classical signature schemes are no longer safe.
Current bridge position. Quantova's bridge now verifies 36 chains / 68 assets. The proof crates in this repo back the trust-minimized tiers: ETH sync-committee and BSC Parlia light clients (+ EIP-1186 MPT proofs), Tendermint + ICS-23 for Cosmos, GRANDPA + sp-trie for Substrate, and SHA256d SPV for the Bitcoin family. See BRIDGE-SPEC.md for the full chain→proof matrix, the over-collateralized BTC vault custody model, and the honest trust boundaries (optimistic L2s and Monero are not represented as trustless).
This repository is the engine behind Quantova's bridge — a runtime module governed by the Quantova Virtual Machine (QVM), not an application-layer contract. The work in this repo is to turn a verifiable interoperability coprocessor into a post-quantum, finality-anchored bridge for Quantova:
- A post-quantum verification path. Where the bridge produces or verifies signatures and
authority attestations on the Quantova side, we replace classical elliptic-curve cryptography
with Quantova's NIST post-quantum schemes — Falcon (FN-DSA), CRYSTALS-Dilithium (ML-DSA),
and SPHINCS+ (SLH-DSA) — and SHA3-256 hashing. There is no
ecrecover/secp256k1 path anywhere in the Quantova trust base, including the bridge. - Finality-anchored settlement. Every outbound message (Quantova → external) anchors its proof to a finalized Quantova block before it can be claimed on the remote chain; inbound messages are credited only after the source chain reaches its own finality. Quantova finality is deterministic (~3s) and does not reorg — the property a proof-anchored bridge has to have.
- Deterministic reconciliation under the QVM. Lock, mint, burn, and release execute deterministically under QVM rules and are recorded on-chain. External networks are treated as independent settlement domains: Quantova verifies proofs about a counterparty's finalized state and reconciles asset movement — it never imports or executes a foreign virtual machine or consensus.
- Quantova-native proving on our side. The finalized state being proven to counterparties is produced by Quantova's deterministic, no-VRF consensus and Falcon-keyed finality, so the bridge's proofs about Quantova rest on post-quantum authority from the ground up.
- Per-route trust, stated plainly. Routes whose consensus is provable use the trustless, proof-based path. The Tron route uses a trusted-relayer integration, and its trust assumptions are documented rather than implied.
Supported counterparties: Ethereum, Binance Smart Chain (BSC), and Tron. The public
testnet endpoint is wss://testnet.quantova.io.
The bridge is, at its core, a coprocessor for the cryptographic operations that confirm cross-chain messages — consensus proofs, consensus fault proofs, state proofs, and state-transition validity proofs. Quantova's upgrade focuses on the half of that work rooted in Quantova's own security model:
- Authority & signing. Quantova-side attestations and authority keys use Falcon at the finality layer and the wider Dilithium / Falcon / SPHINCS+ suite elsewhere — the same schemes that secure Quantova accounts and validators.
- Hashing & commitments. State commitments and message hashing on the Quantova side use SHA3-256, with headroom to SHA3-512+ via forkless runtime upgrade.
- No classical fallback on our side. The Quantova verification path contains no elliptic-curve key for a quantum adversary to recover. Counterparty-consensus verification (proving an external chain's finalized state) uses that chain's own consensus-proof scheme, since Quantova cannot change a remote chain's cryptography — only how it is verified and anchored here.
For the protocol-level bridge description, see the developer documentation and the consensus-specs repository.
The bridge keeps a permissionless relayer model: anyone can run a relayer that transmits messages across chains, without staking or whitelisting. Relayers are message-passers — they cannot forge a transfer, because validity rests on the proofs, not on the relayer.
- Run a messaging relayer
- Run a consensus relayer
- Run a node
Operational guides for running Quantova bridge relayers and nodes are published in the developer documentation. For node build and run instructions, see the consensus-specs node guide.
Application developers can use the Quantova bridge for cross-chain applications that need a verifiable, proof-based security model rather than a trusted one.
- Quantova / QVM developers — interact with the bridge through the QVM bridge module.
- Counterparty (EVM) developers — integrate on the Ethereum / BSC side using the counterparty contracts and consensus-proof interfaces.
| Repository | Purpose |
|---|---|
| consensus-specs | Quantova consensus and finality — the state proven on the Quantova side. |
| developer-content | Developer documentation, including the bridge and JSON-RPC reference. |
| security-documentation-repository | Security policy and bug bounty — bridges are an in-scope, high-priority area. |
Quantova's bridge builds on the Hyperbridge interoperability framework by Polytope Labs,
which is licensed under the Apache License, Version 2.0 (© Polytope Labs Ltd.). Upstream files
retain their original Apache-2.0 license and SPDX-License-Identifier headers, and the upstream
LICENSE/NOTICE are kept in this repository; Quantova does not relicense upstream code.
Quantova's own code, configuration, and post-quantum integration in this repository are © 2026 Quantova Inc and licensed under the Business Source License 1.1 (BUSL-1.1), except where a file carries an upstream Apache-2.0 header, which governs that file.
"Quantova", "QVM", "QRC20", "QNS", and "QTOV" are trademarks or technology identifiers of Quantova Inc. © 2026 Quantova Inc.