I love how people are combining all these different pieces to make things.

Here we have an idea for setting up a timelock on a mint's uxtos (similar to how Liana does inheritance timelocks) such that if the mint does not process withdrawals for a specific number of days, a second mint could process withdrawals from the first mint. You could even chain it further so that there are more fallback mints as more time goes by.

While the mint is in operation, it maintains unilateral control over the mint reserves. However, if the mint becomes unresponsive, the delegate mint can take over control of the funds and process withdrawals for the original mint's users.

A mint can delegate to multiple other mints. If a set of mints all act as delegates for eachother, they collectively inherit 1-of-n liveness properties. As long as one mint in the set is able to remain online, the users of all mints in the set are able to redeem their funds.

If you then combine this idea with the concept of running a mint in a TEE (#1498908) you might be able to limit some of the risk of the mint losing access to everyone's bitcoins by timelocking the utxos and letting a different mint take over after a specific length of time.

If Mint A disappears, loses its reserve key, or stops operating, it can no longer roll the reserve. After 7 days, Mint B can claim the funds. If Mint B fails to act within 24 hours, Mint C can claim them.

The main cost of such a scheme is that in normal operation mints need to "roll" or "refresh" their timelocked utxos before the timelock expires.

This takes care of the onchain part of the mint, but what about the ecash side (how would the delegate mint know whose bitcoin is whose)?

The delegate mint needs the original mint's spent-proof state to be able to issue redemptions without accepting tokens that have already been redeemed.

This is solved by Mint A publishing its internal feed of spent proof identifiers. Delegate mints watch this feed all the time and keep a local copy. This ensures that if Mint A disappears, the delegate mints already have an up-to-date copy of the mint state to be able to safely take over operation of the mint.

I think there are a few other things that might need to change about Cashu in order for this to really work well:

Normally, to verify a proof, the mint's private key is needed. This will not work in this case since, if Mint A is in operation, it is not safe to share its key with delegate mints. And if it is no longer in operation, we cannot rely on it to be able to share its key. We need the delegation process to be non-interactive between mints.

This requires an ecash scheme that supports public verification of proofs against mint public keys. DLEQ proofs, as described in NUT-12, can provide this, but full third-party verification requires revealing the blinding factor, which weakens privacy. A BLS-based ecash scheme with public verification avoids this tradeoff. Cashu is moving in this direction, which would make this delegation flow cleaner.

But it's a cool vision: a chain of mints, running in TEEs, that can act as backups to each other so that they are much more difficult to rug and unlikely to just go down take your bitcoin into the fire with them.