
ERC-8443: Quantum Bridge Shield
Draft ERC from Quantova Inc proposing a "Quantum Bridge Shield" for Ethereum bridges. A committee signs the Merkle root of each message batch with RFC 8554 LMS hash-based signatures instead of ECDSA/BLS keys that Shor's algorithm can break. The guard contract requires a strict majority of distinct unfrozen keys, records used leaves, freezes any key that signs a leaf twice, binds digests to domain, chain, guard and epoch, and applies a 60-second delay. The post gives gas costs (LMS W4 height-10 verification about 205k gas, a LayerZero packet 128,683 gas, worst-case rotation 12.44M gas under the EIP-7825 cap) and cites a NioLabs assessment with no critical or high findings. It is relevant as a worked post-quantum migration design for bridge key custody, including hybrid ECDSA+LMS mode and stateful-signature pitfalls such as leaf reuse and rollback.
What it is
ERC-8443 is a draft from Quantova Inc (PR #2071 on ethereum/ERCs, with a reference implementation in quantova-inc/Quantova-bridge-guard). It is a guard contract that accepts a bridge batch's Merkle root only if a committee has signed it with RFC 8554 LMS signatures. The post is vendor-authored and still open for feedback.
Numbers the summary omits
- Parameters: SHA-256 with 32-byte outputs, tree heights 5 to 25, Winternitz W of 1, 2, 4 or 8. A public key is 56 bytes. A W4 height-10 signature is 2,508 bytes.
- Single verification: 185,093 to 223,979 gas (mean 204,807) over 16 signatures.
- Batch approval, hybrid LMS+ECDSA: 549,015 gas for 2 of 3 members, 1,686,595 gas for 6 of 10. Cost scales roughly linearly with the number of signers, so the committee size you choose drives the approval cost.
- Per-message cost: 7,078 gas to accept one message from an approved batch of 256, so the approval cost is amortized across the batch.
- Rotation: the worst case the guard accepts is 12.44M gas, 26% under the EIP-7825 cap of 16,777,216.
Signer-side state handling
The kit's protections against leaf reuse and rollback are:
- durable leaf reservation
- a monotonic high-water mark
- refusal to run on network file systems
On-chain, a double-signed leaf freezes that key.
What to do
Reviewers are asked to weigh in on three points:
- whether the default parameter set should be W4 at height 15 or 20 (the draft does not state a default)
- whether the committee size bounds fit real bridge operators
- leaf bindings for bridge designs other than the packet verifier binding in the draft
If you run a bridge, the useful check is to compare the per-approval gas figures above against your committee size and batch cadence.
Caveats
- The assurance claims are the vendor's own. NioLabs reports no critical or high findings. The page says nothing about medium or low findings and does not link the report.
- The test suite is 55 contract tests, 512-run fuzzing, RFC 8554 Appendix F vectors, and 24 rounds of contract-to-signer-kit parity checks.
- The page gives no analysis of signature-size or calldata cost beyond the gas figures.
- The 60-second delay is a fixed minimum before a root can be used.
Organisations named here
- CNSA 2.0
- EIP-7825
- ERC-8443
- FIPS 204
- harvest now decrypt later
- ML-DSA
- ML-KEM
- NioLabs
- NIST IR 8547
- NIST SP 800-208
- Quantova Inc
- RFC 8554
- Shor's algorithm
Technologies named here
- NioLabs security assessment
- Draft pull request
- LayerZero packet verifier binding
- Quantova network post-quantum stack
- Ethereum
- LayerZero
- LMS
- ECDSA
Techniques named here
- Shor's algorithm
- Harvest now, break later
- Grover search against hash functions
- Leaf reuse in stateful hash-based signatures
Related in Blockchain

THORChain Exploit Report #2 — GG20 root-cause disclosure

Black Thursday revisited: MakerDAO keeper exploited for $500K
.jpg)