Currently for the service I built, I have a custodial wallet for each user where I store the privat data in my own database. With this new component, I plan to push all that private data encrypted out to relays with reference to mints and blossom servers. So the only thing I ‘custody’ is the nsec of that wallet instance I am holding that nsec on behalf of that user who ‘trusts’ me. . I will let the user have access to that nsec, if they want it, and if they begin to distrust me, they can sweep the wallet without my permission. 

As well, I am no longer storing any unencrypted personal data in my database server so that eliminates a big honeypot risk for me. As for availability, storing on redundant relay servers, is a big plus too. 

 Hmm this is cool but it doesn't address the actual custodial risk typically associated with ecash. 

 Which specific custodial risk are you referring to? 

 If anything, it mitigates risks that are beyond the custodian’s control, like having their infrastructure rugged. 

 The mint running away with the collateral 

 Agree. But that risk can be mitigated by using multiple mints and the ability to clear out to Lightning at a moment’s note. Also, by separating the mint operator from the service provider, it further mitigates a single point of failure risk. 

In the end, this architecture makes a mint like a money router - if one goes down, you can easily switch. Finally there are some neat reputation services appearing like bitcoinmints.com and nostr.watch that’s where I discovered reliable relays and mints that I can use.

Sooner or later, an organization will stake their reputation on running a reliable mint and/or relay. When that time comes, we’ll be able to manage our risks accordingly. 

 I completely agree with everything you've just said but let's just not errr on using terms like unilateral exit when they have a very well defined intent which doesn't apply here. 

 Fair point.  We’re experimenting with new concepts here, so the terminology might now be 100% so we need to iterate. In the mainstream context this would be called ‘data portability’, another great concept, but mostly used in lip service without empowering the user. This is the first instance where I see the possibility of keeping data private on behalf of a user, and where they are independently empowered to remove at any time. If find this very exciting and a complete game-changer for service providers that need to provide some custodial service but with creating a big breachable honeypot.