seed words

Developers are working on ways to get rid of seed words and even private keys, while still keeping users in control.

The foundation of the Web3 ecosystem is the wallet, an app or browser extension that lets users verify their web identities and authorize transactions. But using a wallet has always involved a steep learning curve. New users must learn to copy down their seed words and store them in a safe place, create a strong password to encrypt their keystore file, copy addresses accurately when sending funds, and other things they may never have to learn when using a Web2 app.

If a new user wants to make onboarding more accessible, one option is to use a custodial wallet provider, such as a centralized exchange. But experienced crypto users will almost always caution them against this for a good reason. The world has witnessed centralized exchanges like Mt. Gox, QuadrigaX and FTX go bankrupt from hacks or outright fraud, causing some customers to lose all their funds due to using a custodial wallet.

Because of this risk, many crypto users still see a noncustodial wallet backed up by a set of seed words as the only secure way for a user to protect their Web3 identity.

But do users always have to choose between security and convenience? Or is there a way to combine a noncustodial wallet's security with an exchange’s convenience?

A few Web3 companies are trying to create wallets that are easy to use but also don’t require the user to place all their trust in a centralized custodian. Companies like Magic, Dfns, Kresus, Web3Auth, Immutable and others believe that a wallet can be just as easy to use as an email account, and secure enough to be trusted to protect the user’s identity and funds. These companies are using different types of new wallet infrastructure to make this idea a reality.

Here is a rundown of a few of the solutions used by wallet developers:

Magic

One new system is the Magic software developer kit (SDK), produced by Magic Labs. It is a developer kit and wallet infrastructure that allows developers to create seedless wallets for users.

Instead of storing the private key on the user’s device, an encrypted copy is kept on an Amazon Web Services Hardware Security Module (HSM). The encryption is performed using a Master Key that cannot leave the HSM. All signing is done within the HSM, preventing the user’s key from being broadcast to the internet.

Magic wallets do not use passwords. Instead, when users first sign up for a magic wallet, they submit their email address to the Magic relayer. The relayer then sends a one-time use token to the user through their email. This token will only work if used by the device that sent the request and only for a limited time.

The token is used to authenticate with Amazon Web Services when the user clicks a link within the email. The blockchain wallet account’s private and public keys are then generated on the user’s device and sent to the HSM. Magic Labs says they cannot see the generated private key, as it never goes to their servers.

When users stop using their wallets and close their browsers, they can reopen their wallets by repeating the process. They submit their email address to Magic again and receive a new, one-time-use token. This time, after authenticating, they regain access to their wallet.

Magic Labs has created a demo showing how the system works. It appears to allow anyone to create a wallet without downloading a browser extension or copying down seed words. It also allows users to close out their browsers and return to their wallets later, logging into the same Web3 account again.

The demo currently only works on testnets such as Goerli, Sepolia and Mumbai.

Wallets based on Magic

A few different wallets have been released or are currently in development that use Magic. One notable example is the Kresus wallet, a mobile app that allows users to store and hold Bitcoin (BTC), Ether (ETH), Solana (SOL), Polygon (MATIC) and tokens from these networks. It also allows users to send crypto using .kresus domain names instead of crypto addresses.

Kresus was released in the Apple App Store on May 11. The team told Cointelegraph that an Android version would come later in 2023.

Immutable Passport is another example. It’s an application programming interface (API) built by Web3 game developer Immutable. When participating games integrate their websites with Passport, it allows players to create wallets directly through the game’s site.

Related: What is Immutable, explained

Immutable told Cointelegraph that Passport wallets connect to the Immutable X network, a layer-2 Ethereum protocol, which allows players to store all of their Immutable gaming collectibles in one account, regardless of which game they initially signed up with.

Immutable recently implemented Passport as the default login method for its developer portal, and they plan to use it for at least one game’s login page by summer 2023, the team said.

Security concerns with Magic

The Magic SDK does contain one known security flaw, which developers have taken steps to mitigate. Because it relies on email tokens to authenticate a user, an attacker can potentially gain access to a user’s HSM by hacking into their email account and then requesting to authenticate from the attacker’s own device. Once they’ve got access to the HSM, they can authorize any transactions from the user’s account.

For this reason, both Immutable Passport and Kresus plan to use two-factor authentication (2FA) as an additional layer of security in case a user’s email account becomes compromised.

Wallets based on Magic do not have passwords, so they can’t be hacked through the usual method of stealing and cracking a password hash.

Web3Auth

Another new wallet infrastructure developers are often using is Web3Auth.

Web3Auth is a key management network that relies on multiparty computation (MPC) to make private keys recoverable. When users sign up for an account using Web3Auth, they generate a private key as usual. Then, this key is split into three “shares.” 

The first share is stored on their device, the second is stored by the Web3Auth network through a login provider, and the third is a backup share that should be stored on a separate device or offline. The third share can also be generated from security questions if the user prefers.

