Adding and Removing Users at Four Wallet Providers

Companies add and remove people constantly. We tested how four wallet providers handle it, including what remains after someone is removed. It is worth having an institutional crypto wallet open while reading, because the published numbers are what we tested against.

Adding a user

All four straightforward, between two and eight minutes.

Two required the new user to complete their own identity verification, which is correct for a provider holding assets and adds a day.

Two added the user immediately on invitation, which is faster and means the provider does not know who has access.

Removing a user

Here they diverged.

Two revoked access immediately and invalidated existing sessions.

One revoked access but left an active session working until it expired, which was several hours. A removed user could still view and initiate during that window.

One removed the user from the interface and left their API key active. We found this by testing the key after removal and it still worked.

That last case is a serious gap and it would not be noticed by anyone who did not deliberately test for it.

What remained after removal

We checked what a removed user’s activity left behind.

All four retained the audit trail correctly, showing actions by a user who no longer exists.

Two left addresses added by that user on the allowlist without flagging them. That is the gap a departure procedure has to close manually.

One left the removed user as a designated approver in a saved approval rule, which meant that rule could never be satisfied. We discovered this when a payment stalled.

The multi-signature complication

At the one provider using a multi-signature arrangement where we held keys, removing a user meant rotating the key set, which meant moving funds to a new arrangement. At company scale the measurement changes, and a provider serving funds and family offices is what we compared against there.

That is inherent to the design rather than a provider failing. It is also real work and real cost, and it is why key rotation on departure gets deferred.

What we would do

Test removal before relying on the provider. Remove a test user and then attempt to use their session and their API key.

Build the departure procedure to include reviewing addresses they added and approval rules naming them, because no provider did this automatically. The variable we could not test in advance is support under pressure, and whether a regulated crypto exchange exists is worth establishing early.

And for multi-signature arrangements, budget for rotation on departure rather than treating it as an exception.