Nash has rolled out an update to its wallet system, allowing signatures to be generated using the same secure multi-party computation tools that power its decentralized API keys. The solution serves the same role as a hardware wallet, providing a method for approving transactions without needing to directly use a private key.
When a user creates an account with Nash, a master secret is created in the account holders browser and used to create the private keys for all blockchains supported by Nash. Using an MPC key generation protocol, two sub-keys are created from each of these private keys, one sub-key being sent to Nash, the other kept by the user.
These keys can sign data independently which when combined will produce a signature equivalent to a signature from the original private key. This protocol, called a threshold signature, ensures that both sub-keys are needed to sign and, as in a hardware wallet, the private key itself is never exposed.
The advantage of this two-party system for authorizing transactions is that it enables users to define their own security settings for the platform to enforce. This could take the form of whitelisting certain addresses, setting withdrawal limits, or disabling certain functionality such as trading. Essentially a user would be able to tell Nash when (and when not) to use its sub-key to authorize a transaction.
This functionality is argued to provide “safer than hardware” security. If a user’s Nash account is compromised, the damage the hacker can do is limited based on the security policies in place. The user can log in to their account and revoke the compromised sub-key.
As a non-custodial platform, Nash does not ever have access to the user’s secret information, it cannot issue its own transactions. If the user can’t access Nash for any reason, they can still use their seed phrase or private keys with other third-party wallets.
More information and an in-detail technical overview of Nash’s MPC protocol can be read in the original article: