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

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 Coinbase, 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).