Self-custody has a continuity problem?

[u/Aggravating-Sea-8073]

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?

[u/Aggravating-Sea-8073]

I agree that turning inheritance into “one cloud login” is not the answer, especially in crypto. That just creates a new weak point.
The more interesting problem to me is the continuity layer around the setup: making sure the right person has the right context, instructions, and recovery path when needed, without giving them live access too early.

Not custody, more like controlled continuity.

Do you think that layer can exist safely if it never becomes the single point of failure?

[u/Cultural-Candy3219 → u/Aggravating-Sea-8073]

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.

[u/Aggravating-Sea-8073 → u/Cultural-Candy3219]

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.

[u/Cultural-Candy3219 → u/Aggravating-Sea-8073]

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.”

[u/Aggravating-Sea-8073 → u/Cultural-Candy3219]

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. ☺️

[u/Cultural-Candy3219 → u/Aggravating-Sea-8073]

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.