b14g

The evidence supports rejection. 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 support the dualCORE vault, and the vault’s one-day redemption does not describe Babylon BTC unbonding. The cited material gives neither product a complete live record of authority, product-level TVL, incidents and stressed exits. The aggregate remains rejected at zero.

Review triggers: events that reopen the 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

Watched nightly: a warning on its venues or files, or a cited document that changes, reopens the memo. The first confirmation is due 2026-11-15.

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 does not hold the 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 moves 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 carries risks from Core validators, marketplace and order contracts, vault accounting, operator selection, upgrades and the secondary market. 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 that changes validator whitelists, fees and vault parameters, a multisig treasury, an oracle and 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. The audit list is useful only after the deployed bytecode and every fix are matched to it. No cited source gives a complete product-level record of incidents, slashing, failed withdrawals or accounting losses. Their absence from the reviewed pages does not show that no event occurred.

Two different exits and loss paths

Babylon BTC cannot be sold as a liquid b14g receipt. A normal exit follows the selected staking timelock or the protocol’s on-demand unbonding transaction. The BTC remains open to slashing 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 alone. dualCORE instead advertises a one-day normal redemption with no fee and an immediate `withdrawDirect` path charging 10%. Those are paths described by the project, not proof that the proposed size is available during correlated order expiry or Core-validator stress. A DEX sale adds market depth and discount. Neither exit is evidence for the other product.

Comparison and decision

For Babylon BTC, the clean comparison is direct use of Babylon’s staking interface with a disclosed finality provider. b14g must justify any added marketplace contract and BABY reward dependency. For CORE, direct delegation through Core exposes one chosen validator without a liquid receipt, while stCORE provides a separate liquid-staking comparison and dualCORE adds automated order routing plus the claimed shorter exit. Higher advertised yield does not make up for an allocator whose powers have not been mapped. The aggregate cannot be approved until one exact product is selected and measured against its own comparison, 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 research above describes the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The layer with the most administrative power sets the position’s effective control; that describes control, not quality or suitability.