Seedless Self-Custody: On MPC and Smart Contract Wallets

Nichanan Kesonpat
Published in
14 min readNov 16, 2022


Self-custody has long been heralded as a best practice for managing cryptoassets. The unraveling of FTX and Celsius are the latest in a long list of incidents that remind the industry “not your keys, not your coin”, triggering a flight to non-custodial wallets. Following the revelations around FTX, Safe saw $800M+ of net inflow, Ledger experienced multiple all-time highs in sales in short succession, Trezor sales surged 300%, and ZenGo had triple-digit growth overnight and high ATHs in deposits, all in the same week.

Yet, a large population of users still accept custody risk in exchange for lower costs and ease of use. Memes and painful lessons only take us so far in making self-custody the default, we have a ways to go before non-custodial wallet infrastructure becomes the path of least resistance for securing and managing assets.

Fortunately, there is a blossoming ecosystem of wallets giving individuals, DAOs, and institutions more optionality. Crypto is no longer about just securely storing, but also putting assets to use in a new economy. Richer functionality has come with increasing attack surfaces and exploits, requiring wallets to be able to both withstand attacks while supporting everyday business and personal use.

As with all design decisions, it’s a matter of optimization across multiple considerations for a given use case and the ability of wallet solutions and key management practices to pragmatically balance the collective requirements of their target users:

  • Individuals want seamless UX, low cost, and flexibility to interact with dapps.
  • DAOs want transparent treasury management and ecosystem governance participation.
  • Institutions want to outsource liability with chain-agnosticity, auditability, and institutional-grade security.

There has been significant development in two categories of alternative key management solutions: smart contract wallets (including multi-signature wallets), and multi-party computation (MPC) protocols.

Some examples of wallets in each category. WalletConnect’s integrations page is a much better proxy of a comprehensive list and number of wallets in production.

This article covers:

  • Properties to consider in a wallet
  • An overview of conventional, MPC, and smart contract wallets
  • Ongoing challenges in the wallet ecosystem
  • Summary of current tradeoffs in wallet solutions, and an outlook on wallet infrastructure landscape

Properties to Consider in a Wallet

  • Security. Degree of protection against simple to sophisticated attacks. “Good key management” today involves choosing a combination of solutions whose onboarding and operational costs match the nature of on-chain activities and amount at stake.
  • Cost. How expensive it is to create accounts, manage access, and perform transactions.
  • UX & Flexibility. The granularity of access control management, spending policies, limits, and permissions.
  • Recoverability. The ability to recover assets and access in case of compromise or loss of life.
  • Extensibility. The ecosystem of products and services that can bring new features and integrations to the core product.
  • Privacy. The ease with which addresses can be linked to individuals, and the extent to which wallets reveal operating procedures for organizations.

Conventional (HD) Wallets

Conventional wallets use a seed phrase and a hierarchical deterministic (HD) structure to derive private keys, their corresponding public keys and on-chain addresses. These wallets allow users to generate the private keys used to sign transactions, and recover all keys using the seed phrase.

Conventional wallets have so far served as the main entrypoint for users opting to self-custody their assets and interact with blockchain applications. Browser extensions like MetaMask and mobile applications like Rainbow have onboarded millions of users to the ecosystem. Users with more at stake can then opt for hardware wallets like Ledger and Trezor, which offer better security as they protect the private keys offline.

While the industry has made a tremendous collective effort to educate users about the importance of keeping seed phrases and keys secure, this single point of failure remains a significant hindrance to wider adoption. Besides losing all their assets if their private keys are lost, users have to manually keep track of multiple addresses, token approvals, and compromise privacy from having to fund fresh addresses for gas.

The speed of innovation at the application layer has meant that today, irrevocable strings of characters can give not only full access to someone’s life savings, but are increasingly associated with on-chain histories that contribute to their online identity. The incentive to gain access to private keys is so large that everyone from amateur to state-sponsored hackers dedicate limitless resources to perform increasingly creative attacks. Today, relying on user opsec is no longer enough — we need to remove this single point of failure entirely.

Multi-Party Computation (MPC) wallets and smart contract wallets help us achieve this, and there is already an ecosystem of products and services in both categories that have been adopted by institutions, cryptonative individuals, and DAOs alike. While both types of wallets remove the single point of failure, they have some fundamental technical differences that give rise to different sets of tradeoffs. This next section will give an overview of both.

MPC Wallets

