BABYLON · L1 · STAGE 1 ACKNOWLEDGED BUT UNSTARTED · QRI 28 v3.1.0 methodology

In plain terms

What it is. Babylon lets people lock real Bitcoin to help secure its network, and that whole arrangement currently relies on the kind of math a future quantum computer could undo.

What we found. The team has not pretended otherwise and makes no false safety claims, but it has also published no plan or timeline to fix the problem, and part of the weakness comes from the Bitcoin side, which is out of its control.

Why it matters. Anyone staking Bitcoin here is exposing a key that could one day be cracked, so without a published fix you are trusting that the quantum threat stays far enough away.

Cosmos-SDK / CometBFT L1 (Genesis mainnet 2025-04-10) anchored to Bitcoin via covenant-multisig BTC staking. Every signing primitive in the stack is Shor-breakable: Ed25519 validator consensus, BLS12-381 checkpoint aggregation, Schnorr/BIP340 BTC staking, Schnorr-based EOTS finality votes, and Schnorr adaptor signatures. Zero PQ primitives deployed at any layer; no published PQ roadmap from Babylon Labs.

inLinkedIn ↷Audit access ⇆Compare Verified 2026-05-02

Summary

Babylon Genesis is a Cosmos-SDK chain using CometBFT Ed25519 validators, with BLS12-381 multi-signature aggregation in the checkpointing module and Bitcoin-side Schnorr/BIP340 staking under a covenant-emulator multi-sig. Finality providers cast EOTS (Schnorr-based one-time signatures) over Babylon block hashes; double-vote leaks the EOTS secret key for slashing. Mainnet went live 2025-04-10. No PQ primitive is deployed at consensus, finality, BTC-staking, or covenant layers; Babylon Labs has published no PQ migration roadmap and no working-group statement. mainnet-traffic cap fires (5a = 0), Milestone-Discipline cap fires (5d = 0), Supply-Chain cap fires (4 of 4 vendor tiles lack PQ roadmap). Gate 1a-Sig and Gate 1a-KEM both FAIL. The structural difficulty is twofold: BTC-staking inherits Bitcoin's classical Schnorr exposure, and BLS12-381 aggregation has no efficient PQ drop-in. QRI 28, Band 3 Planning. Migration Stage 1, general industry awareness without a PQ-specific architecture.

What the gates say

Gate 1a, Hybrid signature: FAIL , no documented hybrid signature composition on Babylon Genesis or in BTC-staking covenant flow
Gate 1a, Hybrid KEM: FAIL , CometBFT P2P uses X25519 station-to-station; RPC TLS uses RSA / X25519 ECDH; no ML-KEM hybrid
Gate 1b, Commit-to-hash: COND , no OR-composition declared
Gate 2, Evidence reconstruction: PASS , every sub-score reconstructible from cited public artifacts within 48h
Gate 3, Primitive naming: PASS , Ed25519, BLS12-381, Schnorr/BIP340, EOTS, SHA-256, secp256k1 ECDSA all named

Burn-vs-rescue policy on file

Declared option f, Undeclared. Babylon Labs has not published a position on dormant-balance handling, classical-key sunset, or rescue mechanism for Bitcoin staked under Schnorr/BIP340 in a post-Shor world. BTC-staking inherits Bitcoin's protocol-level burn-vs-rescue posture, which is itself undeclared at the Bitcoin layer.

Seven dimensions

Each dimension scores 0–100 internally; the weighted roll-up produces the QRI.

1 Cryptographic Exposure weight 15% 38 / 100

1a · primitive inventory 14 / 20

Babylon Labs documents the primitive set across multiple repositories (babylonlabs-io/babylon, babylonlabs-io/covenant-emulator, babylonlabs-io/finality-provider) with module-level READMEs.

Primitives: Ed25519 (CometBFT validator consensus signing on Babylon Genesis) · BLS12-381 (validator BLS multi-signature aggregation in x/checkpointing module) · Schnorr / BIP340 (secp256k1) (BTC staker public keys, unbonding signatures) · Adaptor signatures (Schnorr, secp256k1) (slashing and unbonding-slashing co-signed by covenant committee) · EOTS (Extractable-One-Time-Signatures, Schnorr-based over secp256k1) (finality-provider votes) · SHA-256 (Bitcoin transaction hashing, checkpoint commitments) · secp256k1 ECDSA (Cosmos account signing path)

1b · shor grover pq tag 12 / 20

Tags:

Ed25519 → Shor-break (DL on Edwards curve)
BLS12-381 → Shor-break-via-pairings
Schnorr / BIP340 (secp256k1) → Shor-break (DL on secp256k1)
Adaptor signatures (Schnorr) → Shor-break (DL on secp256k1)
EOTS → Shor-break (Schnorr-based, DL on secp256k1)
secp256k1 ECDSA → Shor-break (DL)
SHA-256 → Grover-weaken (effective 128-bit security)

