b14g

Rejected venues wait the longest for re-review; a rejection has to earn another look before the scheduled date.

REJECTED. The b14g slug is an aggregate, not one position. DefiLlama’s 2026-08-14 snapshot attributes about $204.1M to it—approximately $200.5M of native BTC, $3.4M of CORE and $0.2M of BABY—but chain and token totals do not identify the contracts, staking scripts or decision rights behind each balance. The Babylon route leaves BTC in a Taproot staking output delegated to a finality provider and subject to Babylon covenant and slashing rules. dualCORE is a separate operator-routed CORE vault on Core at 0xee21ab613d30330823D35Cf91A84cE964808B83F. It reallocates CORE among marketplace orders and exposes a liquid receipt. Self-custody of the Babylon BTC does not underwrite the dualCORE vault, and the vault’s one-day redemption does not describe Babylon BTC unbonding. Neither product has a complete live authority, product-level TVL, incident and stressed-exit record in the cited material. The aggregate remains rejected at zero.

Kill criteria: the events that revoke this verdict
• Babylon review reopens only for named staking transactions whose BTC amount, script parameter version, timelock, finality provider, covenant threshold, marketplace order and reward split are independently reproduced from Bitcoin and Babylon state
• Babylon review requires every deployed b14g marketplace contract, administrator and delay mapped to a read audit, twelve months without unexplained slashing or failed withdrawal, and one proposed-size unbonding completed within the applicable published maximum
• dualCORE review reopens only after vault-level TVL, every active order and validator weight, operator and proxy authorities, upgrade delay, fee, accounting method and audit remediation are published and independently reproducible
• dualCORE must complete three proposed-size normal redemptions in separate months within 24 hours and 50 basis points total cost without `withdrawDirect`; a proposed-size DEX sale must also remain within 50 basis points
• Any product-level accounting gap, undisclosed authority change, finality-provider concentration above 25%, unresolved slashing, missed withdrawal maximum or reliance on aggregate b14g TVL keeps that product rejected

The research file

Babylon BTC staking is one decision unit

The b14g Babylon guide routes a holder into Babylon self-custodial staking: BTC stays on Bitcoin, is not wrapped or bridged, and is delegated to a finality provider. The Bitcoin output commits to a staking timelock, an on-demand unbonding path and a slashing path. Babylon’s specification says a finality-provider double-sign can expose its EOTS key and authorize slashing of delegations, including during the unbonding period. A covenant committee co-signs prescribed unbonding and slashing transactions. b14g may add BABY co-staking and reward matching through its Merge Marketplace, but that coordination layer is not the custody mechanism for BTC. The record must name each staking transaction, finality provider, parameter version, covenant threshold, timelock, unbonding state and marketplace order separately.

dualCORE is a different decision unit

dualCORE accepts CORE into an ERC-20 vault on Core at 0xee21ab613d30330823D35Cf91A84cE964808B83F. b14g documents `stake`, `unbond`, `withdraw` and `withdrawDirect` paths and a daily CORE-per-dualCORE conversion ratio. The operator-only `ReInvest` path reallocates vault CORE from lower-yielding to higher-yielding Merge Marketplace orders and compounds rewards. This is managed allocation across CORE staking orders, not Bitcoin self-custody. The receipt inherits Core validators, marketplace/order contracts, vault accounting, operator selection, upgrade and secondary-market risks. Aggregate CORE TVL does not prove how much is in this exact vault or which validators and orders hold it.

Authorities, assurance and incident record

The architecture describes a BTCFi Council changing validator whitelists, fees and vault parameters, a multisig treasury, an oracle/validator registry and operators that rebalance dualCORE. The reviewed pages do not map those labels to current addresses, signer thresholds, upgrade delays or emergency powers for both products. b14g publishes Halborn reviews for the Core marketplace and dualCORE contracts and a Coinspect review for the Babylon marketplace. Audit inventory is useful only after deployed bytecode and every remediation are reconciled. No cited source is a complete product-level incident, slashing, failed-withdrawal or accounting-loss ledger; absence from the reviewed pages is not evidence that no event occurred.

Two different exits and loss paths

Babylon BTC cannot be sold as a liquid b14g receipt. Normal realization follows the selected staking timelock or the protocol’s on-demand unbonding transaction and remains slashable under the applicable script while the unbonding condition applies. A finality-provider or covenant liveness problem can therefore affect timing even though no custodian can spend the BTC unilaterally. dualCORE instead advertises a one-day normal redemption with no fee and an immediate `withdrawDirect` path charging 10%. Those are project-described paths, not proof that proposed size is available during correlated order expiry or Core-validator stress. A DEX sale adds market depth and discount. Neither exit can be used as evidence for the other product.

Comparison and decision

For Babylon BTC, the clean comparator is direct use of Babylon’s staking interface with a disclosed finality provider; b14g must justify any additional marketplace contract and BABY reward dependency. For CORE, direct delegation through Core exposes one chosen validator without a liquid receipt, while stCORE supplies a separate liquid-staking comparator and dualCORE adds automated order routing plus the claimed shorter exit. Higher advertised yield does not compensate for an unmapped allocator. The aggregate cannot be approved until one exact product is selected and measured against its own comparator, contracts, authorities, loss path and executable exit.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• b14g current product catalogue · primary · accessed 2026-08-15
  Supports: separate Core marketplace and dualCORE products, Babylon BTC and BABY product scope, published product status, application routes
• b14g Babylon BTC staking guide · primary · accessed 2026-08-15
  Supports: Bitcoin self-custody, no wrapping or bridging, finality-provider delegation, unbonding interface, BABY marketplace pairing
• b14g dualCORE technical design · primary · accessed 2026-08-15
  Supports: dualCORE vault address, operator ReInvest authority, daily conversion ratio, one-day normal redemption, ten-percent instant redemption fee
• b14g architecture and governance description · primary · accessed 2026-08-15
  Supports: BTCFi Council claim, validator whitelist and parameter powers, multisig treasury, oracle and validator registry, yield-router architecture
• b14g published security audits · primary · accessed 2026-08-15
  Supports: Halborn Core marketplace scope, Halborn dualCORE scope, Coinspect Babylon marketplace scope, published audit inventory
• Babylon Bitcoin staking-script specification · primary · accessed 2026-08-15
  Supports: staking and unbonding scripts, finality-provider key, covenant threshold, double-sign slashing path, unbonding-period slashing
• Core dual-staking integration guide · primary · accessed 2026-08-15
  Supports: CORE delegation mechanism, delegator principal treatment, validator reward slashing, undelegation contract path, direct-staking comparator
• DefiLlama b14g survey record, read 2026-08-14 · secondary · accessed 2026-08-15
  Supports: aggregate protocol TVL, Bitcoin CORE and BABY breakdown, chain attribution, survey timestamp

Inherited controls

The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.