Because of the way multiparty computation works, a user can generate the private key and confirm transactions with only two of the three shares. This means the user can still recover their wallet if their device crashes or they lose their backup key. At the same time, the login provider cannot perform transactions without the user’s permission since the provider only has one share.

The provider also cannot censor transactions. If the provider refuses to give the user their second share after they’ve correctly authenticated, the user can generate their private key using a combination of the share stored on their device plus the backup share.

Related: Multiparty computation could offer increased protection for wallets

On Web3Auth, the login provider share is further split into nine different shards and distributed across a network of storage nodes, with five shards being needed to reconstruct the provider share. This prevents the login provider from storing its shares on its own infrastructure.

Web3Auth wallets

Web3Auth has been integrated into several retail wallets, including Binance Wallet and a closed beta version of Trust Wallet. In the extension version of Binance Wallet, users can create wallet accounts using their Google logins. In the Trust Wallet version, Google, Apple, Discord and Telegram are login provider options, according to an official video from Web3Auth’s Twitter account.

In either case, the user still needs to copy down seed words. However, the account can be recovered even if these words are lost, so long as the user still has access to both their device and login provider account.

Speaking to Cointelegraph, Web3Auth CEO Zhen Yu Yong argued that the transition to using multiple key shares in Web3 is similar to the evolution of 2FA on Web2 sites, stating:

“Usernames and passwords in the early 2000s or late 1990s were incredibly easy to lose. Back then, we thought that financial applications would never be built on the internet.”

“With usernames and passwords, we eventually progressed into two-factor authentication,” Yong continued. “I think that’s the same transition we’re trying to push here [...] Instead of using a single factor seed phrase, we’re splitting this up into multiple different factors […] and doing it such that it’s all your access points, so it’s all still self-custodial.”

Dfns

Dfns, pronounced as “defense,” is an MPC key management network that allows institutions, developers and end-users to create passwordless and seedless wallets. It holds each blockchain’s private key as multiple shards spread among nodes throughout the Dfns network.

To authorize a transaction, the Dfns nodes must jointly produce a signature using each shard.

Unlike Web3Auth, Dfns does not keep a share of the blockchain private key on the user’s device or as a backup. All of the shards are kept on the network itself.

The Dfns nodes use a protocol called “WebAuthn” to verify that a user has authorized a transaction. This protocol was created by the World Wide Web Consortium to allow users to log into websites without a password. On Dfns, the nodes are programmed only to sign a transaction with their shard if the end-user has authenticated using this protocol.

When a user registers for a website using WebAuthn, the site creates a private key on the user’s device. This private key is not used in any blockchain. It only exists to allow the user to log in to the site.

The user is prompted to protect the key with a pin code or biometric lock when the key is created. On a Windows PC, this lock can be created through Windows Hello, which is part of the operating system, or through a separate device such as a mobile phone or Yubikey. On a mobile device, the lock is generated using the device’s built-in security.

On a website that implements WebAuthn registration, the user does not need an email address or password to register. Instead, the device uses its own security system to identify the user.

Related: Gemini unveils Yubikey integration

When a wallet development team creates a wallet using Dfns, they can pass down this authentication method to the end-user. In this case, the wallet is considered noncustodial because the wallet provider doesn’t have the user’s device, pin code or biometric data and therefore can’t authorize transactions.

The end-user can also add devices to a wallet if the first one crashes.

Wallet developers can create custodial wallets using Dfns as well. In this case, the wallet developer has to authenticate with the network using WebAuthn. They can use any method to authenticate a user with themselves, including even usernames and passwords.

Wallets that use Dfns

Speaking to Cointelegraph, Dfns founder Clarisse Hagège stated that many of the platform’s clients are institutions and development teams in the business-to-business market.

However, the team has begun to attract more business-to-consumer wallet providers recently. The retail crypto savings app SavingBlocks uses Dfns, and the company is in talks with a couple of decentralized exchanges to help create wallets for their customers as well, she said.

Hagège argued that for crypto mass adoption to happen, users shouldn’t even be aware that there is a blockchain private key when they make transactions.

“What we’re targeting is the hundreds of thousands of developers that will build use cases targeted to blockchain mass adoption, targeted to people that do not want to know that they have a private key,” she explained. “We have a network of servers that operates that key generation […], and what’s important is not actually owning the private key or the key share, but it’s owning the access to the API.”

Will new wallet tech be adopted by the masses?

Whether these new wallet technologies will lead to mass adoption or even be accepted by current users remains to be seen. Despite their simplicity, they may still be too complex for users that prefer to hold their crypto in an exchange. On the other hand, users who believe in the “not your keys, not your crypto” mantra may be suspicious of trusting an MPC network or hardware security module owned by Amazon to authorize transactions for them.

Still, some users may decide that the advantages of MPC or magic links are just too good to pass up. Only time will tell.

In the meantime, these new technologies will likely provoke discussion about how to ensure users stay in control of their funds or what “self-custody” really means.