Self custody today gives you the right to ownership of digital assets, without the right to security.
Wallets have been optimized for better usability, but the status quo of wallet security hasn't changed much. In fact, it's degraded with Wallet as a Service (WaaS) providers. Today's wallet security relies on trusted intermediaries and frontends, each a potential point of failure.
Users must trust their devices won't be compromised by malware. They must trust that dApp frontends aren't malicious or hacked. They must trust that wallet service providers won't be breached, corrupted, or simply disappear. They must trust themselves to remain persistently vigilant, never getting phished, never clicking malicious links.
A crack in any piece breaks everything. The user loses self-custody entirely. More than 80% of the $2.6 billion stolen in 2024 involved access control failures. Users must trust themselves and multiple intermediaries to benefit from self-custody—the fundamental right to hold and transact digital assets without centralized dependencies.
With WaaP, self custody comes with the right to security.
What if wallet security didn't depend on perfect users, unhackable frontends, or trustworthy intermediaries? What if every transaction was validated, every intent verified, and every policy enforced by a distributed network running on zero-trust cryptographic protocols?
This is the breakthrough Wallet as a Protocol (WaaP) brings through 2PC MPC. Its unique design makes transactional security programmable at the protocol level, with bank-like fraud protection, full user authorization, web2-like flexible access controls, and trustless security policies that can be fine tuned based on business operation.
For the first time, a wallet provides protected self custody, where transaction rules and policies are enforced by a permissionless MPC network, consisting of 100s of validators with real-world throughput.
Wallet Architectures: The Security-UX Trade-off
Current wallet implementations make fundamental architectural choices that determine their security properties. Each approach involves trade-offs that create specific vulnerabilities.
Embedded Wallets: Convenience at What Cost?
Wallet as a Services (WaaS) provide embedded wallets, that directly into applications via iframes or SDKs, enabling social login and eliminating seed phrases. While they've optimized for usability, they face various implementation vulnerabilities including clickjacking, cross-site scripting, and authentication token theft (detailed in our wallet security post).
More fundamentally, embedded wallets rely on two key management approaches that creates single point of failures along with server dependencies.
Traditional MPC: The Collusion Problem
MPC wallets use threshold schemes where any t parties out of n can generate signatures (e.g., 3-of-5). This design could exclude the user from the signing process; if the network is attacked, corrupted, or colluded, it can steal all the user’s funds. Additionally, all users rely on the same shared committee of nodes, creating a centralized trust point.
While this model ensures keys need not be reassembled in one place, it faces scalability and performance challenges while running as a network. Large enough networks achieve only single-digit signature generation per second, highlighting their severe performance limitations.
Use cases requiring low latency like trading, gaming, or real world use cases are not suitable for large, decentralized MPC wallets.
Shamir Secret Sharing: The Reconstruction Window
Some of the major WaaS providers splits keys using Shamir Secret Sharing across three shares: user device, wallet provider server, and recovery backup.
The fatal flaw: To sign transactions, these implementations must reconstruct the complete private key in the user’s browser. Any compromise in the user device can drain the user’s wallet.
The Server Dependency Risk
Most Wallet as a Services (WaaS) implement MPC and SSS models on centralized servers that
Store critical key shares or coordinate signing
Validate authorization tokens from users that can trigger key reconstruction
Manage recovery shares
Run signing protocols
Security Policies
When these servers go down, or are compromised, all users become vulnerable simultaneously.
Browser Extension Wallets
Browser extensions store complete private keys locally, encrypted with passwords. They create a single point of failure through seed phrases. Key rotation could mitigate risks but creates massive UX friction, where users must update keys across every dApp, losing transaction history and fragmenting their on-chain identity.
If the device running the extension (generally, a laptop) is compromised, then all the information shown by the web browser and by the extension may be compromised and be used to drain all of the user’s assets.
Protected Self Custody through 2PC MPC
What is 2PC MPC
In 2PC MPC, a private key is split into two independent signing shares. This removes single points of failure in the user’s device, the user themself, or any third party that interacts with the key. The “2” in “2PC” corresponds to the user and a network. The user holds one share of the key. This key can be requested from the Human Network at any time. A decentralized network, like Ika, operates the second share, verifies intent against policy, and presents a human-readable summary before it co-signs.
Key Differentiators from legacy MPC
Permissionless network: 97 validators, and scalable beyond 1000s of validators vs. 4-8 node committees
Real-world throughput: 10,000+ signatures per second vs. single-digit performance
User requirement: Collusion resistance via cryptographically enforced user participation for every transaction vs. centralized dependency of permissioned commitees.
Scalability: Suitable for high-frequency trading, gaming, and mass adoption use cases
Network-Side Security Execution
The architectural distinction between user-side, server side and network-side execution determines which security properties can be guaranteed under adversarial conditions. While the user initiates transactions on their device, the network executes critical security logic, a compromise of which requires corrupting a decentralized network.
Transaction simulation: Pre execution analysis that predicts transaction outcomes and detects malicious behavior before signing
Policy enforcement: Automated rule validation through SUI smart contracts that block transactions violating user-defined security parameters
Access controls: Cryptographic permission systems that require additional authorization factors for high-risk operations
Risk assessment: Real-time threat analysis using machine learning models to identify suspicious patterns and anomalies
Based on business operations, 2PC MPC enables customizable security policies: multi-factor authorization for large transfers, spending caps for everyday operations, enhanced verification for risky transactions, essentially bank-like access controls enforced through cryptography rather than trusted intermediaries.
How Protected Self Custody Works in WaaP
Let's walk through a phishing attack scenario:
You click a malicious link and malware infects your device
Malware manipulates your UI to show a legitimate transaction while crafting malicious payload
Your device creates its signature share for what appears normal
The network receives the actual payload and runs independent simulation
Network detects malicious transaction
Network refuses to co-sign, preventing theft regardless of what your screen displays
This prevents blind signing attacks where users authorize transactions without understanding their true intent like the $1.5 billion ByBit attack of 2025 (more on blind signing prevention plugin).
Wallet Security Comparison
Get Started!
Integrate in minutes. The quick start gets a wallet working in about five minutes. WaaP is EIP-1193 compliant, so your dApp may use the standard provider interface common across Ethereum wallets.
Start building with WaaP → WaaP Developer Docs
FAQ
FAQ: 2PC MPC and Protected Self-Custody
Q: What is 2PC MPC? A: Two-Party Computation with Multi-Party Computation splits private keys between user and decentralized network. Both parties must participate cryptographically in every transaction. Unlike traditional MPC wallets where committees can potentially bypass users, 2PC MPC requires user authorization for every transaction.
Q: How does 2PC MPC compare to MPC wallets? A: Traditional MPC wallets use small committees (4-8 nodes) that can potentially collude or exclude users. 2PC MPC distributes across hundreds of validators in a permissionless network, achieving 10,000+ signatures per second while cryptographically requiring user participation.
Q: What are common wallet attack surfaces? A: Primary attack vectors include device compromise through malware, phishing attacks, blind signing, compromised dApp frontends, cross-site scripting in embedded wallets, authentication token theft, and server breaches at Wallet-as-a-Service providers.
Q: How safe is WaaP compared to browser extension wallets? A: Browser extension wallets create single points of failure through seed phrases and device dependencies. Protected self-custody through 2PC MPC splits keys that never reassemble, protecting users even when phished or infected with malware.
Q: How safe is WaaP compared to Wallet-as-a-Service providers? A: WaaS providers run critical components like signing protocols and recovery shares on centralized servers, creating broad attack surfaces. When compromised, all users face simultaneous risk. WaaP's decentralized wallet protocol eliminates these centralized dependencies.
Q: Does WaaP prevent blind signing? A: Yes, this is possible through our blind signing protection plugin. Here, WaaP uses transaction simulation, human readable warnings, and multi-factor authorization to prevent blind signing. WaaP allows using hardware wallets as the authorization method for confirming high risk transactions, where they are presented with cleartext on what they are signing.
Q: Can 2PC MPC prevent all wallet attacks? A: Security is a spectrum—no system prevents every attack. 2PC MPC addresses the most economically motivated attacks: device compromise, phishing, blind signing, cross-site scripting, malware injection, and server breaches, making them significantly more difficult to execute.
Q: What happens if the network goes down? A: Ika’s Distributed architecture across hundreds of validators provides high availability. Unlike centralized embedded wallet infrastructure where downtime affects all users, the permissionless MPC network ensures continuity.