1c · family diversity 0 / 20

Zero PQ-safe families deployed. No lattice, no hash-based, no code-based, no isogeny scheme in production at any layer.

1d · nist security category 4 / 20

No NIST PQC-categorized primitive deployed. Classical primitives at ≈128-bit classical security (broken under Shor); SHA-256 at ≈128-bit post-Grover.

1e · implementation quality 8 / 20

Library provenance: CometBFT (Ed25519), gnark-crypto / Cosmos BLS module (BLS12-381), Bitcoin Core / btcsuite (Schnorr-secp256k1), Babylon Labs in-house EOTS implementation. Audit history: Zellic Phase-1 (2024), Zellic Babylon Genesis Chain audit (2025-03), 32 findings (7 critical, 3 high) reported as resolved or acknowledged. No third-party constant-time validation cited; no machine-checked formal verification of EOTS or covenant-emulator. Cryptanalytic tier: Tier 1 mature classical.

2 Quantum Recovery Exposure weight 10% 29 / 100

Forge subtotal: 21/75 Decrypt subtotal: 8/25

2a · active key exposure 4 / 25

Active CometBFT validators reveal Ed25519 consensus pubkeys per block; BTC stakers publish BIP340 32-byte x-only Schnorr pubkeys in every staking output script; finality providers reveal EOTS pubkeys and per-round public-randomness commitments. Every actively staking BTC pubkey is exposed on Bitcoin.

2b · cold key exposure 12 / 25

Babylon Genesis launched 2025-04-10 (~13 months at evaluation date), limited dormant supply on Babylon side. However, BTC anchored under classical SHA-256 + Schnorr inherits Bitcoin's full cold-key exposure profile.

2c · sig long term validity 5 / 25

All historical Ed25519 consensus signatures, BLS checkpoint multi-sigs, and Schnorr BTC-staking signatures are post-Shor forgeable. No PQ attestation layer exists for historical Babylon block signatures. Checkpoints commit to Bitcoin via Schnorr/SHA-256, quantum-resistant only inasmuch as SHA-256 commitments remain Grover-bounded.

2d · encryption confidentiality hndl 8 / 25

Validator P2P uses CometBFT default transport (X25519 station-to-station). RPC endpoints use standard TLS (RSA / X25519 ECDH). No PQ KEM (ML-KEM / hybrid) integrated into validator gossip or RPC. No public statement on PQC migration for transport.

3 Metadata, Anonymity & Confidentiality weight 13% 20 / 100

3a · tx graph visibility 4 / 20

Pseudonymous transparent ledger on both sides, Cosmos-SDK transparent accounts on Babylon Genesis and UTXO-transparent staking outputs on Bitcoin. Staker pubkeys, finality-provider pubkeys, and stake amounts are all public.

3b · rpc mempool concentration 6 / 20

Top RPC providers include Polkachu, Imperator, Kjnodes, and validator-operated public endpoints; concentration moderate but not publicly quantified. CometBFT mempool gossip observable to any participant. No protocol-level validator-metadata retention policy declared.

3c · cross chain bridge correlation 5 / 20

BTC↔Babylon linkability is structural: each BTC staking transaction links a BTC UTXO to a Babylon finality provider and (via address derivation) to a Babylon account. IBC connections to other Cosmos chains add further linkability surfaces.

3d · retroactive de anonymization 5 / 20

Shor on secp256k1 reconstructs every BTC-staking adaptor-signature trace, every EOTS public-randomness commitment, and every Schnorr unbonding signature, exposing the full historical staking and finality history. No mitigation.

3e · mixnet shuffle 0 / 20

No on-chain mixer, no commit-reveal shuffle, no integrated mixnet on Babylon Genesis.

4 Migration Architecture weight 10% 36 / 100

4a · crypto agility 6 / 15

Cosmos-SDK / CometBFT chains can in principle swap consensus signature scheme via coordinated hard fork. CometBFT itself has had open BLS/Ed25519 abstraction discussions but no production PQ path. No Babylon-specific crypto-agility spec or production instance of an algorithm switch within BTC-staking, finality, or covenant primitives.

4b · aa key rotation 6 / 20

Cosmos-SDK supports account key-rotation via app-layer patterns (x/auth ante-handlers, ICA). No PQ client-layer path documented for Babylon. BTC stakers can unbond and re-stake to a fresh pubkey, but this is same-family rotation, not PQ migration.

4c · hard fork track record 9 / 15

Babylon Genesis V2 upgrade has been planned/delivered. Limited operational history (~13 months). No contested forks but no multi-year cadence yet.

4d · hybrid deployment readiness 0 / 15

No documented hybrid (AND/OR) signature composition for any signing event on Babylon Genesis or in BTC-staking covenant flow. No spec, no testnet pilot.

4e · stateful hash state management 15 / 15

No stateful hash scheme (XMSS/LMS/leanXMSS) deployed. Default 15/15 per v3.1 rule.

