Major Crypto Icon Dies in Jail. What Will Happen to Their Assets?

Featuring today’s biggest Web3 UX problems & solutions

Peter Keay
13 min readJul 7, 2024

It’s a question not everyone wants to think about: Where will your hard-earned crypto assets go if something happens to you?

Death in jail isn’t the only disaster to protect yourself from, either. Recovery is important protection against many plausible events:

  • amnesia
  • coma
  • kidnapping
  • protracted jailtime
  • lizard overlord abduction
  • losing your hardware wallet in a boating accident.

Of course, if you lose all your funds, some people will, like a fundamental Baptist’s meanest Darwin impression, say your mishap is just “survival of the fittest.”

Or, at least, they’ll cheer silently at your deflationary contribution to all other holders on Earth.

“Lost coins are burned coins.”

This idea — that when you lose crypto, everyone else gains just a little — can even be reasonably defended as a “feature, not a bug.” It could level the playing field over time, preventing the wealthy from extending their power to their children.

I mean, Do Kwon once chimed in on the inheritance conversation with exactly this perspective.

He wasn’t just shitposting, either, though we may wonder how he feels about this these days. The tweet makes a valid philosophical point.

In fact, with the growing visibility of Neuralink, brain scanning, anti-aging, private space companies, and imminent trillionaires, the problem of “inequality becoming immortal” is the main drive of nearly every science fiction novel pitch I hear these days.

It’s top of mind in the futurist’s nightmare world. The billionaires don’t just get rocket ships, they get immortality cocoons or digibrains or whatever. And they get impenetrable self-repairing drone defenses that scan the Neuralink webs and assassinate you if you even think about unplugging anything.

This way, the billionaires can take their generation’s quibbles and foibles and force them on humanity forever.

Anyway, sci fi authors aside, this doesn’t really seem to be top of mind for anyone else. Nothing related to mortality and inheritance does.

After all, when we talk crypto inheritance, we’re taking views on death (which for many includes religious beliefs) and combining them with personal finances and politics. All into one issue. A massive, morbid melting pot of table-silencing taboos.

No wonder the problem hasn’t been solved yet. It’s barely even discussed. But it is definitely thought about.

©Oppenheimer, 2023. Universal Pictures. All rights reserved.

And even if you are one of the loonies like me who stay up at night thinking about Bezos Bunker Bots or a society eternally oppressed by the Gates Foundation — even if preventing inequality from becoming immortal matters to you — you probably still personally want to leave a little something behind for your loved ones, or for your later self, in case of disaster.

It is 2018 Pete���s pleasure, then, to introduce you to the Seven Hells of Security.

The Seven Hells of Crypto Security

I used to teach a sort of multi-leveled paranoia to any who asked for my crypto security recommendations.

With increasing certainty as you went down the list, the seven levels were designed to reliably cover all the disaster scenarios. Amnesia, incapacitation, kidnapping, coercion of loved ones, incoherent babbling of seed phrases while at the dentist, you name it.

The deeper you d̶e̶l̶v̶e go, the more resilient you are.

The seven hells may be unending torture, yes, but they are also hella good bomb shelters.

  1. Get a hardware wallet. Now you’re reasonably safe from phishing, hacks, etc. But what if someone with a wrench forces you to unlock it for them?
  2. Set a passphrase under alternate PIN. Now the original wallet is a decoy for duress situations. But… won’t they think an empty wallet is weird?
  3. Add a little funds to the decoy wallet. The decoy becomes more plausible. Ok, but what if they find my secret seed phrase paper?
  4. Reorder your seed words, with new checksum, and memorize. Destroy the written copies.
  5. Add a little funds to the recovery decoy. Ok. But now what if a wrench wound from an unknown source causes me to forget it, or worse?
  6. Set a couple of staggered dead man’s switches that email your reordered, encrypted seed words. Communicate the passwords to your loved ones. Don’t just pick one loved one; have a backup. Cool, but what if something fires off those emails early?
  7. Leave the reordering information and the actual passphrase from #2 in your will, or in something equivalent. Once again, have a backup in case the primary communication fails.

