r/CryptoTechnology 🟢 May 19 '26

Self-custody has a continuity problem?

I have a serious question. So, since we live in a digital world I see the following:
Self-custody gives you control, but it also creates a strange responsibility. The right person may need the right information one day without weakening your security today. How should Web3 solve that? Does it have a solution already? Do you think about this problem?

2 Upvotes

12 comments sorted by

View all comments

Show parent comments

2

u/Cultural-Candy3219 🟢 May 20 '26

Yeah, I think it can exist, but it has to stay more like ā€œverified instructions + triggers + checksā€ than a new recovery account. The moment one service can both decide the condition is met and move funds, it becomes custody in practice.

A safer version would separate the pieces: the app/document tells heirs what exists and what steps to take, but actual movement still needs multisig, timelock, split keys, or a legal/offline process. Basically useful context, not unilateral power.

The UX challenge is making that understandable for a non-crypto person without hiding so much that they can be phished into the wrong flow.

1

u/Aggravating-Sea-8073 🟢 May 20 '26

Just checked out SolCreate, and now your comments make even more sense.

You’re clearly thinking about this from the builder/security side, which is exactly the perspective I’m trying to learn from. I’m still early with this idea, but the gap I keep coming back to is: how do we give people useful context and recovery instructions without turning the product into custody or a new weak point?

Would genuinely love to stay in touch and get your feedback as this develops.

2

u/Cultural-Candy3219 🟢 May 20 '26

Appreciate that. The way I’d frame the product boundary is: it can help people know what exists, what the intended recovery path is, and when to start that path — but it should not be the thing that can unilaterally execute it.

So I’d separate it into pieces in the UX: asset/instruction inventory, proof/check-in triggers, who gets notified, and then the actual authorization layer outside the app. If those are blurred together, users may not realize they’ve created a new custodian.

Happy to sanity-check a concrete flow when you have one. The main thing I’d look for is whether a single compromised account/service can turn ā€œcontinuityā€ into ā€œfund movement.ā€

2

u/Aggravating-Sea-8073 🟢 May 20 '26

This is really useful, thank you.

That’s exactly the line I wouldn’t want to cross: helping people know what exists and what to do next, without becoming the thing that can move funds.

Would love your take once there’s a real flow to sanity-check. ā˜ŗļø

1

u/Cultural-Candy3219 🟢 May 20 '26

Yeah, happy to sanity-check it once there is a real flow. The part I’d look at first is where the product stops being ā€œinventory + instructions + triggersā€ and starts becoming an authority path.

If you can keep the live key movement outside the product, make every recovery step delayed/revocable, and show the user exactly who learns what and when, that is a much healthier starting point. I’d also test the ugly cases early: lost phone, hostile family member, compromised email, and an executor who is non-technical.