4f · bft aggregation path 0 / 20

Babylon checkpoints aggregate validator votes via BLS12-381 multi-signature (Shor-break-via-pairings); finality round uses Schnorr/EOTS aggregation (Shor-break). No PQ aggregation path declared, no spec, no testnet. CometBFT itself has no PQ consensus signature path merged.

5 Deployment Execution weight 22% 32 / 100

5a · mainnet pqc traffic pct 0 / 25

Zero. No PQC primitive in mainnet signing traffic on Babylon Genesis or in BTC-staking covenant. mainnet-traffic cap fires (5a < 20%).

5b · pqc code in consensus client 0 / 15

No PQ primitive merged into Babylon node binary or CometBFT. No falcon_verify, no ML-DSA, no SLH-DSA path.

5c · validator pqc key adoption 0 / 15

No validators register PQ keys. Validator key spec is Ed25519 only (cosmos.crypto.ed25519.PubKey).

5d · published dated milestones 0 / 10

5a = 0 → 5d voided per v3.1 rule. No dated PQC milestone with on-chain enforcement published by Babylon Labs.

5e · pqc washing delta 12 / 15

Announced PQC: zero. Shipped PQC: zero. Ratio 0/0, no washing because there is no PQC narrative to wash. Score reflects narrative-honesty (Babylon does not claim PQ posture it does not have).

5f · signature footprint multiplier 20 / 20

No PQ signatures deployed → no footprint multiplier impact today. Trivially 20/20 in absence of PQ deployment; would drop precipitously if PQ scheme introduced without footprint planning.

6 Supply Chain Vendor Readiness weight 22% 11 / 100

6a · wallet 2 / 25

Top wallets supporting Babylon staking: OKX Wallet, Keplr, Leap, Cosmostation, Ledger HW (BTC + Cosmos apps). None has a published PQC roadmap traced. Ledger has general PQ research but no Babylon/Cosmos-app PQ commitment.

6b · bridge 2 / 25

IBC (default Cosmos bridge), Babylon BTC-staking bridge (covenant-multisig). No PQC roadmap on IBC or covenant tooling. Bitcoin itself has no consensus-level PQ scheme.

6c · custodian 3 / 25

Babylon staking is supported by BitGo, Anchorage, Fireblocks, and Kiln (institutional staking). No custodian has published a Babylon-specific PQC migration timetable.

6d · rpc hsm tee infra 4 / 25

RPC: Polkachu, Imperator, Kjnodes, validator-operated public endpoints. HSMs: Horcrux, AWS KMS, YubiHSM, Thales. TEE attestation chains not on Babylon validator path. No PQC roadmap on any infra tile.

7 Governance & Coordination weight 8% 42 / 100

7a · validator stake distribution 11 / 20

Babylon Genesis runs 100 CometBFT validators in the active consensus set, with a separate set of ~60 Bitcoin-staked finality providers in the dual-quorum design. BABY token concentration in early phase is typical of newly-launched Cosmos chains.

7b · upgrade cadence under pressure 11 / 20

Limited track record (Genesis launched 2025-04-10). V2 upgrade delivered. No contested forks, but no multi-year cadence to evaluate.

7c · named coordination lead 14 / 20

Babylon Labs is named coordination lead. Co-founder David Tse (Stanford EE professor) is publicly named. Babylon Foundation operates the foundation governance arm.

7d · adversarial coordination precedent 6 / 20

No adversarial-pressure coordination event in Babylon's short history.

7e · canary tripwire mechanism 0 / 20

No published rate-limit canary, no cryptographic tripwire, no Hourglass-equivalent. EOTS double-vote slashing is a behavioral tripwire for finality-provider equivocation, not a quantum-forge canary.

X + Y vs Z, when does the math turn against you?

v3.1 demotes the X+Y vs Z timing test to a secondary signal, the headline output is Migration Stage. The timing test still answers the question: can this chain finish migrating before the threat lands?

X, signature shelf life

5–15 years

Y, migration time

8–12 years to Stage 5

Z10 (10% CRQC year)

2030

Z25 (25% CRQC year)

2035

Verdict

X+Y reaches 2034–2043, fully Outside risk window (vs Z25 2035) and Crisis Zone (vs Z10 2030)

Z-compliance

Outside NIST 2030 deprecation window (all signing primitives are classical: Ed25519, BLS12-381, Schnorr-secp256k1)

Source-disagreement disclosure

v3.1 requires every chain card to publish material divergences among authoritative sources, plus the delta-QRI under alternative weighting.

Babylon's primitive inventory

No material source disagreement. Babylon Labs documentation, the babylonlabs-io/babylon GitHub repository, the covenant-emulator repository, and Zellic audit reports all converge on the same primitive set: Ed25519 (CometBFT consensus), BLS12-381 (checkpoint aggregation), Schnorr/BIP340 (BTC staking), EOTS (finality votes), SHA-256 (hashing).