Most people I spoke with had only reached step 1.

That’s right. I’m 600% more paranoid than your average hardware wallet user.

My cofounder likes to tell others that my crypto recovery system is something involving a mysterious bomb-shaped package, instructions to go meet a guy in a raincoat at a London subway stop, and a series of wires to cut in the right order.

Honestly, the resulting National Treasure sequel would be far easier to navigate than Pete’s Seven Hells. Yet this was the only crypto inheritance and recovery solution I could devise which safely covered every single bad outcome I could think of.

Well, almost every bad outcome.

My system was difficult and time-consuming to explain, never mind implement and maintain. So, I’ve been eagerly following — and working on — better systems to replace it.

Over the years, three broad paths emerged to solving the inheritance/recovery problem in a way that could reasonably attract more people than just crazy tech hobbyists like me.

Recovery as a Service (Multisig)

The earliest inheritance solutions were, as you can imagine, something that was offered to wealthier people by service companies.

Casa was the standout in this category. They had an early bespoke Bitcoin solution, including video call identification with a duress keyword and multiple keys. (The service still continues to this day, in basically the same form, but with Ethereum included.)

I gave them a try for some time. There was definitely a higher-end feel to the product, at least at first. I received some hardware devices and some shielded pouches for wallets which almost passed RFID penetration tests but did leak a bit. I was excited about the meetups and perks they had, though they often failed to deliver on them.

Still, it was definitely cool to open up the Casa phone app and see a nice, secure ring of six keys. It took three of them to access my precious satoshis. Man, did that make me feel safe and sophisticated when I first saw those six colored icons.

The buzz quickly wore off.

  1. The personal service requirement was a bit annoying. Plus, it meant I was on a list somewhere of people willing to pay for the service, and a number of known employees had that list. “Hah, no way I’m going to jail for my clients,” one of those employees said to me.
  2. The price tag at decently secure levels (5 keys) could be more than your portfolio, especially if you are from a less expensive area of the world. At one point, at least, it was an absurd $5000 per year, and the additional perks which were promised as a part of the package were often not delivered on.
  3. More significantly, Casa customers were relying on a company. Even if you could recover your assets without the Casa company or app — which required not only keys but also a PDF of public keys that you hopefully stored securely — your inheritors may not have access to this, and the Casa product would become useless if the company or application were taken down.
  4. The multisig setup meant you had to rotate assets into a new setup if you ever had a key compromised.
  5. The convenience level for performing transactions was near zero. For some users, this is a feature, but not for most.

DeFi was starting to pick up by this point, and more and more people in the space were thinking about how to make comprehensive asset management possible without relying on (any paying for) a bunch of middlemen. Bespoke services couldn’t scale and were against the growing ethos of the industry.

Multi-Party Computation Networks

Multi-Party Computation, or MPC, allows multiple parties to work together to sign things with a private key, even though none of them knows (or has ever known) the whole key.

This way, in theory, none of the parties can act on their own to steal funds. In many setups, it’s also very hard for multiple parties to get together and steal funds.

MPC for Newbs

Imagine you must paint an area a particular shade of light orange to prove that enough of you have been to the spot. Let’s give you some incentive: if you paint that light orange, a locked door will open.

You have a red paint, a friend has a yellow paint, and your prison guard has a white paint. You could all together produce a very particular shade of light orange that none of you could create on your own.

Unless both of you and the guard paint the door, it just won’t unlock. There’s no way you can get the right shade without the guard.

Always be on the lookout for opportunities to turn a color wheel metaphor for cryptography into a side lesson on psychological abuse in privatized prisons.

If the warden is more generous with the colors, something like:

  • You have red and yellow
  • Your friend has yellow and white
  • The guard has white and red

