Please forgive my skepticism, but what would Babylon do better than tBtcv2? tBtcv2 isn’t ideal in that it has a fixed, closed group of “validators” that manage a private key to an ERC20 contract, that aside, it’s the closest thing right now to a trustless bridge.
You’re describing an ERC20 token, with some centralized entity controlling private keys, those private keys issue mint() & burn() calls in a solidity contract, that’s exactly what a “bridge” is. The only 2 ways I’m personally aware of to have a more trustless, permisionless, decentralized BTC-ETH bridge than what tBtcv2 offers is to 1; have a complete sha256 chainsync inside a solidity contract which is far too expensive at the moment or 2; a proof of work open bidding system on a seperate coin daemon that offers miners the right to call mint() & burn() on an ERC20 contract (which would offer no more centralization than the common BTC mining pool that controls coinbase deposits), and you’re describing neither of those.
You should publish more programmatic, not math, details for the common, non mathematician developer to understand. As I understand from the whitepaper, the programming implementation of this would be an identical workflow to tBtcv2, deposit to a negotiated BTC address, call some “revealDeposit()” style solidity function, then wait for a mint(). If I am correct, all that is, is a far more technically complex version of tBtcv2 that offers zero additional security in the form of decentralization, trustlessness, openness, etc.