Broadly speaking, multi-party computation (MPC) enables a set of parties who do not trust each other to jointly compute a function over their inputs while keeping those inputs private. In cryptography, this is particularly useful for preserving the private key used to decrypt data or generate digital signatures.

MPC wallets remove the single point of failure by using a Threshold Signature Scheme (TSS). Under this paradigm, we create and distribute shares of a private key such that no one single person or machine controls the private key entirely — this process is called Distributed Key Generation (DKG). We can then jointly generate a public key by combining the shares without exposing shares between the parties.

To sign messages and transactions, each party inputs its secret share along with a public input (the message to be signed), generating a digital signature. From there, anyone (i.e. validator nodes) with knowledge of the public key should be able to verify and validate the signatures. Since the key shares are combined and the signature is generated off-chain, a transaction generated from an MPC wallet is indistinguishable from that of a conventional private key wallet.

This gives MPC wallets users a degree of privacy. For organizations who want to keep their signing schemes and signer activity out of the public eye, this feature comes out of the box as these processes occur off-chain. Organizations can then keep internal logs of who participated in the signing without it being made public to outsiders.

Private Key Rotation is another MPC protocol that takes the secret shares as input, and outputs a new set of secret shares. Old secret shares can be deleted and replaced with new ones that can be used in the same way without changing the corresponding public key and address.

MPC Wallets: Strengths

  • No single point of failure. A whole private key is never concentrated on one device at any one time. There is also no seed phrase.
  • Adjustable Signing Schemes. Approval quorums can be modified as individual and organizational needs evolve, while maintaining the same address. Organizations can dynamically adjust signing schemes without having to inform counterparties of a new address every time.
  • Granular Access Control. Institutional users can assign an unlimited number of transaction approvers to a policy and delegate permissions that acutely reflect organizational roles and security measures (timelocks, MFA, fraud monitoring). Individuals can choose the semi-custodial route with an MPC wallet-as-a-service, where a third party holds one of the key shares.
  • Lower Transaction and Recovery Costs. MPC wallets are represented on the blockchain as a single address, for which gas costs are the same as regular private key addresses. This can be important for users who make hundreds of transactions per day e.g. in a B2C use case. Recovery of lost key shares can also be conducted off-chain.
  • Blockchain Agnostic. Key generation and signing relies on pure cryptography off-chain. Extending compatibility to new blockchains is straightforward as the wallet needs to simply be able to generate signatures using the algorithm recognized by that chain.

MPC Wallets: Drawbacks

  • Off-Chain Accountability. Signing authorization policies and approval quorums are managed off-chain, so these custom rules are still subject to centralized failures. Key shares are still cryptographic secrets that should be handled the same way whole private keys are. Off-chain rules and signing hinders transparency and calls for more rigorous operational audits.
  • Incompatible with most conventional wallets like Ledger and Trezor as there is no seed phrase or whole private keys stored on a single device, but MPC hardware wallet options like Cypherock are available (also open source). MPC algorithms are not standardized, and so custom implementations aren’t supported natively by institution-grade secure devices like iPhone SEP and HSMs. Though it’s worth mentioning that Qredo implements open source Apache Milago MPC libraries and users can sign with an iPhone.
  • Mostly siloed, bespoke products. Many MPC libraries and solutions are not open-source, so there is no easy way for the ecosystem to independently audit and integrate them and conduct post-mortems if something goes wrong. One notable exception here is ZenGo’s open-source MPC/TSS libraries for popular signature algorithms like BLS and ECDSA.

Today, MPC-based solutions have primarily targeted institutional clients such as funds, family offices, exchanges, and custodians. MPC tech providers like Qredo* and Fireblocks enable customers to define their own workflows for different kinds of transactions that allow them to remain compliant and secure. Qredo decentralizes it’s MPC solution with an L2 blockchain, where each node holds a key share and collectively produce a signature once approval thresholds are met. Dfns provides offers an API for institutions to roll out seedless wallets, secured by an MPC network.

The retail investor base however, remains largely dependent on independent research and private key wallets. But this too is changing, with ZenGo currently the leader in the consumer MPC wallet category. Web3Auth recently released an MPC SDK that allows any wallet or dapp to leverage this for their users as a “web3-native MFA”, using their iCloud or email as backup. Decentralized custody protocols like Entropy are building open source tools for consumers and DAOs to store assets online, and define security precautions for transactions through MPC.

Notable ongoing development in MPC: Programmable Key Pairs