Now any two of you can work together. This makes escape much easier; the guard is no longer required for every transaction.

But it also makes it easier to get cheated. If you failed to act fast enough, the guard could let your “friend” out for a bribe — and then keep you in prison indefinitely.

MPC allows a certain set number of the parties to work together in order to make cryptographic signatures. Each setup has a threshold — and the number of signatures must be greater than the threshold in order for a signature to be mathematically possible.

In a more realistic scenario, the parties could be your laptop, your hardware wallet, your partner’s laptop, and your lawyer. Perhaps three parties are required, so that you always need to call someone up in order to transact. This is more secure. You can’t be forced to transact on your own, and your partner and lawyer can’t get together and rob you. The more parties you add, the harder it becomes to steal your funds. But also, the harder it becomes to get anything done.

MPC networks follow numerous designs. Sometimes, they split their shares up among many, many nodes. The nodes then work together to sign transactions when needed.

This can be as expensive and as slow as it sounds, plus…

  • You have to trust the nodes not to collude
  • You have to trust the nodes’ hardware not to have an unknown vulnerability
  • You have to trust that the network’s operation will continue without a breaking interruption until you need recovery

So while MPC networks may be a piece of the puzzle, they have serious risks and limitations if used on their own.

Smart Accounts

Account abstraction has been in progress for years now, too, though the nerds involved were even less cool than the MPC nerds were. (More of the MPC nerds were spies.)

Thanks to their work, some smart account standards have emerged, but the space is still badly fragmented. Even within Ethereum, which is farther ahead on agreed abstraction standards than other technologies…

  • only some chains have smart account entry points deployed,
  • some have v0.6 but don’t have v0.7 yet,
  • some don’t have factory contracts for the smart account you want,
  • some haven’t yet adapted the technology for their unique EVM tweaks, and
  • some have implemented their own abstraction standards which are widespread or even universally applied to all of their users.
The Blog Authors’ Standards Manual states that I must drop XKCD #927 here.

Despite these challenges, account abstraction will, in some form and at some point in the future, be the way that the vast majority of users interact with blockchain applications.

Account abstraction will, in some form and at some point in the future, be the way the vast majority of users interact with blockchain applications. ~Click to Tweet

Account abstraction can turn your crypto user experience — a labyrinth of assorted gas fees, seed phrases, network latency, and dozens of opaque wallet errors and mysterious signature popups — into a smooth evening stroll down a lakeside path.

Since insufficient fees is one of the worst offenders, much of the focus in account abstraction discussion is on fee abstraction: covering gas fees for users. Second to that is bundling transactions, meaning more efficient use of block space, meaning reduced congestion and fees.

But account abstraction is much more powerful than just fee abstraction and paymasters.

Transaction Policies

Account abstraction also enables accounts to have rules, and this is essential for large user bases. Transaction policies suddenly make it simple to offer users many things, including but not limited to:

  • Budgets, allowances, automatic subscriptions
  • Lists of criteria which allow, block, or delay transactions, or which cause them to trigger other events
  • Session keys (sign once to log in, then enjoy a convenient session), including limitations and restrictions on what they can do
  • Recovery, increased security and cryptographic future-proofing, and inheritance
Some guy telling some students in a CS program about account abstraction.

Yes, this probably means that specific technical solutions for subscriptions, inheritance, session keys, DAO treasury rules, and so on will quickly become obsolete, or at least be thrown into a fight for their lives. They will be superseded by smart account standards. Smart accounts provide these capabilities out of the box, in a more flexible way than the bespoke solutions ever did.

Bespoke technical solutions for crypto subscriptions, inheritance, session keys, and treasury management will soon be fighting for their lives. ~Click to Tweet

But even with the most optimistic roadmaps completed, smart accounts alone will not actually provide ideal setups for any of these.

Most notably, smart accounts only have policies for activity on one chain at a time.

