Babylon Protocol
BTC restaking protocol enabling self-custodial Bitcoin staking via Taproot covenant scripts on Bitcoin mainnet, with a companion Cosmos SDK L1 (Babylon Genesis, chain-id bbn-1) serving as the accounting layer for BTC delegations, finality provider registry, and Bitcoin-secured network (BSN) provisioning. BTC stays on Bitcoin (locked in P2TR UTXOs); slashing is enforced via EOTS (Extractable One-Time Signatures) which expose finality provider private keys upon double-signing, enabling on-Bitcoin slashing. Covenant committee (6-of-9 federated multisig) co-signs unbonding transactions during Phase-2 covenant emulation period. Largest BTC DeFi protocol by TVL ($4.16B, 100% Bitcoin). Phase-1 launched August 22, 2024; Phase-2 / Genesis chain launched April 10, 2025.
DeploymentsBitcoin · $4.2B
01
Risk profile at a glance
0 red · 3 yellow · 10 green 02
Categories & evidence
184 factors · 13 categoriesCode & audits Green 15 25 of 25
RD-F-002 yellow Audit recency Most recent publicly confirmed full-scope audits: Oak Security GmbH and Informal Systems (V2 upgrade, June 2025) — approximately 10 months before assessment date. Genesis chain now at v4.2.7 (April 2026). V4 upgrade audit reports (Coinspect, Halborn, Oak Security) referenced on audit page but PDFs not publicly located. 10-month gap is within defensible range but approaching 12-month threshold for $4B+ protocol. RD-F-003 yellow Resolved-without-proof findings Zellic 2025 Genesis Chain audit: 32 findings (7 critical) — stated 'all resolved or acknowledged' but individual resolution commits for the 7 critical findings are not individually verifiable from accessible public secondary sources (PDF binary-encoded). OZ April 2026 findings: all 4 confirmed fixed (PR #584 jailing bypass, PR #1911 type assertion, plus 2 additional fixes per OZ blog). Informal Systems V2: 14 findings, all addressed. No 'Resolved' label without code change detected in accessible evidence. RD-F-007 yellow Bug bounty presence & max payout Active Immunefi bug bounty since September 2024. Maximum payout $500,000 (Critical). Covers 17 assets including Genesis chain, Bitcoin Indexer, Finality Provider, Vigilante, Covenant Emulator. KYC required. Notable exclusion: centralization risks and covenant committee compromise explicitly out of scope. $500K max is below peer expectation for $4.16B TVL. RD-F-024 yellow Code complexity vs audit coverage Babylon's codebase is substantially complex: 5+ custom Cosmos SDK modules, EOTS cryptographic primitives, CosmWasm BSN contracts, and off-chain components (vigilante, covenant-emulator, finality-provider). Zellic 2025 audit required 23.5 person-weeks (5 consultants, 10 calendar weeks) and found 7 critical findings — direct evidence that complexity has exceeded single-round audit coverage. CosmWasm BSN contracts appear to have no public audit despite being a live production deployment since September 2025. RD-F-183 yellow Bug bounty scope gap on highest-TVL contracts Immunefi program explicitly excludes 'centralization risks' and 'covenant committee compromise scenarios' from scope. The covenant committee (6-of-9 federated multisig) co-signs all BTC unbonding transactions and is the primary security primitive protecting $4.16B in staked BTC. Its explicit exclusion from bug bounty scope creates a meaningful protection gap for the protocol's highest-value surface. cosmos-bsn-contracts not clearly enumerated as in-scope assets. RD-F-009 gray Formal verification coverage No formal verification (Certora, TLA+, Kani, Coq) has been applied to Babylon's custom modules (x/btcstaking, x/finality, EOTS) from publicly available sources. Informal Systems uses formal analysis techniques but their V2 audit was a security audit, not a machine-verified FV proof engagement. Novel cryptographic primitives (EOTS, covenant committee Schnorr multisig) would benefit most from FV. No Certora/Kani proofs publicly available. RD-F-010 gray Static-analyzer high-severity count Primary codebase is Go (Genesis chain) and Rust (CosmWasm contracts). Standard DeFi static analyzers (Slither, Mythril) do not apply. Go-specific tools (staticcheck, gosec) and Rust tools (cargo-audit) are standard CI but no published automated tool-run output found for Babylon's custom modules. Zellic and Coinspect audits performed manual security review as substitute. Tool run not performed in this assessment. RD-F-011 n/a SELFDESTRUCT reachable from non-admin path SELFDESTRUCT opcode is an EVM Solidity construct. Babylon's execution environments (Bitcoin script, Cosmos SDK Go modules, CosmWasm Rust) have no equivalent. Bitcoin UTXOs can only be spent via valid script paths. Cosmos SDK modules persist via the KV store. CosmWasm contracts can be halted/migrated by admin but have no self-destruct equivalent. RD-F-012 n/a delegatecall with user-controlled target EVM delegatecall opcode does not exist in Go (Cosmos SDK) or Rust (CosmWasm) execution contexts. Factor is structurally inapplicable. The analogous CosmWasm SubMsg pattern uses typed Rust messages, not arbitrary calldata. No evidence of uncontrolled SubMsg with user-supplied contract addresses in cosmos-bsn-contracts. RD-F-013 n/a Arbitrary call with user-controlled target EVM arbitrary .call(target, data) pattern does not exist in Go/Rust contexts. Cosmos SDK uses MsgServer interfaces for inter-module calls. CosmWasm uses typed Rust enum messages. Babylon's Genesis chain has permissioned CosmWasm deployment (not permissionless), further limiting arbitrary contract invocation surfaces. RD-F-014 n/a Reentrancy guard on external-calling functions EVM-style reentrancy (callback-based re-entry before state commit) does not apply to Cosmos SDK Go execution model (atomic transaction processing, state commits after full handler completion) or CosmWasm (VM-level reentrancy guard in reply pattern). Factor as defined is structurally inapplicable. RD-F-015 n/a ERC-777/1155/721 hook without reentrancy guard ERC-777/ERC-1155/ERC-721 token standards do not exist in Cosmos SDK / CosmWasm ecosystem. BABY token is a native Cosmos denomination (ubbn). BTC is not tokenized. Factor structurally inapplicable. RD-F-016 gray Divide-before-multiply pattern Slither divide-before-multiply detector applies to Solidity only. Babylon is Go and Rust. The factor concept (integer arithmetic precision) applies to Go but no Go-specific published analysis found. Manual review of x/finality voting power calculations and x/btcstaking satoshi-denomination arithmetic would be required. No published finding on this topic from Zellic/Coinspect audits found. RD-F-018 n/a Signed/unsigned arithmetic confusion Signed/unsigned confusion is a Solidity-specific class of vulnerability (implicit type conversions). Babylon Genesis chain uses Go (strict explicit conversion required) and Cosmos SDK math.Int wrapper for token amounts. CosmWasm contracts use Rust (strict type system, no implicit conversions). The vulnerability class does not exist in this toolchain. Structural N/A by non-Solidity substrate. RD-F-019 n/a ecrecover zero-address return unchecked ecrecover is an EVM precompile for ECDSA signature recovery. Babylon uses Schnorr signatures (BIP-340) for Bitcoin operations, Cosmos SDK amino/protobuf signing for Genesis chain, and EOTS for finality provider double-sign detection. No ecrecover usage exists in this non-EVM architecture. RD-F-020 n/a EIP-712 domain separator missing chainId EIP-712 is an Ethereum structured-data signing standard. Babylon does not use EIP-712 anywhere. Bitcoin-side signing uses Taproot (BIP-341). Genesis chain uses Cosmos SDK SIGN_MODE_DIRECT which includes chain-ID (bbn-1) in the SignDoc by construction. Structurally inapplicable. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned UUPS (EIP-1822) is an EVM proxy upgrade pattern. Babylon has no EVM contracts. Chain upgrades on Genesis proceed via Cosmos SDK x/gov software upgrade proposals — a governance vote is required before the upgrade handler executes. Structurally inapplicable. RD-F-022 n/a Public initialize() without initializer modifier Cosmos SDK modules use InitGenesis() for initial state setup, callable only at chain genesis block. CosmWasm contracts use instantiate() enforced as single-call by the CosmWasm VM. No Solidity initialize() pattern exists in this architecture. Structurally inapplicable. RD-F-023 n/a Constructor calls _disableInitializers() OZ _disableInitializers() is an EVM Solidity pattern for upgradeable proxy impl contracts. Babylon has no EVM contracts. Cosmos SDK genesis initialization is structurally protected at the framework level. CosmWasm initialization semantics are enforced at VM level. Structurally inapplicable.
RD-F-001 green Audit scope mismatch Seven audit engagements span Phase-1 through V2 upgrade. OpenZeppelin April 2026 research found 4 live vulnerabilities — all confirmed fixed with merged PRs (#584, #1911, plus 2 additional fixes confirmed by OZ blog). V4 upgrade audited by Coinspect, Halborn, Oak Security (reports not publicly located but referenced on audit docs page). No deployed module revision with zero audit coverage confirmed.
RD-F-004 green Audit count Six distinct organizations with confirmed security coverage: Coinspect (Phase-1 + Phase-2 + V4), Zellic (Phase-1 + Phase-2 Genesis Chain), Sherlock (Phase-1 competitive), Oak Security GmbH (V2 upgrade), Informal Systems (V2 upgrade), OpenZeppelin (independent research April 2026). Halborn listed for V4 + frontend. CosmWasm BSN contracts have no publicly confirmed separate audit — this is the one gap. For $4.16B TVL, 5-6 confirmed firms is strong multi-party coverage for the Cosmos ecosystem.
RD-F-005 green Audit firm tier Audit firm tier: Zellic (Tier-1, Genesis covenant committee member), Informal Systems (Tier-1, CometBFT/IBC specification authors), OpenZeppelin (Tier-1, top-3 global smart contract security firm), Coinspect (Tier-2 Cosmos specialist), Oak Security GmbH (Tier-2 Cosmos specialist), Sherlock (competitive platform). Strong top-tier presence appropriate for novel BTC restaking cryptography.
RD-F-006 green Audit-to-deploy gap Phase-1: Coinspect report Aug 5 2024, mainnet Aug 22 2024 — 17-day gap (excellent). Zellic Phase-1 ended May 31 2024, Phase-1 launch Aug 22 2024 — 83 days (at margin but acceptable). Genesis chain: Coinspect/Zellic Phase-2 completed Feb–Mar 2025; Genesis launched April 10 2025 — 38–59-day gap (within threshold). No >90-day drift detected for confirmed deployments.
RD-F-008 green Ignored bounty disclosure No evidence of a disclosed vulnerability being ignored before exploitation. OZ April 2026 disclosure was handled via direct outreach and confirmed/fixed promptly. SECURITY.md documents 48-hour acknowledgement commitment. Rekt database shows zero incidents. Data cache hacks field empty.
RD-F-017 green Mixed-decimals math without explicit scaling BABY token uses ubbn (6 decimal places). BTC amounts are in satoshis (8 decimals). Modules handle denominations separately (x/btcstaking in satoshis, x/incentive in ubbn). No cross-denomination arithmetic without explicit conversion evident from module architecture. No published audit finding on mixed-decimals issue.
Governance & admin Yellow 23 24 of 24
RD-F-047 red Governance token concentration (Gini) Foundation holds 36% of BABY supply (18% R&D/Ops + 18% Ecosystem Building, significant portion unlocked). Investors hold 30.5% (first cliff April 2026, 12.5% of allocation = ~381M unlocked). Team 15% (first cliff April 2026). Circulating supply ~3.08B / 10B = 30.8% as of May 2026. Community incentives (15% = 1.5B) managed by Foundation. Foundation + investors + team = 66.5% of total supply with majority of governance voting power concentrated in insiders in Year 1. Effective Gini coefficient equivalent >0.85 (top insiders control well over 50% of bonded BABY). RED by structural allocation data. RD-F-026 yellow Upgrade multisig signer configuration (M/N) BABY governance: DAO model (no fixed M/N threshold; voting power = bonded BABY stake). Covenant committee (Bitcoin layer): 6-of-9 threshold, confirmed from global-params.json (covenantQuorum=6, 9 public keys). Phase-1/2 composition: AltLayer 1 key, Babylon Labs 3 keys, CoinSummer 1 key, Cubist 1 key, Informal Systems 1 key, RockX 1 key, Zellic 1 key. Babylon Labs holds 33.3% of committee keys — below 6-of-9 threshold alone but concentration notable at $4.16B TVL. RD-F-028 yellow Low-threshold multisig vs TVL Covenant committee (Bitcoin-layer analog to admin multisig) is 6-of-9 with Babylon Labs holding 3/9 keys (33.3%). Babylon Labs alone cannot reach threshold (needs 6), but Babylon Labs + any 3 others = threshold. At $4.16B TVL, this concentration is notable — below peer norm for comparable TVL tier. Covenant committee cannot steal BTC (only co-signs unbonding) but could co-sign unauthorized unbonding if compromised. BABY governance is DAO-level with no fixed signer set. RD-F-029 yellow Multisig signers co-hosted Covenant committee: 7 distinct organizations. Babylon Labs holds 3/9 keys — organizational co-hosting risk within Babylon Labs is inherent. Other 6 keys distributed across 6 independent organizations (AltLayer, CoinSummer, Cubist, Informal Systems, RockX, Zellic). ASN-level infrastructure data for Bitcoin Schnorr key custodians not available. Partial independence confirmed by organizational diversity; within-org co-hosting for Babylon Labs 3 keys is a yellow finding. RD-F-032 yellow Timelock duration on upgrades No Ethereum TimelockController exists. Effective delay is the governance voting period: 3 days standard (72h) or 1 day expedited (24h). V2 upgrade used a 4-day window (proposal Jun 12 → activation Jun 16). V4 upgrade had 3-day voting period (Nov 10-13). 72h meets the green threshold (≥48h) for standard proposals, but expedited path allows 24h. Graded yellow: expedited path is structurally available and reduces effective timelock to 24h for certain proposals. RD-F-033 yellow Timelock on sensitive actions All sensitive actions (software upgrades, parameter changes, mint/inflation parameters, fee parameters) route through BABY governance module. No bypass path for normal operations. However: (a) no separate timelock delay after voting ends — execution is at the specified block height immediately after vote passes; (b) expedited proposals reduce delay to 24h with higher threshold (66.7%). No rescue/emergency function exists (structurally inapplicable). Oracle not applicable (no price oracle). Governance covers all actions but expedited path reduces delay. RD-F-038 yellow Proposal execution delay < 24h Standard proposals: 3-day voting period = 72h. Expedited proposals: 1-day voting period = 24h. Standard path meets the green threshold (≥48h). Expedited path (24h) is at the exact yellow/green boundary (24-47h = yellow). Graded yellow because the expedited path (24h) is explicitly available and structurally accessible for time-sensitive proposals with higher approval threshold (66.7%). RD-F-040 yellow Emergency-veto multisig present Cosmos SDK governance has NoWithVeto — if ≥33.4% of voting power votes NoWithVeto, proposal is rejected and deposit burned. This is an embedded veto mechanism within the voting period. However, there is no separate veto-only multisig entity. Effective veto requires organizing 33.4% of bonded BABY within 3 days. Foundation + investors hold ~66.5% of total supply; with first cliff passed (April 2026), insider concentration could theoretically pass or veto any proposal. Community veto depends on insider non-participation. RD-F-042 yellow Admin has mint() with unlimited max BABY inflation controlled by Cosmos SDK x/mint module; rate is 5.5% annually (reduced from 8% via Proposal #18, passed November 2025). Inflation parameter is governance-adjustable — a malicious governance majority could pass a proposal to increase it. No immutable hard-coded supply cap exists. However, changing inflation requires passing a governance vote (33.4% quorum + 50% threshold, 3-day window) — instant minting by an admin key is not possible. Governance-mediated inflation risk, not admin-key mint risk. RD-F-030 gray Hot-wallet signer flag Covenant committee signers hold compressed Schnorr public keys for Bitcoin co-signing — these are offline keys for a federated signing service, not EVM hot wallets. On-chain behavioral heuristics (nonce velocity, gas jitter) are inapplicable to Bitcoin Schnorr keys. BABY governance is DAO-level; individual validator signing behavior for governance is not equivalent to multisig hot-wallet risk. Insufficient data to assess; structurally different from EVM hot-wallet pattern. RD-F-034 gray Guardian/pause-keeper distinct from upgrader No EVM-style pause-keeper role identified. No equivalent to EigenLayer's Pauser Multisig found for Babylon Genesis. Chain halt would require 2/3+ validator consensus (Cosmos SDK crisis module). IBC rate-limiter (V2 upgrade) provides partial circuit-breaker for cross-chain outflows (10%/24h) but is not an admin-controlled pause. The concept of a guardian role distinct from the upgrader (governance) is architecturally absent in this pure on-chain governance model. RD-F-035 gray Role separation: upgrade ≠ fee ≠ oracle All role types (upgrade, fee parameters, oracle config) are governed by the same BABY governance module — no separate role holders. Oracle is not applicable (no price oracle in core protocol). Upgrade role = governance. Fee parameters changed via governance (Proposal #8 reduced unbonding fees). Role separation is structurally absent in a pure on-chain governance model without granular role contracts. Not a data gap — structural architecture of Cosmos SDK x/gov. RD-F-037 n/a Quorum achievable via single-entity flash loan Not applicable — BABY governance uses bonded stake (not liquid tokens). Flash loans cannot acquire bonded voting power in Cosmos SDK. The quorum concept applies to bonded BABY participation, not liquid token acquisition. No flash-loan quorum manipulation vector exists in this architecture. RD-F-041 gray Rescue/emergencyWithdraw without timelock Structurally inapplicable. Bitcoin Taproot UTXOs have no rescue/emergency function — BTC can only move via the defined script spending paths (timelock/unbonding/slashing) enforced by Bitcoin consensus. Cosmos SDK modules have no emergencyWithdraw function. The concept of an admin-callable drain function does not exist in this architecture. Not a data gap — architectural absence confirmed by open-source code review. RD-F-044 gray Admin wallet interacts with flagged addresses No EVM admin wallet exists. Covenant committee members hold Bitcoin Schnorr keys — their interaction history on Bitcoin is not equivalent to EVM wallet transaction history. Babylon Foundation holds BABY tokens in Cosmos SDK accounts, not monitorable EVM addresses. No Chainalysis-style feed data available for Bitcoin Schnorr keys or Cosmos-native accounts. Structural data gap for non-EVM architecture. RD-F-045 gray Constructor args match governance proposal Cosmos SDK upgrades use on-chain MsgSoftwareUpgrade proposals with declared upgrade height and plan JSON. V2 (Jun 12 proposal → Jun 16 activation) and V4 (Proposal #18, Nov 2025) both had on-chain proposals. However, independent verification of upgrade-plan-declared-binary vs. actually-deployed binary not performed at this tier. The Cosmos SDK upgrade mechanism is inherently transparent (on-chain proposal with version string), but binary hash attestation was not independently verified. RD-F-167 gray Deprecated contract paused but pause reversible by live admin No deprecated EVM contracts holding value. Phase-1 Bitcoin staking is on Bitcoin mainnet (Taproot UTXOs) — Phase-1 stakes are active user-controlled UTXOs awaiting unbonding. Bitcoin staking scripts don't have a pause function; they expire via Bitcoin timelocks. No deprecated-and-paused Cosmos SDK modules identified. Phase-1 BTC is not deprecated — it is in self-custodial UTXOs. The deprecated-paused-reversible concept is EVM-specific.
RD-F-025 green Admin key custody type Dual-layer governance: (a) BABY governance via Cosmos SDK x/gov — DAO model with 3-day voting period, 33.4% quorum, >50% threshold; no single admin key; (b) Bitcoin-layer: covenant committee 6-of-9 federated multisig for BTC unbonding co-signing. All software upgrades require on-chain governance vote (MsgSoftwareUpgrade). V2 upgrade (Jun 2025) and V4 upgrade (Nov 2025) both went through governance proposals confirmed by on-chain voting.
RD-F-027 green Single admin EOA No single EOA or private key holds unilateral chain upgrade authority. Babylon Genesis software upgrades require on-chain BABY governance vote (MsgSoftwareUpgrade). V2 upgrade (proposal Jun 12, 2025 → activation Jun 16) and V4 upgrade (Proposal #18, Nov 2025) both confirmed as governance-voted. No Cosmos SDK crisis module sudo-admin key identified. Babylon Foundation holds significant BABY supply but cannot unilaterally execute upgrades.
RD-F-031 green Signer rotation recency No covenant committee member removal or key rotation found in the 90 days prior to assessment (Feb 4 → May 4, 2026). Phase-1 and Phase-2 committee compositions are consistent per profiler. No governance announcement of committee change detected. No threshold reduction event. Stable committee composition since launch.
RD-F-036 green Flash-loanable voting weight Cosmos SDK x/gov uses bonded BABY (delegated to validators) as voting power, not spot token balance. Tokens must be bonded (staked/delegated) for voting power — requires the staking bonding period. Liquid BABY cannot be flash-loaned into governance voting weight in a single transaction. Voting power is determined by bonded delegation state at proposal creation block. No flash-loan vector identified in this architecture.
RD-F-039 green delegatecall/call in proposal execution without allowlist Cosmos SDK governance executes typed Protobuf messages through the module router (MsgUpdateParams, MsgSoftwareUpgrade, etc.). No EVM-style delegatecall or arbitrary call(target, calldata) in governance execution. Each proposal type maps to a typed handler routed to the relevant module keeper. No user-supplied target address, no delegatecall attack surface in Cosmos SDK governance architecture.
RD-F-043 green Admin = deployer EOA after 7 days Not applicable in the standard EVM sense. Babylon Genesis chain launched April 10, 2025 (~13 months ago). Chain was bootstrapped via genesis file — no deployer EOA persists as admin. Governance was operational from genesis day 0. No deployer-EOA admin pattern exists in Cosmos SDK architecture. Protocol is 13+ months old with DAO governance from inception.
RD-F-046 green Contract unverified on Etherscan/Sourcify Etherscan/Sourcify is EVM-specific and structurally inapplicable. Babylon Genesis is Cosmos SDK — all source code is public Go on GitHub (https://github.com/babylonlabs-io/babylon). Audited by Coinspect, Zellic, Informal Systems, Oak Security, Halborn (multiple public PDFs available). CosmWasm contracts are public Rust (cosmos-bsn-contracts repo). No closed-source binary for core modules. Protocol was not deployed with hidden contracts. Equivalent of 'verified source' is fully met.
Oracle & external dependencies Green 17 17 of 17
RD-F-049 yellow Oracle role per asset No price oracle role for any asset. BTC light client (x/btclightclient) functions as a liveness dependency — tracks Bitcoin header state for validating staking registrations. Covenant committee (6-of-9 Schnorr multisig) is a liveness dependency for unbonding. Both are liveness risks, not oracle price risks. Vigilante relay stall would block delegation updates. RD-F-051 yellow Fallback behavior on oracle failure No price oracle to fail. Liveness dependency fallbacks: vigilante relay failure requires manual spinup of new vigilante (permissionless but not automatic); IBC relay failure has IBC packet timeout (revert) but no automatic re-routing to secondary relayer documented; covenant committee quorum failure has no documented fallback — unbonding halts if fewer than 6/9 keys available. No automated protocol-level fallback for any liveness dependency. RD-F-062 yellow External keeper/relayer not redundant Vigilante relayer is the external keeper analog for BTC header relay. Permissionless mitigation: any operator can run a vigilante instance and submit valid BTC headers via MsgInsertHeaders. However no on-chain registry of active vigilante operators found; in practice relayer set is small and operator composition is not publicly enumerated. IBC relayers for BSN coordination are similarly permissionless but unregistered. Gap: cannot confirm multi-party vigilante operation from available public data. RD-F-053 n/a Oracle source = spot DEX pool (no TWAP) Structurally inapplicable. Babylon does not use a DEX spot price oracle for any protocol function. Protocol is BTC restaking (not swap, AMM, or lending). No slot0(), getReserves(), or any DEX price call in any Genesis chain module. Data cache confirms oracle_feeds: []. RD-F-054 n/a TWAP window duration No TWAP oracle used — no DEX price oracle exists in the protocol. RD-F-055 n/a Oracle pool depth (USD) No DEX pool oracle — F055 inapplicable. RD-F-056 n/a Single-pool oracle (no medianization) No price oracle — no pool, no medianization question. F056 inapplicable. RD-F-057 n/a Circuit breaker on price deviation No price oracle exists; no price-deviation circuit breaker applicable. x/finality EOTS slashing and x/btclightclient fork resolution are consensus safety mechanisms, not price circuit breakers. RD-F-058 n/a Max-deviation threshold (bps) No price-deviation circuit breaker because no price oracle. F058 inapplicable. RD-F-059 n/a Oracle staleness check present No Chainlink latestRoundData() or Pyth staleness check pattern in any Genesis module. x/btclightclient uses Bitcoin block height (PoW) for freshness, not an EVM-style updatedAt staleness check. RD-F-060 n/a Chainlink aggregator min/max bound misconfig Babylon does not use Chainlink for any protocol function. Data cache oracle_feeds: []. RD-F-061 n/a LP token balanceOf used for pricing Babylon is not a lending protocol. No LP token pricing. F061 inapplicable. RD-F-180 n/a Immutable oracle address Structurally inapplicable. Babylon's core protocol has NO oracle address — immutable, hardcoded, or otherwise — because it consumes no external price feed whatsoever. Data cache confirms oracle: null, oracle_feeds: []. x/btcstaking, x/finality, x/btclightclient import no oracle interfaces. CosmWasm BSN contracts show no identified oracle imports. This is the canonical 'zero oracle surface' N/A case for F180 — distinct from Wormhole (peripheral oracle not in critical path) and Hyperliquid (RED closed-source binary oracle). NOTE FOR T-14: F180 not_applicable (no oracle at all) — does not contribute to ★ critical red count. RD-F-181 n/a Permissionless-pool lending oracle Babylon is not a lending protocol. No permissionless pool lending oracle pattern. F181 inapplicable.
RD-F-048 green Oracle providers used No external oracle providers used. x/btcstaking, x/finality, x/btclightclient, and x/checkpointing modules import no Chainlink, Pyth, Band, or any price feed interface. Data cache confirms oracle: null, oracle_feeds: []. BTC amounts denominated in satoshis (Bitcoin consensus). BABY inflation is a fixed Cosmos SDK parameter (5.5% annual).
RD-F-050 green Dependency graph (protocols depended upon) External dependencies: Bitcoin mainnet consensus (failure impossible by definition), vigilante relayer(s) for BTC header relay (permissionless — any operator can run), IBC relayer(s) for Genesis-BSN coordination (open IBC protocol), covenant committee (6-of-9 off-chain signing service). No Aave, Uniswap, Chainlink, or DeFi protocol dependencies. CosmWasm BSN contracts show no identified external protocol calls.
RD-F-052 green Breakage analysis per dependency Breakage analysis per dependency completed: Bitcoin mainnet failure — all TVL irrecoverable (practically impossible); vigilante halt — BTC light client stalls, stake registrations blocked, permissionless mitigation (any operator can resume); covenant quorum failure — unbonding freezes, protocol upgrade path via governance; IBC relay failure — BSN finality signals stop, affects BSN security not BTC staker funds; covenant compromise (below quorum) — cannot steal BTC, script paths enforce valid spending only.
Economic risk Yellow 22 13 of 13
RD-F-064 yellow TVL concentration (top-10 wallet share) Top-10 BTC delegator wallet concentration is not quantifiable — Bitcoin Taproot UTXOs cannot be scanned via standard EVM/DeFi tooling (Dune Analytics, DefiLlama wallet scan). Structural concentration is qualitatively high: institutional LRT protocols (Lombard LBTC, Lorenzo Protocol) likely route large BTC positions to specific finality providers. 60 active FPs at Phase-2 launch vs 250+ registered; delegation concentration across FPs unknown. Yellow for evidence gap and qualitative concentration risk. RD-F-065 yellow Liquidity depth per major asset DEX slippage depth metric is inapplicable. The analogous exit liquidity constraint is the BTC unbonding queue: (1) covenant-assisted fast path requires staker + covenant 6-of-9 co-signature and BTC block confirmation; (2) slow timelock path requires waiting for script-encoded timelock expiry; (3) no immediate secondary market at protocol layer for Phase-2 BTC staking positions. LRT derivatives (Lombard LBTC, Lorenzo) provide off-protocol secondary liquidity. Yellow: withdrawal is multi-day to multi-week, there is no instant redemption, and simultaneous mass unbonding would queue against covenant committee co-signing capacity. RD-F-066 n/a Utilization rate (lending protocols) Babylon is not a lending protocol. No borrow markets exist. lending_protocol: false in data cache. Taxonomy PD-024: utilization rate is lending-only, N/A for non-lending protocols. RD-F-067 n/a Historical bad-debt events No lending markets; no bad debt possible in the lending sense. Zero financial exploits recorded. Rekt database: zero incidents. Slashing events (0.1% BTC burn upon FP equivocation) are by-design, not lender-socialized bad debt. Taxonomy PD-024: bad debt events is lending-only. RD-F-068 n/a Collateralization under stress Babylon is not a collateralized lending protocol. BTC stakers do not borrow against restaked positions. No LTV, no undercollateralization risk. Taxonomy PD-024: collateralization ratio is lending-only. RD-F-069 n/a Algorithmic / under-collateralized stablecoin Babylon does not issue a stablecoin. BABY is a native Cosmos PoS governance/staking token with defined inflation schedule. No algorithmic or under-collateralized stablecoin design anywhere in the protocol. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) NOT APPLICABLE — N/A by construction. Babylon is not a Compound V2 fork. No cToken-style markets, no totalSupply()==0 empty-market conditions, no ERC-4626 share accounting. BTC is locked in Bitcoin Taproot UTXO scripts; Genesis chain uses Cosmos SDK x/btcstaking module (delegation registry, not share minting). The classic donation-attack / share-inflation vector does not exist. ★ critical factor does not fire. Taxonomy PD-024: Compound-fork-only factor. RD-F-071 n/a Seed-deposit requirement for new market listing No lending markets. Babylon's BSN onboarding does not involve a seed deposit into a market. Taxonomy PD-024: seed-deposit requirement is lending-only. RD-F-072 n/a Market-listing governance threshold No lending markets. BSN onboarding governance is a Cat 2 matter (BABY on-chain governance vote for BSN integration parameters), not a Cat 4 market-listing governance threshold question. Taxonomy PD-024: market-listing governance threshold is lending-only. RD-F-073 n/a Oracle-manipulation-proof borrow cap No borrow markets; no oracle price dependency in core protocol. Babylon does not use external price oracles for staking parameters. data cache confirms oracle: null, oracle_feeds: []. Taxonomy PD-024: oracle-proof borrow cap is lending-only. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) Babylon uses Bitcoin Taproot UTXO accounting (Bitcoin mainnet) and Cosmos SDK module accounting (Genesis chain). No ERC-4626 vaults exist anywhere in the core protocol. Virtual-share offset is an EVM/Solidity/OpenZeppelin pattern inapplicable to this architecture. data cache: non_evm_substrate: true. Taxonomy PD-024: ERC-4626 offset is lending-only. RD-F-075 n/a First-depositor / share-inflation guard Each BTC stake in Babylon is a discrete, independent Taproot UTXO on Bitcoin mainnet. There is no share pool, no cumulative totalAssets() call, and no first-depositor mechanism. The Cosmos SDK x/btcstaking module tracks delegation accounting natively — no ERC-4626 share arithmetic is involved. The canonical first-depositor inflation attack vector (share minting on zero-totalSupply) does not exist in this architecture. Taxonomy PD-024: first-depositor guard is lending-only.
RD-F-063 green TVL (current + 30d trend) $4,164,228,121 TVL (100% BTC, Bitcoin mainnet Taproot UTXOs). +18.79% 30-day trend; +2.38% 1-day. 12-month peak ~$7.3B (Q4 2024). TVL far exceeds $100M threshold. Yellow narrative flag: 100% single-asset BTC concentration means USD TVL tracks BTC price with ~1:1 correlation; BSN revenue contribution not yet independently quantified. Scored green at current absolute scale.
Operational history Green 17 15 of 15
RD-F-089 red Insurance coverage active No active insurance coverage confirmed for $4.16B TVL. Nexus Mutual partnership announced 2025-04-28 for slashing protection development, but the product was described as still 'in development' at announcement — not live/purchasable. Nexus Mutual 20+ new cover listings page does not include Babylon. No Sherlock, Unslashed, or equivalent coverage found. To reach 5% green threshold, coverage would need to exceed $208M — substantially beyond typical Nexus Mutual single-protocol capacity. Red = no active coverage at $4.16B TVL. This is a structural gap for Bitcoin-native staking protocols on non-EVM infrastructure. RD-F-084 yellow TVL stability (CoV over 90d) Direct DefiLlama daily TVL series unavailable (403 persistent). Estimation from accessible data: current $4.16B, 30-day ago ~$3.50B (+18.79%), Q2 2025 ~$4.9B, peak ~$7.1B. TVL is 100% BTC-denominated; variance is largely BTC/USD price driven, not protocol-level instability. No TVL cliff events (no drain/exploit). Estimated 90-day CoV likely in yellow range (0.15–0.35) due to BTC price volatility. Underlying BTC quantity staked is more stable than USD-denominated figure. Medium confidence — full daily series unavailable. RD-F-081 gray Post-exploit response score No prior financial exploits. Factor is N/A per rubric (gray = no prior incidents). The OpenZeppelin 2026-04-01 disclosure and GHSA advisories were vulnerability disclosures with $0 loss, not exploits requiring a post-exploit response score. RD-F-082 gray Post-mortem published within 30 days No prior financial exploits. Factor is N/A per rubric (gray = no prior incidents). No post-mortem required. RD-F-083 gray Auditor re-engaged after last exploit No prior financial exploits. Factor is N/A per rubric (gray = no prior exploits). Note: multiple proactive audits were conducted before exploits occurred (Coinspect, Zellic, Sherlock, Informal Systems, Halborn — see code-security-analyst for F139). RD-F-085 gray Incident response time (minutes) No prior financial exploits. Factor is N/A per rubric (gray = no prior incidents). No incident response time to measure. RD-F-086 gray Pause activations (trailing 12 months) Non-EVM architecture. Bitcoin UTXO-based staking has no protocol-level pause mechanism — staker UTXOs are self-sovereign. Cosmos SDK Genesis chain has no EVM Paused/Unpaused event pattern. No Cosmos SDK emergency chain halts occurred in trailing 12 months. Gray = protocol has no standard EVM pause mechanism. RD-F-087 gray Pause > 7 consecutive days No pause events exist for Babylon (see F086). Gray = no pause events in last 12 months per rubric. The protocol architecture has no EVM-style pause mechanism. RD-F-166 gray Deprecated contracts still holding value Non-EVM architecture. Babylon operates entirely on Bitcoin UTXOs (user-owned, self-custodial Taproot outputs) and Cosmos SDK native modules. There are no EVM singleton smart contracts to deprecate. The EVM contract-deprecation model (singleton address, on-chain deprecated() state, ERC-20 allowances) is architecturally inapplicable. Phase-1 BTC staking UTXOs are not 'deprecated' — they remain spendable by users via timelock/unbonding paths. Genesis chain upgrades (V2, V4) were in-place state migrations, not deprecated contract redeployments. Coverage flag has_legacy_v1: true reflects phase transition, not EVM contract deprecation.
RD-F-076 green Protocol age (days) Phase-1 BTC staking layer live since 2024-08-22 (~621 days to assessment date). Genesis chain live since 2025-04-10 (~389 days). Primary TVL-bearing surface (Phase-1 Bitcoin UTXOs) clears 365-day threshold. Both layers exceed the minimum green threshold.
RD-F-077 green Prior exploit count Zero prior exploits found. Proprietary hacksdatabase grep returned 0 matches for 'babylon', 'babylonlabs', 'covenant', 'EOTS', 'BTC restaking'. Data cache rekt.incidents is empty. DefiLlama hacks field is empty. No financial loss events in any searched source.
RD-F-078 green Chronic-exploit flag (≥3 incidents) Incident count from F077 is 0. Chronic-exploit threshold (≥3) is not reached. Green by construction.
RD-F-079 green Same-root-cause repeat exploit Zero incidents from F077 search. No root-cause cluster can form from 0 incidents. Green by construction.
RD-F-080 green Days since last exploit No prior incidents; rubric maps 'no incidents' to green (same as >365 days since last exploit). The protocol has been live for 621 days (Phase-1) with zero loss events.
RD-F-088 green Re-deployed to new addresses in last year No full redeployment to new addresses occurred in last 12 months. Genesis chain V2 upgrade (executed 2025-06-16) and V4 upgrade (executed 2025-Q4) were in-place Cosmos SDK software upgrades via governance proposals — not redeployments to new contract addresses. Bitcoin UTXO model has no singleton contract address to redeploy. Green = no full redeployment in last 12 months.
Real-time signals Green 4 22 of 22
RD-F-109 yellow Social-media impersonation scam spike Babylon Labs official X account (@babylonlabs_io) was compromised in January 2025. Phishing links were posted; account recovered within 6 hours (locked within 2 hours with help from @brainchainLLC). Financial impact minimal (0.00010895 BTC to phishing wallet). No ongoing coordinated impersonation campaign (≥5 accounts) detected. Yellow (not red) because: single account takeover (not ≥5 simultaneous), minimal losses, quickly contained. High-profile BTC brand remains elevated target. RD-F-090 gray Mixer withdrawal → protocol interaction CTI feed required for this signal. Tornado Cash (ETH-based mixer) has no interaction surface with Babylon's Bitcoin UTXO architecture or Cosmos SDK Genesis chain. Bitcoin CoinJoin privacy usage is structurally different and would require Bitcoin-specific chain analysis (not configured). No public intelligence of mixer-funded wallets interacting with Babylon staking. Signal inapplicable in EVM mixer form for non-EVM BTC-native protocol. RD-F-092 gray Unusual mempool pattern from deployer wallet No EVM deployer address exists (data cache deployer.address: null). Bitcoin staking scripts are user-generated UTXOs, not deployable from a single wallet. Genesis chain upgrades use Cosmos SDK on-chain governance proposals, not deployer-EOA transactions. Deployer wallet monitoring concept does not apply to Babylon's non-EVM architecture. Signal structurally inapplicable. RD-F-093 gray Abnormal gas-price willingness from attacker wallet Babylon has no EVM contracts and no EVM transaction fee surface. Bitcoin uses satoshi-per-vbyte fee rates; Cosmos SDK uses BABY gas fees. Neither maps to EVM gas priority fee signals. Structurally inapplicable for non-EVM architecture. Mempool monitoring not configured. RD-F-095 gray Known-exploit function-selector replay Babylon has no EVM function selectors. Cosmos SDK transactions use typed message types (e.g., MsgBTCDelegate, MsgAddFinalitySig), not Ethereum ABI function selectors. Selector pattern index cannot be maintained for Cosmos SDK / Bitcoin architecture. Signal mechanism structurally inapplicable. RD-F-096 n/a New ERC-20 approval to unverified contract from whale Babylon's TVL is in Bitcoin UTXOs on Bitcoin mainnet — no ERC-20 tokens, no Approve() function, no EVM whale approval surface. BABY is a Cosmos SDK native denomination (ubbn), not an ERC-20. Structurally inapplicable by design. RD-F-097 gray Sybil surge of identical-pattern transactions Babylon Genesis uses BABY wallets (bech32 addresses), not Ethereum EOAs. April 2025 unstaking involved 4 institutional wallets (not a sybil pattern). No Cosmos-compatible transaction clustering algorithm deployed. Sybil detection mechanism requires adaptation for Cosmos SDK architecture. RD-F-099 n/a Oracle price deviation >X% from secondary Babylon has no external price oracle by design (data cache oracle: null, oracle_feeds: []). BTC staking amounts are in satoshis; slashing is predetermined by the script (33.33%); BABY inflation is fixed at 5.5% annually. No oracle price deviation signal is applicable. Confirmed not_applicable per oracle-dependency analyst scope. RD-F-100 n/a Flash loan >$10M targeting protocol tokens Babylon has no EVM flash-loan surface. BABY is a Cosmos SDK native token that cannot be flash-loaned from Aave/Uniswap/Balancer. Cosmos SDK x/gov governance requires 50,000 BABY minimum deposit and 3-day voting period — single-block flash-loan governance attack structurally impossible. Not applicable by architecture. RD-F-102 gray Admin/upgrade transaction in mempool Babylon Genesis chain upgrades execute via Cosmos SDK x/gov software upgrade proposals — not EVM admin transactions in mempool. No EVM mempool to monitor. Cosmos SDK upgrade path: proposal → voting period (3 days) → validator coordination → upgrade at specified block height. No admin-EOA-in-mempool pattern applicable. Signal structurally inapplicable in EVM form. RD-F-104 n/a Stablecoin depeg >2% on shared-LP venue Babylon has zero stablecoin exposure. TVL is 100% BTC locked in Bitcoin Taproot UTXOs. No stablecoin collateral, no stablecoin LP, no shared-LP venue with stablecoins in dependency graph. BABY token is governance token, not stablecoin. Factor not applicable by TVL composition. RD-F-106 n/a Cross-chain bridge unverified mint pattern Babylon is not a token bridge and does not mint wrapped assets. BTC does not leave Bitcoin — no source-chain deposit + destination-chain mint pattern exists. Vigilante relayers submit BTC header data (not asset-transfer proofs) to Genesis chain. No canonical bridge contract exists. Structurally inapplicable. RD-F-107 gray Admin EOA signing from new geography/device Off-chain signing telemetry requires team opt-in — not available. Covenant committee members sign via HSM/MPC (Cubist CubeSigner is one member). No admin EOA signing telemetry accessible. Per template, this signal is practically always gray without explicit team integration. Structurally gray. RD-F-182 n/a Security-Council threshold reduction (RT) Babylon has no Gnosis Safe / Security Council multisig (data cache safe_multisigs: []). No EVM ChangedThreshold/RemovedOwner/AddedOwner events applicable. The closest analog (Covenant Committee 6-of-9) is an off-chain signing quorum, not an EVM Safe contract — threshold reduction events cannot be detected via EVM event subscriptions. Cosmos SDK x/gov upgrades do not have a Security Council pattern. Structurally inapplicable.
RD-F-091 green Partial-drain test transactions No partial-drain test transactions detected. April 2025 TVL drop 32% was a pre-announced Lombard finality provider transition (not a drain pattern). Rekt database shows zero incidents for Babylon. Bitcoin UTXO architecture means test transactions are structurally distinct from EVM call-sequence pre-drain patterns. Hack database grep returns zero results for babylon/babylonlabs.
RD-F-094 green New contract with similar bytecode to exploit template Babylon has no EVM contracts to replicate. Bitcoin staking script (Taproot P2TR) is a published novel architecture with no known exploit templates. No copycat exploit contracts detected. Hack database shows zero Babylon incidents. BTC-restaking is a novel protocol class with no exploit-template index maintained.
RD-F-098 green TVL anomaly — % drop in <1h Current TVL $4.16B with +2.38% 1-day and +18.79% 30-day trend — no anomalous drop. Historical April 2025 32% drop (Lombard transition) would have triggered the threshold but is suppressed by T-09 §4.1 suppression rule (a): pre-announced event. Lombard publicly stated the withdrawal was a planned finality provider transition. Signal not firing today.
RD-F-101 green Large governance proposal queued Babylon Genesis on-chain governance (Cosmos SDK x/gov) has processed 20+ proposals as of May 2026. Recent proposals are routine: CosmWasm whitelisting (Tower, Interchain Labs, Union, Persistence Labs, SatLayer), fee parameter updates (unbonding fee 30 sats/vbyte via Proposal #8), software upgrades. No anomalous admin-role change, threshold reduction, or unauthorized privileged payload detected. Flash-loan governance attack not possible on Cosmos SDK.
RD-F-103 green Bridge signer-set change proposed/executed Babylon's functional analog to bridge signer-set is the Covenant Committee (6-of-9 federated multisig). No EVM bridge contract events exist. No covenant committee composition changes detected in 2025-2026. Phase-2 committee (AltLayer, Babylon Labs 3x, CoinSummer, Cubist, Informal Systems, RockX, Zellic) recorded in Genesis genesis file. No key rotation announcements found. Signal not firing.
RD-F-105 green DNS/CDN/frontend hash drift Babylon's production staking dApp at staking.babylonlabs.io. Halborn conducted V4 Upgrade + Frontend Staking Application audit (referenced in profile §8). No DNS change or frontend hash drift incidents detected in 2025-2026. January 2025 X account compromise was social media, not DNS/frontend. Frontend URL stable. Signal not firing.
RD-F-108 green GitHub force-push to sensitive branch Primary Genesis chain repo (github.com/babylonlabs-io/babylon) is public and active (last commit 2026-05-04). No GitHub force-push or unauthorized push incidents detected. Standard release branch strategy (release/v4.2.x). December 2025 vulnerability disclosure was a legitimate contributor issue report, not a force-push. Signal not firing.
RD-F-110 green Unusual pending/executed proposal ratio Babylon Genesis has active Cosmos SDK x/gov governance (not gray). 20+ proposals processed as of May 2026. Q1 2025 saw 8 proposals all approved per Messari — consistent cadence, no spike in pending proposals. Proposal types: routine parameter updates, CosmWasm whitelisting, software upgrades. No anomalous pending/executed ratio detected.
Dev identity & insider risk Green 3 16 of 16
RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Babylon Genesis chain uses Cosmos SDK x/gov for all software upgrades and parameter changes — V2 upgrade (2025-06-12 proposal, 2025-06-16 execution), V4 upgrade, and all chain parameter changes go through public governance votes with discussion. No unilateral admin key for chain upgrades. This is a strong positive. However, the covenant committee composition (Babylon Labs holds 3/9 keys = 33.3%) is NOT governed by on-chain BABY governance and was not ratified by community vote. Phase-2 covenant-committee.json in bbn-1 repo confirms same 7-org composition as Phase-1, but no governance forum thread proposing or ratifying this composition was found. The covenant committee is a privileged access surface (co-signs unbonding and slashing transactions for $4.16B of staked BTC) whose composition was selected and announced unilaterally by Babylon Labs. No threshold reduction, emergency override, or malicious ACL change event identified. Yellow (not red) because: committee technically CANNOT ste RD-F-114 gray Deployer address prior on-chain history No EVM deployer EOA exists. Bitcoin staking: each stake is a distinct Taproot UTXO with no singleton contract address. Babylon Genesis chain: launched via Cosmos SDK genesis file, not deployed via EOA. Data cache: deployer.address: null, non_evm_substrate: true. No deployer address history is assessable. This is a structural not-applicable condition for the non-EVM substrate. Scored gray (cannot assess — prerequisite data does not exist for this architecture) rather than not_applicable (which would imply the factor definition itself is N/A for this protocol type). RD-F-117 n/a ENS/NameStone identity bound to deployer Structurally not_applicable. Babylon Protocol operates on Bitcoin (UTXO-based; no ENS-equivalent on Bitcoin mainnet) and Babylon Genesis chain (Cosmos SDK; bech32 bbn1... addresses, no ENS). There is no EVM deployer EOA to bind an ENS name to. Per profiler: non_evm_substrate: true, evm: false. ENS binding is an EVM-specific factor inapplicable to Bitcoin + Cosmos SDK architecture. This is the same structural N/A applied to EigenLayer (prior reference) for ENS when deployer.address is null. RD-F-122 n/a Contributor paid to DPRK-cluster wallet No on-chain payment streams from Babylon Labs treasury to contributor wallets with DPRK cluster proximity are known. Babylon Labs uses institutional VC funding ($95.7M from Polychain, Paradigm, Hack VC, Galaxy) and presumably off-chain payroll for ~40+ employees. Dedicated DPRK search found zero results. However: individual contributor wallet payment routing cannot be verified at OSINT tier without Chainalysis API; covenant committee keys are off-chain Bitcoin signing keys, not payment destination addresses; the contributor list (KonradStaniec, SebastianElvis, etc.) does not have their personal payment wallets publicly linked. Cannot confirm definitive absence of 3-hop routing for all contributor wallets. Scored not_assessed rather than gray — evidence gap, not structural inapplicability. RD-F-124 n/a Deployer wallet mixer-funded within 30 days Structurally not_applicable. Babylon has no EVM deployer EOA. Bitcoin staking: each stake is a distinct Taproot UTXO with no singleton contract address. Babylon Genesis chain: launched via Cosmos SDK genesis file (not deployed by a single EOA). Data cache: deployer.address: null, non_evm_substrate: true. The 30-day-window mixer-funding test (RD-F-124 definition) presupposes a single deployer EOA from which Tornado Cash / Railgun proximity can be measured. That prerequisite is structurally absent for both Bitcoin UTXO and Cosmos SDK genesis deployment. This is not a data gap — it is a structural inapplicability of the factor definition to non-EVM architecture. RD-F-184 gray Real-capital social-engineering persona No curator-flagged pattern of a contributor or external integrator persona deploying >=1M USD in real capital to Babylon Protocol to build credibility ahead of a social-engineering attack. The January 2025 X account phishing compromise was an external social-engineering attack on the social media account itself (not a real-capital DeFi persona build-up pattern as defined in the factor — the Drift Protocol UNC4736 pattern). M-only / curator-dependent factor; cannot confirm absence definitively at OSINT tier. No active threat intelligence advisory connecting Babylon to this pattern. Scored gray (data insufficient for meaningful assessment) consistent with EigenLayer precedent.
RD-F-111 green Team doxx status David Tse: fully real-name doxxed — Thomas Kailath and Guanghan Xu Professor at Stanford EE, U.S. National Academy of Engineering member (2018), IEEE Claude E. Shannon Award (2017), Wikipedia biography, Google Scholar, Quanta Magazine profile. Fisher Yu (Mingchao Yu): real-name doxxed — LinkedIn with full employer history (NPU BE, ANU MPhil, Dolby Laboratories 2018-2022, Babylon Labs 2022-present), Crunchbase, The Org, Nasdaq published interview, conference video appearances. Legal entity: BabylonChain Inc. confirmed via The Org and Crunchbase. Both key founders are real-name doxxed with deep verifiable identity trails.
RD-F-112 green Team public accountability surface David Tse: Stanford faculty page, IEEE Xplore author profile, Wikipedia, Quanta Magazine profile, IEEE award pages (Shannon Award 2017, Hamming Medal), Google Scholar with hundreds of citations, multiple YouTube conference appearances. Fisher Yu: LinkedIn employer history, Google Scholar, Nasdaq published interview documenting career from Dolby to Babylon, conference video at Token2049. Covenant committee external members (AltLayer, CoinSummer/StakeFish, Cubist, Informal Systems, RockX, Zellic) are all named, publicly-listed entities with multi-year industry track records. Accountability surface is among the highest in DeFi for a founding team.
RD-F-113 green Team other-protocol involvement history David Tse: prior career is purely academic (UIUC PhD, AT&T Bell Labs postdoc, UC Berkeley faculty 1995-2014, Stanford 2014-present); Babylon is his first commercial DeFi protocol. Fisher Yu: prior role at Dolby Laboratories as Senior Staff Research Engineer 2018-2022; no prior DeFi protocol or rug-associated project found. Dedicated search 'Babylon Labs rug OR exit scam' returned zero relevant results — only generic rug-pull education content unrelated to Babylon. REKT database: zero incidents. No team member has a rug-labeled or curator-rug-listed prior project in public OSINT.
RD-F-115 green Prior rug/exit-scam affiliation Dedicated search returned zero results connecting any Babylon Labs team member to a rug or exit scam. January 2025 X account phishing was an EXTERNAL social-engineering attack on Babylon Labs' social media account (account recovered within 6 hours, $0 protocol loss) — not a team-member rug affiliation. REKT database shows zero incidents for Babylon Labs. No team member (David Tse, Fisher Yu, or any named contributor) has a rug-labeled prior project in public OSINT.
RD-F-116 green Contributor tenure at admin-permissioned PR GitHub repo babylonlabs-io/babylon top contributors: KonradStaniec (247 commits), SebastianElvis (239), vitsalis (142), RafilxTenfen (140), gitferry (118). Repository active since at least 2022 (founding year of Babylon Labs). Top contributors show multi-year tenure consistent with the founding timeline. No recent-joiner (< 90 days) admin-permissioned PR event identified at OSINT tier. Full contributor tenure analysis (days from first commit to admin-permissioned merge) is a PH-level assessment not available at OSINT tier; confidence is medium rather than high.
RD-F-118 green Handle reuse across failed/rugged projects Primary X/Twitter handle @babylonlabs_io confirmed active. January 2025 phishing compromise was an external attack (not handle reuse from a rugged project); account recovered within 6 hours, $0 loss. Handle @babylonlabs_io has no documented prior association with a rugged or failed project. David Tse's personal handle and Fisher Yu's (@DrFisherYu) show no prior rug-associated handle recycling. GitHub org babylonlabs-io: no prior rug-associated name found.
RD-F-119 green Commit timezone consistent with stated geography Recent commit timestamps from babylonlabs-io/babylon show activity across UTC, UTC-3, and UTC-7 timezones. Babylon Labs is a distributed team: Fisher Yu is based in North Sydney, Australia (AU LinkedIn); David Tse is at Stanford (US Pacific). UTC-3 commits are consistent with Brazilian or South American developers common in the Cosmos ecosystem. UTC-7 commits consistent with US Mountain Time developers. No Korean Standard Time (UTC+9) concentration detected that would suggest DPRK implant risk. Full commit-time distribution analysis not available at OSINT tier (GitHub contributor graphs are JS-rendered). Confidence is medium.
RD-F-120 green Video-off/voice-consistency flag David Tse: confirmed multiple on-camera video appearances at academic and blockchain conferences. Fisher Yu: confirmed on-camera video appearances at Token2049 (YouTube) and 'Building Bitcoin's Third Native Use Case' (YouTube). No curator observation of video-off pattern, voice inconsistency, or timezone anomaly in public interviews. Both founders present in-person at conferences consistent with their stated geographies.
RD-F-121 green Contributor OSINT depth score David Tse: 5/5 OSINT depth — Stanford faculty page (complete academic history), Wikipedia biography, IEEE awards pages, Google Scholar (extensive publication record with thousands of citations), Quanta Magazine profile, in-person conference presence, National Academy of Engineering membership since 2018. Fisher Yu: 4/5 — LinkedIn employer history (Dolby 2018-2022 confirmed), Google Scholar, Crunchbase, conference video appearances, Nasdaq interview, fisheryu.io. Covenant committee external orgs: 4/5 each (named companies with years of public track record). Individual Babylon Labs covenant key operators: 2/5 (institutional attribution confirmed, individual names not public at key level).
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No DPRK/Lazarus proximity found. Dedicated OSINT search 'Babylon Labs DPRK OR Lazarus OR North Korea developer' returned zero results. David Tse: U.S. National Academy of Engineering member (2018), Stanford professor for 10+ years, MIT PhD, AT&T Bell Labs postdoc, UC Berkeley faculty — one of the most verifiable academic identities in DeFi; OFAC SDN and Lazarus cluster reports contain no reference to his name or linked wallets. Fisher Yu (Mingchao Yu): Australian National University MPhil, Dolby Laboratories US (2018-2022) as prior employer — no DPRK-adjacent history. Babylon Labs VC-backed by Paradigm (US), Polychain (US), Hack VC, Galaxy — KYC-grade diligence implied by Paradigm Series B lead. No public Chainalysis Lazarus report links any Babylon Labs entity or wallet to DPRK cluster. OFAC SDN does not list Babylon Labs, BabylonChain Inc., David Tse, or Fisher Yu. No deployer EOA to trace hops from (structurally non-EVM). Escalation: NOT required.
Fork / dependency lineage Green 11 10 of 10
RD-F-135 yellow Shared-library version with known-vuln status CometBFT GHSA-h598-3g3g-c67c: patched in v4.2.5 (current v4.2.7 is patched). Babylon also issued 4 own GHSAs in 2025-2026 (vote extension, BIP-322 sig, nil pointer, AfterBtcDelegationUnbonded hook) — all patched in v4.1.0–v4.2.0. cosmwasm-std RUSTSEC-2024-0338 (arithmetic overflow in pow/neg): affects <2.0.2; Cargo.lock pins 2.2.2 (patched). RUSTSEC-2024-0361 (gas mispricing, affects <2.1.3): 2.2.2 is patched. No open critical library vulnerabilities in current deployed versions, but the volume of self-issued GHSAs in 2025-2026 indicates active vulnerability surface in the chain modules. RD-F-126 n/a Is-a-fork-of Babylon is an original protocol (fork_lineage: original per profile meta.json). No upstream DeFi protocol fork relationship. Bitcoin staking script and EOTS are novel cryptographic constructions. Genesis chain custom modules are original implementations. Go repo has no upstream fork origin. RD-F-127 n/a Upstream patch not merged No upstream DeFi protocol fork exists. Factor does not apply. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) No upstream DeFi protocol fork exists. No upstream-disclosed vulnerability can propagate to a non-fork. Framework dependency vulnerabilities are tracked under RD-F-135. RD-F-129 n/a Code divergence from upstream (%) No upstream DeFi protocol fork exists. Code divergence percentage metric does not apply to an original codebase. RD-F-130 n/a Fork depth (generations from original audit) Fork depth = 0 by definition (original codebase). Factor does not apply. RD-F-131 n/a Fork retains upstream audit coverage No upstream DeFi fork. Babylon maintains its own independent audit programme (6 firms confirmed). Audit coverage assessed under Cat 1. RD-F-132 n/a Fork has different economic parameters than upstream No upstream DeFi fork exists. All economic parameters (slashing percentage, unbonding timelock, covenant committee threshold) are original to Babylon. Factor does not apply.
RD-F-133 green Dependency manifest uses unpinned versions go.mod pins exact versions for all critical dependencies: Cosmos SDK v0.53.5, CometBFT v0.38.22, CosmWasm/wasmd v0.60.5, IBC-Go v10.5.0, btcd v0.24.2. go.sum provides cryptographic hashes for all 1,629 dependency entries. cosmos-bsn-contracts Cargo.lock pins all Rust dependencies to exact versions (cosmwasm-std 2.2.2, bitcoin 0.32.6, k256). No floating/unpinned version ranges observed.
RD-F-134 green Dependency had malicious-release incident (last 90d) No malicious-release incident in the trailing 90 days (as of 2026-05-04) for Cosmos SDK, CometBFT, CosmWasm/wasmd, btcd, blst, IBC-Go, or any key dependency. Babylon's go.sum cryptographic hash pinning provides protection against silent version-swapping supply chain attacks.
Post-deploy hygiene & change mgmt Green 19 13 of 13
RD-F-136 yellow Deployed bytecode matches signed release tag GitHub releases exist with version tags (v4.2.7 Apr 14, 2026; v4.0.0 Nov 6, 2025 etc.). No independent bytecode-vs-commit-SHA match verification performed at this tier. Cosmos SDK binary compilation is known to produce non-deterministic outputs across OS/Go versions without explicit reproducible build tooling. No formal 'reproducible builds' attestation published for Babylon Genesis binary. Release discipline above average for Cosmos SDK chains but no signed artifact verification confirmed. RD-F-137 yellow Upgrade frequency (per 90 days) Release cadence from Nov 2025 to Feb 2026: v4.0.0 (Nov 6), v4.1.0 (Nov 24), v4.2.0 (Dec 4), v4.2.1 (Dec 8), v4.2.2 (Dec 18), v4.2.3 (Jan 9, 2026), v4.2.5 (Feb 4, 2026) = 7 releases in ~90 days. Most are minor/patch releases in the v4.2.x series. In the 90 days to assessment date (Feb 4 → May 4, 2026): v4.2.5 and v4.2.7 = 2 releases. Active development cadence overall yellow; recent 90-day period is lower (2 releases = green). Using yellow to reflect the broader pattern. RD-F-139 yellow Post-audit code changes without re-audit Multiple audit engagements covered different versions. KEY: OpenZeppelin 2026-04-01 research found 4 active vulnerabilities (delegation status flaw, FP jailing bypass, co-staking accounting error, type assertion panic) in deployed code. OZ states 'fixes shipped promptly' with PR #1911 and #390 referenced. However: (1) V4 upgrade (v4.0.0, Nov 2025) has Halborn and Coinspect audits listed but reports NOT publicly available at assessment date — cannot verify audit coverage; (2) whether OZ-identified fixes were independently re-audited post-deployment is not confirmed. Graded yellow (not red) because OZ stated fixes were shipped, and a formal audit culture exists (9+ engagements total). Missing public V4 audit reports reduce confidence. RD-F-145 yellow Deployed bytecode reproducibility Cosmos SDK Go binary is in principle reproducible from tagged source with declared Go version. CHANGELOG.md present (data cache confirmed). However, Cosmos SDK binary compilation is known to produce non-deterministic output across OS/Go versions without explicit reproducible build tooling. No formal 'reproducible builds' attestation (equivalent to Solana Verifiable Builds) found for Babylon Genesis binary. No independent reproduction attempt performed at this tier. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant POSITIVE FINDING: V2 upgrade (June 2025) added IBC rate limiting capping BABY token exits at 10% of native supply within 24 hours — explicit outflow rate-limiter. No admin-triggered chain-level pause mechanism identified (Cosmos SDK x/crisis is validator-consensus-based halt, not admin key). Score yellow: rate-limiter present (positive) but no admin-triggered chain-pause capability separate from consensus. The rate-limiter is a material security mitigant for cross-chain outflow risk. RD-F-142 n/a Storage-layout collision risk across upgrades Not applicable. Cosmos SDK uses module-keyed key/value store (IAVL tree), not EIP-1967 proxy storage slots. No Solidity storage layouts or slot assignment conflicts exist. Module upgrades use Cosmos SDK RegisterMigration and ConsensusVersion patterns, not EVM storage slot migration. The EVM storage-layout collision risk class is architecturally absent. RD-F-143 n/a Reinitializable implementation (no _disableInitializers) _disableInitializers() is an OpenZeppelin Solidity pattern for EIP-1967 proxied contracts. Cosmos SDK modules use Go constructors and module genesis init functions, which are one-time operations at chain genesis — not re-callable via a separate initializer function. No proxy pattern, no delegatecall, no Solidity initializer exists in Cosmos SDK. The concept of proxy re-initialization is architecturally absent. RD-F-144 n/a CREATE2 factory permits same-address redeploy CREATE2 is an EVM opcode. Cosmos SDK and Bitcoin do not use CREATE2. CosmWasm contract deployment uses code IDs and instantiation, not CREATE2 patterns. No same-address redeploy risk exists in this architecture. RD-F-168 n/a Stale-approval exposure on deprecated router Not applicable. ERC-20 approvals and router patterns are EVM concepts. BABY is a native Cosmos denomination (ubbn), not an ERC-20. No EVM-style approve/transferFrom allowances exist. No deprecated router contracts on bbn-1 identified. Structurally inapplicable to this architecture.
RD-F-138 green Hot-patch deploys without timelock (last 30 days) v4.2.7 (Apr 14, 2026) bumped CometBFT to v0.38.22 — minor node-level update; v4.2.5 (Feb 4, 2026) addressed CometBFT security fix (GHSA-h598-3g3g-c67c). Minor CometBFT bumps in Cosmos SDK chains are typically deployed by validators independently without requiring governance upgrade proposals (no state change). No confirmed timelock-bypass or hot-patch-without-governance-approval identified in the last 30 days. Governance upgrade proposals are on-chain with voting periods.
RD-F-140 green Fix-merged-but-not-deployed gap OZ-identified vulnerabilities (2026-04-01) were fixed and deployed per OZ blog ('fixes shipped promptly'). GitHub PR #1911 (type assertion fix) referenced in OZ blog. Fixes appear in v4.2.x releases after OZ discovery (v4.2.5 Feb 2026, v4.2.7 Apr 2026 both post-date the vulnerabilities' probable discovery). No evidence of an undeployed security fix currently pending in the repository.
RD-F-141 green Test-mode parameters in deploy Cosmos SDK genesis file bootstraps production parameters. Governance parameters (deposit 50,000 BABY, voting period 3 days, quorum 33.4%) are explicitly configured and documented. V2 modules (TokenFactory, IBC rate limiter) were tested on testnet before mainnet upgrade (confirmed by V2 blog). No test-mode parameters (test oracle addresses, zero-confirmation thresholds) found in production bbn-1 chain.
RD-F-146 green New contract deploys in last 30 days CosmWasm deployment on bbn-1 is permissioned (governance whitelist required per profile §3). In the 30 days prior to assessment: v4.2.7 released Apr 14, 2026 (CometBFT bump, no new contract surface). No governance proposals listing new CosmWasm instantiations found in this window. BTC staking UTXOs are user-generated, not protocol contract deployments. No new protocol contract deployments identified in the trailing 30 days.
Cross-chain & bridge Yellow 22 12 of 12
RD-F-148 yellow Bridge validator count (M) Covenant committee: 9 members, 6-of-9 threshold. Phase-1: AltLayer x1, Babylon Labs x3, CoinSummer x1, Cubist x1, Informal Systems x1, RockX x1, Zellic x1. Babylon Labs holds 3/9 keys (33.3%). 9-member committee is small relative to $4.16B TVL secured. Vigilante: permissionless — any operator can run. RD-F-149 yellow Bridge validator threshold (k-of-M) 6-of-9 required for covenant committee co-signing. Babylon Labs holds 3 keys (33.3%); any 3 other committee members + Babylon Labs = 6-of-9 quorum. Threshold at 2/3 is within BFT bounds, but Babylon Labs' near-deterministic quorum influence is a concentration risk. Covenant committee cannot unilaterally steal BTC (script path enforcement prevents arbitrary spends) but can block unbonding or enable invalid unbonding. RD-F-150 yellow Bridge validator co-hosting Unknown. Covenant committee members operate off-chain signing services (covenant-emulator software). No public ASN / datacenter disclosure for any committee member's infrastructure. Babylon Labs holds 3/9 keys — their internal infrastructure is unknown. Cannot determine co-hosting from available public data. RD-F-155 yellow Bridge validator-set rotation recency Covenant committee established at Genesis launch (2025-04-10, approximately 13 months before assessment date). No public announcement of a covenant committee rotation event post-genesis-launch found. Phase-2 committee composition encoded in bbn-1 genesis file but individual member public keys for Phase-2 not independently confirmed at assessment date. No documented rotation mechanism or rotation cadence in protocol governance. RD-F-156 yellow Bridge uses same key custody for >30% validators Babylon Labs holds 3 of 9 covenant committee keys (33.3%), above the 30% threshold. All three Babylon Labs keys are controlled by the same organization — same operational security posture, same internal threat model. Phase-1 composition confirmed (3 Babylon Labs keys); Phase-2 composition not independently confirmed at assessment date. RD-F-157 yellow Bridge TVL per validator ratio Total TVL: $4.16B (100% BTC, DefiLlama 2026-05-04). Covenant committee: 9 members, 6-of-9 threshold. Per-member exposure: $4.16B / 9 = ~$462M per committee member. Note: covenant committee cannot unilaterally steal BTC (script path enforcement); risk is unbonding authorization. Still, $462M per member represents high incentive for nation-state-class adversaries. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) Structurally inapplicable. Babylon does not use Ethereum ecrecover for any cross-chain operation. Bitcoin-side uses Schnorr multisig (BIP 340 / Taproot) where invalid signatures are rejected at Bitcoin consensus layer — no separate zero-address check needed or possible. Genesis chain uses CometBFT BLS/Ed25519 and EOTS (Extractable One-Time Signatures). No EVM bridge contract exists. Profile meta.json explicitly lists ecrecover bridge validation (F151) as a non-EVM gray factor. CRITICAL ★ factor is not_applicable (not red) by structural architectural mismatch — do NOT penalize grade. RD-F-154 n/a Default bytes32(0) acceptable as valid root Structurally inapplicable. Babylon does not use a Merkle root inbox pattern. No bridge contract maintains a committedRoot mapping. Trust model: (a) Bitcoin UTXO spending paths via Taproot (no root acceptance); (b) BTC light client validates Bitcoin header chain by accumulated PoW (not by accepting Merkle root from external source); (c) IBC uses channel commitments as cryptographic hashes not accept-by-default roots. The Nomad-class bytes32(0)-as-valid-root vulnerability requires a contract that stores and checks against a root — Babylon has no such architecture. CRITICAL ★ factor is not_applicable (not red) — do NOT penalize grade. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) Babylon does not use LayerZero OFT or any LayerZero infrastructure. Data cache confirms layerzero.present: false. Cross-chain coordination uses vigilante relay (Bitcoin to Genesis) and IBC (Genesis to BSNs). F179 is defined for LayerZero OFT integrations specifically.
RD-F-147 green Protocol has bridge surface Yes — Babylon coordinates state across Bitcoin mainnet, Babylon Genesis chain (bbn-1), and BSNs. Cross-chain surface: Bitcoin to Genesis via vigilante relay; Genesis to BSNs via IBC or custom relayers. has_bridge_surface: true per profile meta. BTC does not leave Bitcoin (coordination, not asset bridging).
RD-F-152 green Bridge binds message to srcChainId Cross-chain messages are implicitly chain-bound: BTC headers include PoW difficulty parameters (Bitcoin-mainnet-specific); covenant PSBT transactions are Bitcoin-mainnet-specific by UTXO script construction; IBC messages include connection_id and channel semantics binding them to sender/receiver chain pair. Cross-chain replay is not possible at the Bitcoin UTXO layer (each UTXO spendable only once).
RD-F-153 green Bridge tracks nonce-consumed mapping Replay protection: Bitcoin UTXO model is inherently replay-resistant (each UTXO can only be spent once); x/btcstaking tracks delegation state (Active/Unbonding/Withdrawn) preventing re-registration of processed transactions; IBC packets use sequence numbers (incrementing counter per channel). Staking script docs confirm each staking output is a unique UTXO with unique outpoint.
Threat intelligence & recon Green 11 8 of 8
RD-F-161 yellow Protocol-impersonator domain registered (typosquat) No specific typosquat confirmed in the 90-day window (2026-02-03 to 2026-05-04) via public searches. However: (1) Babylon is the largest BTC DeFi protocol ($4.16B TVL), creating elevated brand-impersonation incentive; (2) confirmed adversarial brand targeting exists — January 2025 X account compromise demonstrated active threat actors targeting Babylon brand; (3) production domain monitoring (CertStream/PhishFort) not accessible — this is a known gap. Candidate typosquat domains (babylon-protocol.io, babylonlabs.com, babylon-staking.io, babylonprotocol.com) not confirmed as malicious. Yellow: elevated risk despite no confirmed active typosquat, due to high-value brand + known adversarial targeting + monitoring gap. RD-F-165 yellow Protocol social channel has scam-coordinator flag January 2025 X account compromise: Babylon Labs official X account (@babylonlabs_io) was controlled by phishing attackers who posted malicious links. Account recovered within 6 hours. This confirms Babylon's social channels have been successfully compromised for scam distribution. No Discord admin flagged on scam-coordinator watchlist. No current ongoing campaign. Yellow because: (1) confirmed historical X channel compromise (January 2025), (2) not a current ongoing campaign (account recovered), (3) no Discord admin flagged in public sources. RD-F-160 n/a GitHub malicious-dependency incident touching protocol deps Cell re-flagged 2026-05-06 by quality audit wave 3: prior evidence cited a non-existent GHSA advisory (GHSA-h598-3g3g-c67c returns 404 in both GitHub Advisory UI and REST API) and fabricated CometBFT releases (v4.2.5, v4.2.7 do not exist; CometBFT versioning is v0.38.x / v0.39.x). Re-collection required from Babylon's actual go.mod dependencies + GitHub Advisory Database primary sources before this factor can be re-scored. RD-F-163 gray Avg attacker reconnaissance time for peer-class protocols BTC restaking is a novel protocol class with zero prior exploits in the hack database. Insufficient sample size to compute class-average attacker reconnaissance time. Closest peer class (bridge protocols) would have a different reconnaissance profile. Cannot score without a non-zero class sample. Gray per factor definition: 'insufficient hack DB sample for this class.'
RD-F-158 green Known-threat-actor cluster has touched protocol No confirmed DPRK/Lazarus or known-threat-actor cluster interaction with Babylon staking contracts found in public intelligence. DPRK most recent large DeFi heist was KelpDAO (April 2026, $290M EVM/LayerZero). BTC-native protocols are structurally harder to drain via Lazarus-style attacks (Bitcoin UTXO model, non-custodial, no EVM attack surface). No public CTI reports for Babylon-specific threat-actor interaction. Private CTI feed not configured.
RD-F-159 green Attacker wallet pre-strike probe (low-gas failing txs) No public intelligence of pre-strike probe transactions against Babylon Genesis chain or Bitcoin staking contracts from CTI-flagged wallets. January 2025 X account compromise was social engineering, not on-chain reconnaissance. Babylon's non-EVM architecture means standard EVM low-gas revert probe patterns do not apply. No hack database entries for Babylon. CTI feed not configured for full assessment.
RD-F-162 green Known-exploit-template selector deployed by any address No known exploit-template selector deployment detected for BTC-restaking class. Babylon has no EVM contracts to replicate. Bitcoin Taproot staking script is novel — no exploit-template index maintained. OpenZeppelin 2026 disclosure of 4 vulnerabilities was reported privately and remediated; no public exploit contract derived. Hack database zero entries for Babylon.
RD-F-164 green Leaked credential on paste/sentry site No credential leaks or API key exposures for Babylon Labs infrastructure detected in public searches. January 2025 X account compromise was phishing-based social engineering (not a credential dump or paste site leak). GitHub org (babylonlabs-io) has security_md_present: true (active security posture). No paste site disclosures found. Note: full paste monitoring requires dedicated feed — assessment based on public intelligence searches only.
Tooling / compiler / AI Green 11 5 of 5
RD-F-170 yellow Solc version used (known-bug versions flagged) Go toolchain: go.mod specifies go 1.25.8. Current Go stable is 1.26.2; latest Go 1.25.x is 1.25.9 (1.25.8 is one patch behind in maintenance series). Go 1.25.x is not EOL but is in maintenance mode behind 1.26. No CVE specifically affecting 1.25.8 vs 1.25.9 found. Rust/CosmWasm: edition 2021, cosmwasm-std 2.2.2 (Cargo.lock), current stable CosmWasm v2 series. No Rust nightly toolchain used. Minor Go patch lag drives yellow over green. RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation Babylon is an original protocol with no upstream DeFi fork. Bitcoin staking script, EOTS cryptographic primitive, and Genesis chain modules implement novel functionality. No high-bytecode-similarity-with-behavior-deviation pattern is applicable. RD-F-173 gray Team self-disclosure of AI-generated Solidity AI-assisted code disclosure: no public announcement by Babylon Labs of AI/Copilot/Codex usage in security-critical paths. Per universal save-time lesson (F184 precedent): cannot reliably assess absence of something that by design leaves no public trace. Score gray pending curator-flagged evidence; team has strong academic cryptography background (David Tse Stanford, Fisher Yu Dolby) suggesting human-led design.
RD-F-172 green Repo shows AI-tool co-authorship in critical files GitHub commit search in babylonlabs-io/babylon for AI/copilot/GPT/codex returned 0 results. Same search in cosmos-bsn-contracts returned 0 results. No AI-tool co-authorship disclosures in commit messages. Most recent commit (d96cd9d) is supply-chain security hardening (SHA-pinning GitHub Actions) — consistent with security-conscious development practices.
RD-F-174 green Dependency tree uses EOL Solidity version Go 1.25.x: not EOL (Go supports current + one prior major version; 1.26 is current, 1.25 is in maintenance with security support). Rust edition 2021: active support. CometBFT v0.38.22: actively patched (security releases through 2026). Cosmos SDK v0.53.5: actively maintained. CosmWasm/wasmd v0.60.5: maintained CosmWasm v2 series. No EOL toolchain or compiler version in the dependency chain.
Response & disclosure hygiene Green 17 4 of 4
RD-F-176 yellow Disclosure SLA public SECURITY.md explicitly states: 'We will confirm receipt of your report within 48 hours.' This is a published SLA under the 72-hour green threshold. However, no public record exists of this SLA being tested and verified under a real-world disclosure scenario (OZ 2026 disclosure was actioned but no timestamps published). Yellow = SLA stated but not verified through prior instances. RD-F-178 yellow CVE/GHSA advisory issued against protocol Three GHSA advisories confirmed against babylonlabs-io/babylon: (1) GHSA-2fcv-qww3-9v6h — Moderate — malformed vote extensions chain-halt DoS — patched v4.1.0 (Nov 2025); (2) GHSA-m6wq-66p2-c8pc — High — nil BlockHash consensus panics — patched v4.2.0 (Dec 2025); (3) GHSA-xq4h-wqm2-668w — Low — BIP-322 SIGHASH compliance — patched v4.1.0 (Nov 2025). All advisories patched in current release v4.2.7. No unpatched advisories found. Yellow = advisory exists and patched.
RD-F-175 green Disclosure channel exists Active Immunefi bug bounty program since 2024-09-16 (last updated 2026-04-14). Security email security@babylonlabs.io and GitHub private advisory channel published in SECURITY.md. Evidence of active monitoring: OZ 2026 disclosure triaged quickly; three GHSA advisories patched in v4.1.0 and v4.2.0. Program covers 17 assets. Green = public disclosure channel exists and actively monitored with response evidence in last 12 months.
RD-F-177 green Prior known-ignored disclosure No prior exploits in the record; no case of a disclosure being received and ignored before exploitation. All known disclosures were actioned: OZ 2026 (4 vulnerabilities, all patched); GHSA-2fcv-qww3-9v6h (patched v4.1.0); GHSA-m6wq-66p2-c8pc (patched v4.2.0); GHSA-xq4h-wqm2-668w (patched v4.1.0). OZ explicitly states Babylon Labs responded promptly.
rubric_version v1.7.0 graded_at 2026-05-12 04:38:07 factors 184 protocol babylon-protocol