Lit* is a decentralized protocol which stores key shares on Lit network nodes. Here, public/private key pairs are represented by a PKP (Programmable Key Pair) NFT, whose owner is the sole controller of the key pair. The PKP owner can then trigger the network to aggregate the key shares to decrypt a file or sign messages on their behalf when arbitrarily defined conditions are met.

This has powerful implications for decentralized access control, asset management, and automated on-chain interactions. By granting signing privileges to a Lit Action (immutable code deployed to IPFS), PKPs can be used as an MPC or decentralized cloud wallet that uses any auth method expressible in javascript.

Minting a PKP NFT is the MPC-based Distributed Key Generation process which makes the NFT owner the root owner of the PKP. Thus, transferring this NFT is the equivalent of trading a private key, which actually breaks the notion of “soulbound” tokens (SBT) in the sense that an SBT is bound to a particular owner, as the wallet itself can now be securely traded (so perhaps “wallet-bound token” is a more appropriate name for non-transferable NFTs here).

Smart Contract Wallets

Ethereum currently has 2 account types:

  • Externally owned accounts (EOAs) — controlled by private keys
  • Smart contract accounts — controlled by code

Smart contract wallets (“smart wallets”) are just smart contracts that behave like a wallet, i.e. an interface that allows users to manage their funds, sign in with web3, and interact with dapps. Unlike private key wallets, smart wallets come with an initial cost to create as a smart contract needs to be deployed on-chain.

Multi-signature wallets are smart contract wallets which require the signature from M-of-N keys to execute a transaction. While MPC only creates a single signature regardless of the number of key shares that participated, a multisig uses distinct signatures generated by distinct private keys to sign transactions. This makes it compatible with existing private key wallets and sits one layer above HD wallet addresses like Ledger or Metamask.

Smart contract accounts standards like Safe* provide a foundational layer for an ecosystem of asset management products and services to be built on top. Features are added via modules, which allow users to define admin key logic, spending limits, recurring transactions, account automation, hierarchical access, and more. The most prolific set of modules for Safe today is built by the Zodiac team.

Smart Contract Wallets: Strengths

  • No single point of failure. Multiple signatures are needed to execute a transaction.
  • Programmable Access Control. Users can define different policies, set timelocks, spending limits, automations (harvest farming rewards, limit orders).
  • Transaction batching can be implemented to save costs. For example, “batching” common actions like token approvals and trades into one transaction. Although single actions from a multisig costs higher in gas than those from MPCs, transaction batching can help save costs in the long run.
  • Extensible. Thanks to the composability of smart contracts, wallet developers can create an ecosystem of modules that users can opt to add to their wallet, creating an app store for new features like NFT lending frameworks, DAO voting modules, and non-custodial asset management services.
  • Programmable Recovery. Wallets can offer several options to recover funds into the smart contract itself. For example social recovery, deadman switches, or a hybrid approach (a service provider can hold a backup key).
  • On-Chain Accountability. On-chain signature authorization policies and aggregation makes it explicit which keys were used to sign a transaction, making operations more transparent and straightforward to audit who participated in a transaction in case something goes wrong.
  • Enables migration to alternative signature schemes. Smart contract wallets can change their signature scheme to simpler, more gas efficient, or quantum-resistant ones. They could also use secure enclaves on iOS and Android devices (turning phones into a hardware wallet) or enable Ed25519 to allow using iOS biometrics & WebAuthn.
  • Open Source. Smart wallet implementations and feature extensions can be audited by anyone, enabling an ecosystem approach to addressing vulnerabilities and adding new features.

Smart Contract Wallets: Drawbacks

  • Higher fees. Smart wallets come with higher fees than regular, single address transactions as multiple signatures need to be verified. Actions such as adding/removing owners and changing the threshold also requires an on-chain transaction.
  • Not universally supported. While smart wallets can deploy on any EVM chain at the same address, they need bespoke implementation on non-EVM chains.
  • More expensive to recover. While recovery logic is programmable, you need to pay on-chain fees to execute it.
  • Incompatible with non-upgradeable contracts. While EIP-1271 allows applications to sign on behalf of contract wallets, it is still not universally supported and cannot be added to non-upgradeable contracts.

Notable ongoing development in smart contract wallets: Account Abstraction

Smart wallets play a crucial role in the ecosystem-wide effort to move away from EOAs and private keys completely, otherwise known as account abstraction. Under this paradigm, all accounts are smart contracts with their own logic to dictate what a valid transaction is, allowing users to customize accounts to their specific needs.

