Is This Vendor Lock-In? Leaving With Your Keys Is Trivial. Leaving With Your Identity Is Not.

Lock-in is the cost of leaving, and every wallet has some. This page measures ours and names no other product, because a comparison would be the wrong instrument for a question about us.

The answer splits cleanly in two, and the split is the useful part.

The portable half, which is genuinely portable

Your recovery phrase is a standard format. Twelve or twenty-four words from the standard wordlist, generated on your device from a cryptographic random source. Any conformant wallet accepts it.

And your external addresses use the standard derivation. The Ethereum path we derive is the ordinary one, which is precisely why importing a real phrase here is dangerous and equally why exporting works: the same phrase in another wallet produces the same account.

So the value half of this wallet has essentially no exit cost. Write the phrase down, type it somewhere else, and you are gone. Nothing about that requires our permission, our servers or our continued existence.

The bound half, which does not move at all

Nothing outside can resolve it. There is no resolver driver for our method, so third-party tooling pointed at the standard aggregator gets nothing, and a direct call is a bespoke integration.

Your guardian set lives on our chain. Setting a recovery policy writes it there, so the arrangement protecting your identity is bound to a network we operate.

Your credential catalogue is in our database. The wallet holds a catalogue rather than the credentials, so there is no file to take with you, and what you would be exporting is a list rather than the objects.

And you cannot read the chain without us. The browser never contacts it, so even the state that is public is reached through our relay.

Why the split is the honest answer

A control makes this a measurement rather than a posture: CONTROL that makes this a measurement rather than a posture: the two halves resolve differently under the same question. If everything were portable, or everything bound, the exercise would be marketing with a sign attached.

We inherited the portable half from a standard and built the bound half ourselves. That is not an accusation, it is the ordinary shape of building on a chain, and it explains the asymmetry exactly: where a specification already existed we are interoperable, and where we defined something we are the only implementation.

What is already built, because absences alone would misdescribe us

The credential format we emit is a published standard, so an artefact leaving here is verifiable by any conformant implementation with the issuer's key and no code of ours.

The identifier method is registered in the W3C DID Method Registry.

And the phrase, the derivation and the signature scheme are all standard or specified, which is why the portable half is portable at all. That is real, and it is the half we did not have to invent.

What we could do about it, in order of honesty

Publish a resolver driver. Small, well-specified, and it moves third-party resolution from impossible to routine.

Store the credential body where the holder controls it. That converts a catalogue into something exportable and is a prerequisite for several other things this estate has found missing.

Expose a proof method and a client that verifies, so reading does not require trusting us.