Skip to content

Latest commit

 

History

History
52 lines (33 loc) · 6.21 KB

our-features.md

File metadata and controls

52 lines (33 loc) · 6.21 KB
description
An extensible on-chain smart wallet solution

📽 Introduction

Introducing Locksmith Smart Wallet

A secure, self-custodial, and user-friendly wallet is necessary for the evolution of the crypto industry. This is why we built the Locksmith smart wallet to transform self-custody into full-custody and every user’s wallet into a personal bank. With an innovative ERC-1155 semi-fungible token (SFT) design, the security and benefits of account abstraction are here and now. Out of the box, Locksmith smart wallets offer:

  • Virtual addresses that unify all existing user wallets
  • Automated asset transfers (e.g., recurring payments)
  • Wallet recovery mechanisms
  • Multi-sig / MPC security with a single signature
  • Verifiable solvency of all collateral positions
  • Delegation of deposit, withdrawal, and dApp interaction permissions
  • Deposit control – no more unwanted dustings or airdrops
  • Multi-call transactions that bundle transaction to minimize gas fees
  • Powerful session keys that govern dApp transactions with complex logic (e.g., approve all swaps if and only if…)
  • “Invest at rest” to earn yield on passive funds

With these features, we expect to reach brand new audiences with the benefits of self-custody and provide existing users newfound confidence on their crypto journeys. Every Locksmith wallet user can access a single, intuitive interface that meets their needs, whether they are a first time retail customer, crypto degen, or TradFi institution that is ready to embrace DeFi.

Our insight is that overcoming the UX-security dilemma means changing the relationship between private keys and access to crypto assets. A priori, the ideal solution would have the following traits:

  1. On-chain. Does not rely on centralized off-chain actors, companies, custodial outfits, "Web2" based services, servers, or deployments for data storage, indexing, or transaction relaying.
  2. Self-custodial. Allows the user to maintain complete control of and visibility into their assets at all times.
  3. Recoverable. Negates the impact of lost private keys by providing the user a secure and reliable way to recover crypto assets. This includes cases where assets are staked, locked up, loaned, borrowed, etc.
  4. Secure. Ensures that interacting with new experiences never means putting the user’s assets at unnecessary or involuntary risk.
  5. Extensible. Allows users the freedom to deploy, transfer, and transact with their crypto assets with greater functionality than they encounter in traditional finance. This includes the ability to provide others with granular permissions over self-custodied funds.

No wallet or service in the market today meets all five criteria. By contrast, the Locksmith smart wallet assigns, tracks, and monitors the permissions of SFT holders, providing users with a virtual wallet that separates private keys from assets in a trustless, permissionless way. With Locksmith, you can move funds from cold storage to predetermined addresses or dApps without ever exposing the cold wallet private keys. You can use multiple copies of a single SFT to access funds on different desktop, mobile, and hardware wallets without sharing the same private key between devices. You can provide full control of assets to family members after a certain period of inactivity, as one might want to do for inheritance. And we believe this is just the beginning.

At its core, the Locksmith tech stack is a toolbox of novel smart contracts that are entirely composable into nearly any custody or DeFi use case. The primary functional features in the Locksmith smart wallet include:

  1. SFT-based ownership: Locksmith wallet actions require valid possession of the proper SFT "Key." These can take the form of “root keys” (the original) or “ring keys” (keys generated by the root key). The importance of any one individual private key diminishes as long as the user can maintain control of the root SFT, enabling many valuable features of account abstraction.
  2. Programmable security: Separate fund access between cold and hot wallets with mediator accounts that only have permission to move funds from one wallet to another. This allows for "air-locked" access to funds and feature sets. The SFTs can also be optionally and mutably "soul-bound" to a specific address to prevent phishing, exploits, scams, pawning, or unauthorized transfers.
  3. Permissioned key minting: SFTs enable multiple copies of keys to be minted. This enables the wallet owner to mint multiple permissions used by different actors, including permissions to restore funds to a newly generated address.
  4. Open Development: Commitment to composability enables developers to build and extend the wallet API to provide further automation and features on-chain and without permission.

That last point is significant. While Locksmith will launch with several applications built in (e.g., inheritance, account recovery, recurring payments), we’ve made the code open source and the wallet easily extensible. Any developer that wants to create additional features, build integrations, or offer new services on top of Locksmith is welcome to take part in the journey and benefit from the community. For users, we expect a steady stream of optional features and services that they can access from the Locksmith UI, bringing the incessant innovation of Web3 directly into their wallet.

Locksmith wallet does not replace your existing wallets; Metamask, Coinbase Wallet, WalletConnect, and every other EVM wallet can utilize our platform. We give your existing wallet superpowers. All you need to do is connect.

Join us if you share our vision of a simpler, safer, and more powerful self-custody experience.

The remainder of this white paper outlines in detail the composability of the Locksmith smart wallet. Each section of the “Architectural overview” provides a non-technical introduction, followed by a technical discussion of the smart contracts that comprise the system architecture. We conclude with a summary of the design considerations and known trade-offs.