Account abstraction has been discussed since 2016, but the ecosystem has been slow in aligning on the solution. L2s have greatly accelerated the awareness and adoption here, for example Starkware has already made all Starknet accounts smart wallets natively, and zkSync 2.0 will also launch with AA.

On Ethereum, multiple EIPs exist to accomplish the milestones on the roadmap to make account abstraction a reality.

  • ERC-4337 moves signature verification, gas payment, and replay protection out of the core protocol and into the EVM, enabling users to use smart wallets containing arbitrary verification logic instead of EOAs as their primary account without any consensus-layer changes. This EIP introduces a UserOperations mempool which exists in parallel to the existing mempool. Bundlers (validators, MEV searchers, or the application itself) pick up transactions from the UserOperations pool, relay them to the blockchain and pay the fee. Paymasters are an optional step for transaction sponsorship. Here, the initiator wallet doesn’t pay for gas themselves, but instead applications can aggregate and sponsor gas payments for their users using fee subscription models.
  • EIP-3074 allows EOAs to delegate control to a contract, letting existing EOAs send ops that get paid for by third parties.
  • EIP-5003 upgrades existing EOAs to contracts and allows migration away from ECDSA to more efficient or quantum-resistant signature schemes.

Ongoing Challenges for the Wallet Development Ecosystem

  • Technical Exploits

The Parity Multisig hack and more recently the Rabby Swap exploit demonstrate that even the best conceptual means to store funds mean little if the implementation is flawed. With open source software and an ecosystem approach to add features, vulnerabilities are more likely to be found and addressed quicker than code in a black box. We can anticipate that there will be standards for smart contract accounts, like OpenZeppelin’s implementations of ERC-20 and ERC-721, will grow Lindy and developers can more confidently build on top as the ecosystem matures.

  • Social attack surfaces

The merits of any given technical solution still does not neutralize risk at the social layer. The $600M Ronin Bridge exploit was not due to any technical flaw, but a social engineering attack on one of the Sky Mavis employees that gave attackers access to the validator keys. Beyond making responsible decisions on which wallets to use to manage their assets, organizations still need to ensure that each component of this critical system is truly independent at the social and technical layer.

  • Cost of Security and Migration

Migrating from one account to another is neither fun nor cheap. Despite robust wallet alternatives on the market today, there is a real cost to users to migrate their existing EOAs: transaction fees, closing/opening DeFi positions, tax implications, user error, time and energy.

  • Operational Security

Self-custody is a scary prospect for most users today as improving personal opsec requires a conscious effort which can be a daunting task. Most transaction data is not human-readable (though this is changing), and mistakes are irreversible. Many wallet websites mention something along the lines of “you fully own your crypto, if you lose your seed phrase we can’t help”, which is a non-starter for a significant portion of potential users. Hybrid setups (e.g. a service provider like Casa as a signer in your multisig) help here to provide a path of recourse and support without the ability to mismanage user funds. Like crypto education, this problem can’t be solved by one team alone and requires the ecosystem to develop tools and UX patterns that go hand-in-hand with security best practices.


Despite common “this vs that” framing, MPC and smart wallets are not competitive, but rather complementary in the long term. MPC gives shared security at the key generation and management level, while smart contracts bring extensibility and an ecosystem approach to feature and application development. For example:

  • MPC could augment an existing multi-signature scheme by dividing one or more of the private keys into parts. If three people were utilized to secure a 2-of-3 multisig, each of those three users could subdivide their individual private keys using MPC and store their MPC key parts on independent machines i.e. make an MPC account an owner of a Safe.
  • Communities or DAOs can be signers to a multisig that owns a PKP NFT managing a decentralized cloud wallet, which can be used for automated investing or DEX interactions.

This year, crypto has been crippled in many ways by the reckless behavior of centralized entities who have eroded trust in the industry, solicited regulatory scrutiny, and most importantly lost users’ funds and in some cases life savings. The technologies and projects highlighted in this article paves the path towards a future where everyone can participate in the decentralized economy without leaving their fate in the hands of a few.

If you are building a wallet solution or have additional thoughts on the topic, we’d love to chat!

Many thanks to Lukas Schor, Christoph Simmchen, Dmitriy Berenzon, and Accel XR for reviewing drafts of this.

* denotes 1kx portfolio companies



Nichanan Kesonpat

Platform & Content @1kxnetwork | Co-Founder @lastofours | Smart Contracts @upstate-interactive | 🏠.