I saw this on nostr (where the other is asking for comments) and spent a little time looking at it.

In general, I think it's cool when people dream up new layer two ideas. Bitcoin is a huge design space and I believe there are probably things no one has thought to try before. That being said, i think ti's pretty difficult to come up with better trade-offs than Lightning.

So here is Bitcoin Deposits. It sounds like a system of a number of custodians (called operators, I think?) who hold sats on a user's behalf. But while a user may only interact with one operator, the operators pool all their deposited sats into a multisig controlled by a quorum of operators.

we propose a solution to this problem using verifiable ledgers and a web of collateral. operators broadcast ledger updates to their peers, creating an auditable record of accounts. wallets broadcast evidence of dishonesty to those peers, who ensure that the ledger maintains an honest operator. unilateral exit is replaced by the guarantee that funds remain available so long as the network does. we arrive at a network that delegates liquidity maintenance, avoids setup fees, is capable of receiving payments offline, and scales independently of the base layer.

In the case that your operator cheats, the other operators are supposed to confiscate the cheating operator's sats.

From the FAQ:

q: what happens when dishonest parties steal funds?q: what happens when dishonest parties steal funds?

a: the basic construction is that the operator updates the ledger, but a quorum controls the on-chain collateral/reserves utxo. if the operator makes invalid updates, the quorum confiscates their collateral and sends the reserves to a random quorum member, who will assume responsibility for the ledger

if quorum members themselves are dishonest or do not reassign reserves in a timely manner, the quorums on their own ledgers will find out, and confiscate their collateral and reassign their reserves

This second part was confusing to me.

Here's how ledger operators are described:

ledgers have a single active operator, but are cooperatively maintained by the mesh. any operator can create one, but should they disappear or become dishonest a different operator will be assigned, along with reserves. the currently active operator is identified by the pubkey that was used to sign to most recent co-signed update.

Trying to understand the operator/custodian role, here is something about the quorums:

operators request other operators to join their quorum. the member’s terms include minimum fee schedules that deposits on the ledger must meet. to serve as a quorum member, an operator must have collateral at stake on their own ledger — misbehavior as a quorum member (co-signing a non-conforming update) can result in slashing on the member’s own ledger. members specify limits on fee schedules during their quorum membership — the operator cannot open deposits with fees below the strictest member’s minimums, protecting members from inheriting unprofitable obligations after a custody transfer

once quorum is established, reserves are rotated into a new taproot multisig utxo. members co-sign valid updates and participate in recovery if the operator signs non-conforming ones. quorum membership is lightweight — it requires no separate capital, only that the member has collateral at stake on their own ledger and is willing to monitor. larger quorums increase communication overhead but reduce operator risk, increase availability, and make collusion more difficult and expensive. wallets should prefer larger quorums

There's also a lottery thing for reassigning ledgers when an operator is proven to be dishonest:

q: how does the quorum reassign ledgers?q: how does the quorum reassign ledgers?

a: quorums are composed of other operators running their own ledger that is at least half the size as the validated ledger. quorums have odd-numbered membership, realistically 3, 5, or 7 members. a majority of the quorum is required to co-sign updates (operate), and a majority is required to reassign a ledger (confiscate)

the ledger is assigned to one of the quorum members based on a commit-reveal lottery. before committing, each participating quorum member creates their own fork of the ledger, declares replacement collateral, and organizes a quorum. after the commitment transaction, participants reveal their pre-image and a winner is determined. the operators who lost close their fork with “yield”, and the winner continues their fork with “acquire”. then the quorum members spend the confiscated reserves along with the replacement collateral into a new quorum

All in all, this sounds like other federations like Liquid or fedimint, and I didn't see a solution to their native problem of the user not being able to tell whether or not the federation members are actually separate entities and not in cahoots. Bitcoin Deposits creates a federation of custodians operator their own ledgers rather than a federation of guardians or members controlling a single chain. I think this aspect of it is interesting, but I'm not sure I see it being that much better than a fedimint model.

Here are some links for exploring this further:

FAQ Github Whitepaper Website