Most cross-chain bridges have the same structural problem: they extend trust assumptions from one chain to another without clearly documenting what those assumptions are. A bridge connecting chain A to chain B typically inherits whichever chain has the weaker security model β and if any key material in the path is classically signed, the entire bridge is classically vulnerable.
This post walks through how Quantova's bridge is structured, what verification actually means for each connected chain family, and why the post-quantum signing model matters even when the destination chain isn't post-quantum.
The core problem with bridge security
When a bridge moves an asset from chain A to chain B, something has to attest that the lock or burn on chain A actually happened. That attestation is a signed message. The security of the bridge is only as strong as the keys signing that message.
Most bridges use ECDSA or secp256k1 keys for attestation β the same cryptographic primitives used in standard Ethereum accounts. This is a problem not just today but structurally, because harvest-now-decrypt-later means an adversary can record every bridge attestation issued today and revisit them when quantum hardware matures. Bridge messages are often high-value, time-stamped, and permanently on-chain. They're a natural archive target.
Quantova's bridge uses NIST-standardized post-quantum signing for all attestations on the Quantova side β Falcon-512 for validators, Dilithium and SPHINCS+ at the account layer. No secp256k1 key participates in any Quantova-side settlement message, regardless of which chain is on the other end.
Verification tiers
Not every chain supports the same verification mechanisms. The bridge maps three tiers to chain families based on what their protocol actually supports.
Tier 1 β SPV (Bitcoin)
Bitcoin is verified using simplified payment verification: SHA256d Merkle inclusion proofs against a block header chain. The Quantova runtime validates that a Bitcoin transaction was included in a valid block by checking the Merkle path against the block header, and that the header chain has sufficient proof of work.
There is no trusted relayer involved in this path. The proof itself carries the guarantee. An invalid Merkle proof will not pass the on-chain verifier regardless of what any relayer asserts.
Bitcoin TX β Merkle proof β Block header chain β Quantova on-chain verifier
This is the strongest trust model available for any external chain β it requires no assumptions about the honesty of any off-chain participant.
Tier 2 β Light Client (Ethereum, BSC, Cosmos, Substrate)
For chains with richer finality mechanisms, the bridge uses light-client proofs:
Ethereum / BNB Smart Chain: Sync-committee BLS attestations + EIP-1186 Merkle-Patricia-Trie storage proofs. The bridge verifies that a supermajority of the current sync committee signed a block containing the relevant state root, then verifies the storage proof against that root.
Cosmos / Celestia: Tendermint BFT finality with ICS-23 membership proofs. The bridge checks that β₯β
of validators by stake signed the block, then verifies the ICS-23 proof against the committed app hash.
Polkadot / Substrate chains: GRANDPA finality proofs with sp-trie state proofs.
Remote chain state β Finality proof β State root β Storage/membership proof β Quantova verifier
Again, no trusted assertion from a relayer β the chain's own finality mechanism is what Quantova verifies. A relayer can submit the proof, but cannot forge it.
Tier 3 β Federated quorum (EVM L2s, Solana, TRON, XRP, others)
For chains where trustless verification isn't yet practical β either because the protocol doesn't expose the required proof data, or because the proving costs are prohibitive β the bridge uses a federated relayer model.
A quorum of at least β of the registered relayer set must independently attest to a cross-chain state transition before Quantova processes the settlement. Relayers are registered on-chain, quorum thresholds are governance-controlled, and each attestation includes a strict nonce ordering requirement to prevent replay.
This is explicitly a weaker trust model than SPV or light-client β the security relies on honest majority among relayers. The bridge documentation states this directly. There is no pretense of trustlessness where it doesn't exist.
Bitcoin custody: over-collateralized, SPV-enforced
BTC bridged into Quantova uses an over-collateralized vault model (Interlay iBTC). Vault operators lock collateral exceeding the BTC value. If the collateral ratio falls below threshold, automated liquidation triggers before the position becomes undercollateralized.
Every lock and unlock is gated on an SPV proof from the Bitcoin side β no trusted signer in the custody path. The vault parameters and liquidation logic are on-chain and auditable.
Governance and fee parameters
Bridge configuration β chain additions, relayer set changes, quorum thresholds, fee adjustments β is governed on-chain:
Minimum approval: β₯80% of participating validators
Minimum participation: β₯40% of total stake
Timelock: multi-week delay after a proposal passes before changes take effect
No bridge parameter can be changed unilaterally or by a minority. The timelock gives the ecosystem time to react to any governance proposal before it executes.
Bridge fees are 0.10% of settled volume, routed directly to the protocol treasury, which is itself governed on-chain.
Why post-quantum signing on the Quantova side matters regardless of the destination
When a validator on Quantova signs a settlement attestation for a Bitcoin SPV proof, that signature is a Falcon-512 signature. When it signs a Cosmos light-client proof, same. When a federated relayer set attests to a Solana state transition and the Quantova side processes it, the internal finalization message is post-quantum signed.
The destination chain doesn't know or care about this β it's an internal Quantova property. But it means the Quantova-side audit trail, the validator attestations, and the settlement history are all post-quantum signed data. Every message in the bridge's history is resistant to retrospective decryption.
