TL;DR
- “Vendor lock” in MPC based custody products occurs when secret shares (the shards of the private key created with MPC) are held by the infrastructure vendor.
- This is a common model today, used by SaaS MPC infrastructure solutions.
- Due to the severe potential consequences, companies building a wallet or custody product should avoid being vendor-locked at the key management layer.
- Self-hosted MPC infrastructure offers a different model, that combines the advantages of SaaS MPC products with full operational independence, including real no vendor lock.
Introduction
Every company dreads the idea of becoming highly dependent on a crucial vendor. The sheer thought of undergoing a major migration process that will paralyze the company for months or a sudden price hike they are forced to accept, is a frequent nightmare for every business or product owner.
That’s why the phrase “no vendor lock” has become a common buzzword in marketing materials, although, in many cases, it’s merely lip service.
In crypto custody, and MPC products specifically, vendor lock is extremely painful and yet very common. Tales of nightmarish migration stories from companies like Curv or Unbound Security are still being told around Web3 campfires.
The reality is that migrations from critical services happen. Whether due to an acquisition, discontinuation of service, a superior offering from an alternative vendor, or in a small space like Web3, moving away from a vendor since it became a competitor. One thing is certain - whatever the reason, the migration is always painful.
So, when is it essential to avoid being vendor locked? To answer, let’s first define what it means to be vendor-locked. The main criterion we suggest is the effect on the end users should a migration process take place.
“No Vendor Lock” in SaaS MPC Infrastructure Solutions
In previous blogs we discussed in detail the disadvantages of SaaS MPC infrastructure solutions, which hold shards of the private key created with MPC, including vendor lock. Although many claim their solution has “no vendor lock”, in practice it means they offer a feature called “Key export”, which enables end-users to reconstruct the MPC shares to a full private key and export it to their device.
“Key export” is a handy feature to allow a specific end user a way to exit the wallet product. A basic and important feature in self-custody products. That is also a valid selling point a wallet provider can market to end users.
However, this feature is widely misused in marketing claims of infrastructure vendors as providing key management infrastructure with no vendor lock. A good analogy for using key export for a full-fledged migration of all end users to another vendor is of pulling out endless cactus spines from your hand.
Since the key management vendor holds one secret share for every end-user in this model, the process of a wallet provider migrating its end users to another MPC based key management vendor, requires reconstructing the key and transporting it, for each end user. Therefore, a migration process will typically look something like this:
Migration process using “Key export”
- Running a script that will export the full private key of each end user to its device.
- This script requires the active participation of each end user, so only when a user connects to the wallet and approves it, the process will be initiated.
- After the export script ends, another script will need to import each private key to the new vendor’s software, split it again into secret shares according to the new vendor’s MPC scheme, and store it.
- This will be a rolling, long, and tedious process until all the users complete it (if ever), consuming major resources from across all departments of the unfortunate wallet provider.
And that is the happy flow. In an unhappy flow, many things can go wrong and turn the process into a death blow: whether the old vendor doesn’t or can’t play along, export/import processes malfunction, users lose access, funds are lost or the users need to manually transfer their assets to an intermediate wallet during the process.
And if the happy flow works? Still, major problems await. Since the private key was reconstructed into a single piece at a certain point, the security assumptions of MPC were broken. Since the private key existed as a single point of failure, there are no assurances that it was not compromised somehow or saved by the end user in an insecure way during the process. Therefore, even if the new vendor will take the risk of being accountable for stolen funds associated with them, insurance companies will not. Eligibility to any insurance coverage that relies on the MPC security promises will be lost.
The only way to restore the security of MPC is by issuing each user a new public address (and a matching private key) and transferring the funds. This is not only a sensitive and nerve-wracking operation, but also a very expensive one due to gas fees. Of course, end users who need to close financial positions or lose eligibility to airdrops or other Web3 address-based eligibilities will demand compensation or take legal action.
To summarize: if a migration process to another vendor will badly affect all of your users, require months and months of work, and is expected to hurt your business and customer base - you are most definitely vendor locked, even if your vendor claims otherwise.
“No Vendor Lock” in Self-Hosted MPC Infrastructure
So what does “no vendor lock” in digital asset custody actually look like? Let’s look at how a migration process will look like with a self-hosted MPC infrastructure vendor. In this model, the vendor does not hold a secret share and doesn’t participate in the process of generating keys or signing transactions. Therefore a migration process will look very different:
Migration process from a self-hosted MPC infrastructure vendor
- The new vendor will run a compatibility script that will transform the secret share/s format on the server side to the new format, as well as the share on the end user side.
- Since the old vendor is not holding a secret share, the migration process can take place without a need for his involvement or active participation.
- The private key is not reconstructed at any point. Hence, the MPC security assumptions will not be broken. The end users can keep the same public address, with the same level of security.
In this process, the end users are hardly affected, and the process is significantly lighter. It does of course require the new vendor to be knowledgeable. Therefore, carrying out a solid due diligence process is always necessary.
Conclusions
To summarize, let’s return to the question regarding when it’s essential to avoid vendor lock. We suggest distinguishing between two scenarios:
- SaaS MPC wallet solutions are great for companies that simply manage their digital assets or offer their users a wallet as a part of their ecosystem. It would be ideal not to be vendor-locked, but that is a point to consider as a part of a pragmatic trade off.
- For wallet providers or custodians, whose wallet offering is their main business - We believe it’s worth avoiding vendor lock at the key management infrastructure level, at almost any cost.
Self-hosted MPC infrastructure offers a model that combines the advantages of SaaS MPC products and maintaining full operational independence, including real no vendor lock.
For more information about "Vendor lock", feel free to reach out.
