Wallet as a Protocol vs Wallet as a Service
Last updated January 24, 2024
Wallets as a Service are great for onboarding. Pin up a dozen wallets for a dozen apps, with Google guarding your keys. But WaaS leads to fragmented on-chain experience, have known security issues, and generally have a rent seeking business model similar to SaaS.
Wallet as a Protocol, on the other hand, lets you create one universal account for all apps with 2-click onboarding, and provides full user authorization and protection for your keys from a decentralized network that guards but never gates.
Silk is Holonym’s WaaP, a new paradigm in onboarding that provides abstracted key management and unparalleled security, specifically against vulnerabilities that are common with WaaS and wallets in general. It’s free for developers to integrate, allowing them to provide native wallet experiences without fragmenting user experience by having one universal account that can be used across apps and devices.
It’s time for an upgrade
WaaS another name for SaaS: Centralized and Profiteering
Much like SaaS, Wallet as a Service provides businesses with ready-to-use infrastructure, abstracting away the complexities of wallet management. They also provide easy onboarding and Web2-like convenience.
But do we want to rely on WaaS models that still depend on centralized infrastructure? Should we accept third-party gatekeepers for our private keys? WaaS functions much like a horse-assisted automobile—a transitional technology that clings to centralized gatekeepers.
Self-proclaimed non-custodial WaaS can make users passive participants in distributed key management, relying on centralized agents for account recovery and cross-device accessibility while falling short in implementing robust security standards for key management.
Fragmented on-chain experience Sustains Rent-Seeking Models
SaaS models rely on proprietary APIs restricting interoperability, and create a closed ecosystem to retain market share. WaaS mirrors this fragmentation but in a different way—by requiring users to create a separate wallet for each app. This happens for two main reasons.
dApps could access or expose private keys, so isolating apps is better for security; even if one dApp is compromised, the damage is contained to that specific dApp and not the user’s entire holdings. Additionally, the revenue of WaaS is based on a “pay per (active) user model, ideally creating as many wallets makes WaaS a sustainable business model.
This leads to fragmented on-chain experience and a hassle of owning many wallets. It also locks users out of potential on-chain rewards and cost benefits, like subsidized fees, tied to a unified account and broader on-chain footprint.
Imagine needing a different PayPal account for every website you shop at—a web of accounts to juggle, each with its own password, authentication headaches, and no way to view your balances or spending history in one place. Worse, none of your loyalty rewards or benefits can be combined, leaving you with scattered funds and wasted perks.
Not secure for self custody, even partial self custody
WaaS solutions, however secure they claim to be, are well-known for hacks and human errors resulting in loss of funds. In addition to the unnecessary private key exposure to dApps mentioned above, WaaS have serious security flaws that render them unsuitable to safeguard large amounts of value and unusable for everyday on-chain interaction.
WaaS, as a rule, not only fails to address existing wallet security threats but introduces additional risks through implementation weaknesses, iframe vulnerabilities, federated MPC structures that risk locking users out, and dependence on centralized agents for key storage and account recovery. Learn more about these prevalent security issues here and here.
See for yourself – Nanak Nihal, co-founder of Holonym, shares a demo here on how to copy private keys from Friend Tech with two user clicks – ironically matching its onboarding simplicity.
Wallet as a Protocol and the Human Friendly key solution
Silk reimagines instant onboarding for dApps from rentable services to permissionless and decentralized solutions. Built on a zero-trust primitive, Silk eliminates single points of failures across the wallet security spectrum, allows developers to own their customer experience by making Silk native to their application, while users create just one universal account.
Simplicity and universal access:
Silk abstracts key management with Human Keys–keys derived from human attributes and innate identity that can be regenerated on any device.
Human Keys allow the users to log in using familiar credentials (e.g., an email address, a voice recording, or biometrics. A single Silk account works across platforms/devices, consolidating all on-chain interactions in one place.
The user could also prove their personhood via Zeronym (ZK), allowing users to authorize every interaction and authenticate identity from a single Silk account.
Security-First Approach through 2PC MPC:
Silk takes a multi-layered approach, looking at security as a spectrum and enabling the user to self-custody without risk from internal or external threats.
Human Keys are split between the user and a non-collusive network (2PC-MPC), ensuring neither party can access or reconstruct the key independently. This design also mitigates centralization risks and user lockouts prevalent in federated MPC networks for distributed key management, as explained here.
Additionally, with Silk, the server or network verifies and authenticates every user-signed transaction by performing transaction simulations and deploying policy engines. Here transactions are verified for fraudulent or malicious intent by running a transaction simulation and validating the authenticity before signing the actual transaction. Policy engines build rules and policies into pre-transaction logic to mitigate exploits, counter money-laundering actions, and enable other programmable checks.
These mechanisms detect and address single points of failure, such as compromised user devices, dApps, or recovery processes. Learn more about Silk’s security model here.
The combination of user authorization, server-side authentication, and advanced security measures like transaction simulation effectively prevents most common wallet vulnerabilities today.
Business Model
Silk has no subscription cost to use or to integrate, with basic setup typically completed in less than 3 minutes. The revenue is in part derived from Mishti Network – Holonym’s AVS for Human Key derivation and ZK ID minting and recovery. Learn more about Mishti Network and Human Keys here.
Other revenue sources come from wallet activity and include fees from swaps, onramps, gas tank fees and yield generating activities.
Get Started!
Try Silk to experience the least cognitive friction with no single point of failure. Developers can earn points from Mishti network, Ika and other networks by onboarding users through Silk.