Meaning you have to set up and update your policies — including inheritance — on each and every chain individually. Early account systems which tie these together either have weaker trust assumptions or require you to endure some (often considerable) latency in order to do what you want to do.

Additionally, conventional smart account transaction policies are public.

Keeping all the rules public for how you plan your money to be used is not desirable. Not when it comes to subscriptions, not when it comes to recovery, and especially not when it comes to inheritance plans.

Here are but a few reasons:

  • Telling your beneficiaries and non-beneficiaries the details of your inheritance arrangements will immediately, irrevocably change all of those relationships.
  • Somebody might actually take action based on this information. Action designed to manipulate or coerce you, or even prematurely activate your inheritance.
  • Worse, people you don’t know at all might mount any number of potential attacks based on this information — attacks on you, your systems, your loved ones, you name it.

Some things just shouldn’t be required to be public.

In fact, insurance solutions using immutable blockchains without private or provably enforced off-chain policies may be in immediate violation of GDPR and similar privacy regulations, making it supremely difficult for companies to legally offer smart account products.

So MPC networks and account abstraction both have limitations when it comes to fixing Web3 user experience. But what if…

Account Abstraction + MPC Helper Networks

Some MPC networks offer transaction policies, with or without using smart account standards directly.

Transactions can be checked by the MPC network itself to see if they meet the rules. If the rules aren’t met, the transactions aren’t signed.

Some early attempts at this kind of network offered transaction policies, so that signatures could only be obtained when the user’s rules were followed. This did in fact remove a few of the concerns with using MPC networks. However, many of the concerns still applied: concerns like latency, downtime, and trust assumptions.

The latest development in this field, Signet, attempts to remedy these faults of earlier systems by only requiring communication with a Signet network or service in order to finalize signatures.

The network doesn’t have enough power to act on its own, which means the network nodes couldn’t steal your funds even if they all colluded against you. And signature finalization — used to finalize a signature process which is almost complete but can be done without the network involved — can be done as a pure view or query function.

Meaning that if the network is down, recovery still works.

Private Transaction Policies with TEE

In addition, Signet can enforce completely private transaction policies, which is paramount for user security and for institutional adoptability.

Transactions can be checked against your policies without revealing what they are. No one, including network nodes, can view these policies, as they are enforced in an isolated, secure execution environment.

Meaning that only a particular piece of the hardware is able to read and enforce policies. The rest of the node sends in an encrypted request, “Can you help finish signing this transaction?”, and receives the signature in response — or a rejection, simply saying the policies are not met.

In our specific case, the policy might be “my son gets 30% after 6 months of account inactivity, a charity gets 20%, and my siblings get 1% per month after 12 months of inactivity.” But until the inactivity period passes, there’s no way for any party besides the user to figure out exactly what policies are active.

Private inheritance policies are a critical capability. And this doesn’t just apply to your individual user looking for the best inheritance solution.

Wider adoption, standardization, and insurability will never happen without the ability to keep certain things confidential.

Meaning that without capacity for private policies — private even from node operators — Web3 UX will never be ready for widespread use.

Without capacity for private transaction policies — private even from node operators — Web3 UX will never be ready for widespread use. ~Click To Tweet

Signet and other technologies are fixing Web3 user experience by making gas fee errors, seed phrases, bridge troubles, and loss of funds problems of the past. With transaction policies come automatons, too: non-custodial Zapier-like shortcuts and AI agents for web3.

But that’s for another post.

Once using them is easier and safer than using Web2 applications ever was, I can’t wait to see what Web3 applications can do.

By the way, you can comment on the Signet whitepaper directly at https://docs.google.com/document/d/1Tdc8-2bZ2DdNX_oVD1h_mIretjDSKZHny07W4BcG4xM. Comments which are adopted will retroactively earn points for the commenter’s Signet wallet after points are launched 🤫

Visit Obi.money | Contact Pete on Twitter

--

--

Peter Keay

Rust/C++/WASM smart contract dev || Creative || Writer