The thing you keep coming back to â not having to expose every key just to spend â is exactly what a key-path Taproot spend gives you. When the signers aggregate their keys into one, the spend looks like an ordinary single-sig payment: one Schnorr key on chain, and an observer can't tell it was multisig or how many keys stood behind it. MuSig2 does this today, but it's n-of-n only (every signer has to sign), so it doesn't cover your 2-of-3.
The piece that covers k-of-n is FROST (threshold Schnorr). It produces a single aggregated key for any t-of-n, so a 2-of-3 spend reveals nothing about the individual pubkeys, or even that a threshold was involved at all. It's real â IETF standardised it as RFC 9591, the Zcash Foundation's frost-secp256k1-tr library hit v3.0 this year, and someone just published an offline FROST Taproot wallet (ChillDKG for the key generation). The honest catch: it's early. The tooling is unaudited, the Bitcoin-side specs are still drafts, and no mainstream or hardware wallet supports it yet. So it's the right answer architecturally, not something I'd move real funds onto this week.
On the spending-race / quantum worry a couple of replies raised â worth separating those. A key-path Taproot spend exposes exactly one key at spend time, the same as a normal single-sig payment already does; it isn't uniquely worse than what you do every time you spend now. The P2WSH case is the one that dumps all the cosigner keys at once. So moving to aggregated signing actually reduces your exposure â it doesn't add a quantum problem, since that risk is identical across every current Bitcoin spend the moment a key touches the chain.