Self-custody wallets and the support burden

There is a category of support ticket that has no resolution. A customer writes in, politely at first, to say they have lost the recovery phrase they wrote down when they set up the wallet. They can see the balance sitting on a public block explorer. They cannot move it. Nobody at the company can move it for them. The second email is less polite.

We built DigieCash as an Ethereum-based wallet where users hold their own private keys, transfer tokens peer to peer, and convert between electronic currencies. Custody sits in the client, so a balance never depends on a central ledger. That is the product working exactly as designed. It is also a decision about what a support team is able to do on a bad day, and it should be made with that in mind.

Custodial support is repair work. Self-custody support is prevention.

An operator holding custody has tools. Reset the password, freeze the account, reverse the credit, reissue a balance from its own books. Support in that world is largely repair, and a team can reasonably be measured on how quickly it fixes things. Take custody away and every one of those tools goes with it. The work does not disappear. It moves to a point before the mistake: onboarding, backup verification, the confirmation screen on a first outbound transfer, the wording of a warning.

Teams under-budget this consistently, because prevention does not look like support on an org chart. It looks like product design, copywriting and education. The bill still arrives, in the form of tickets nobody can close.

Decide the recovery story before launch

There are three honest positions on recovery, and each one costs something.

• Recovery phrase only. Clean and cheap to build, and irreversible loss becomes a real outcome that has to be stated plainly during onboarding rather than buried in terms nobody opens.
• Social or multi-signature recovery. Removes most single-point loss, and adds a coordination problem, fresh attack surface, and a support queue of its own about guardians who have changed phones.
• An optional custodial backup. Comfortable for users, and it puts the operator back inside the regulatory perimeter it was trying to stay outside of.

Any of the three can be the right answer for a given product. What fails is reaching launch without having chosen, then improvising a position in a live support thread while a customer is losing money.

Put the friction on the irreversible steps

A transfer to a mistyped address is final. So is a send on the wrong network, or of the wrong token to a contract that has no idea what to do with it. Friction is the only tool available, and it works only while it stays rare. A modal that appears on every transaction is trained away inside a week. A confirmation that appears the first time an address is used, spells the amount out in words and offers a small test send first, gets read.

Address book management is in DigieCash for that reason. Choosing a saved recipient removes an entire class of unrecoverable error, and it is the least interesting feature in the product.

What the queue actually contains

Most tickets are ordinary. What a pending status means. Why a fee moved. Which rate applied at the moment of a conversion. How an e-voucher gets redeemed. Those are answerable, and decent documentation removes a fair share of them before they are raised. The remainder are people in distress, and the training that matters there is about honesty. An agent who implies a fix might exist buys a week of hope and then a formal complaint. Saying plainly and early that the funds cannot be recovered is the kinder answer, and it has the advantage of being true.

The useful measure of a self-custody support function is how few of its tickets concern money that has gone somewhere it cannot come back from. Response time barely registers by comparison.