WaaP vs Privy

WaaP and Privy both provide embedded wallet infrastructure. Social login, no seed phrases, smooth onboarding. The difference is what’s under the hood.

WaaP is free to integrate. No per-signature fees, no MAU caps. Pricing above the free tier is not finalised. Privy’s free tier caps at 50K signatures and $1M volume per month, then bills on usage, so cost scales with users.

WaaP is also architecturally different. Privy reconstructs the full private key inside a single enclave and signs whenever the request passes its rules. WaaP separates the two: an independent Policy Engine authorizes each transaction and issues a single-use approval bound to that exact transaction, and the Key Manager re-verifies it before signing. Neither service can move funds alone. And WaaP is the only provider that offers inbound migration tooling. We pre-generate wallets for your users before you change a line of code. Once users log in, they can upgrade their MFA settings (adding passkeys, additional auth factors) to achieve security comparable to hardware wallets.

Why Developers Choose WaaP over Privy

How the Architecture Differs

The critical difference isn’t where keys are stored. It’s what has to happen before they’re used.

Privy: key reconstructed in a single enclave

┌─────────────────────────────────┐
│        Privy Infrastructure     │
│                                 │
│  ┌───────────┐  ┌────────────┐  │
│  │  Enclave  │  │    Auth    │  │
│  │   Share   │  │   Share    │  │
│  │  (in TEE) │  │ (encrypted)│  │
│  └───────────┘  └────────────┘  │
│          │              │        │
│          └──────┬───────┘        │
│       Full key reconstructed    │
│       in single enclave ⚠️       │
└─────────────────────────────────┘

Privy splits the key into two shares, but both shares are brought together inside a single TEE to sign. This creates a single point of failure: if that enclave is compromised (hardware vulnerability, supply chain attack, insider threat), all key material for all users is potentially exposed in one place.

WaaP: deciding and signing are separate services

┌─────────────────────┐        ┌─────────────────────┐
│    Policy Engine    │        │     Key Manager     │
│      (decides)      │───────▶│  (verifies, signs)  │
│                     │        │  ┌───────────────┐  │
│  spend limits       │        │  │    t1 / t2    │  │
│  risk thresholds    │        │  │  held in TEE  │  │
│  2FA requirements   │        │  └───────────────┘  │
└─────────────────────┘        └─────────────────────┘
          ▲                               │
   exact bytes verified          single-use approval,
    before any decision          re-checked, then burned

WaaP holds signing keys inside a Trusted Execution Environment, so nothing on the user’s device can sign. The protection is not simply that the key sits in an enclave. Privy’s does too. It is that the party that decides and the party that signs are different services, and neither can move funds alone.

The Policy Engine authorizes each request against the user’s spend limits, risk thresholds, and 2FA settings, after decoding the exact chain bytes. So the transaction that gets reviewed is the transaction that gets signed. It issues an approval bound to one user, one transaction digest, and one operation, which the Key Manager independently re-verifies and burns before signing. A captured approval cannot be replayed, and cannot be redirected at a different transaction.

Users can strengthen their account further with MFA (passkeys, additional auth factors). For a full breakdown, see Architecture & Security Model.

If you want distributed key material: Squid Mode splits it across the Ika Network validator set, so no single operator. Including us. Holds it. Squid is gated on its reviewed on-chain deployment: production commands fail closed until that deployment is published.

Full Feature Comparison

Pricing Comparison

Privy

• Developer (free): 50K monthly signatures, $1M monthly transaction volume, up to 10K MAU.
• Scale: Custom pricing per transaction or per transacting wallet. Required above free tier thresholds.

Costs scale with your user base. More users = higher bills.

WaaP

• Integration: Free. No per-signature fees. No MAU caps.
• Pricing: Free to integrate today. Tiers above the free ceiling are not finalised.

Your wallet infrastructure becomes a revenue line, not a cost center.

Security Controls: Different Approaches

Both WaaP and Privy offer programmable security controls, but they optimize for different things.

Privy offers more granular programmatic policy options: function-level smart contract restrictions, time-of-transaction windows, asset restrictions, and m-of-n quorum approvals enforced inside their TEE. These are powerful for enterprise teams managing treasury wallets with multi-sig governance.

WaaP optimizes for human-in-the-loop oversight. The security model developers actually want when users or agents are transacting. Instead of configuring policy JSON, your users get a Telegram message describing what the agent wants to do and tap “approve” or “deny.” This is the difference between programmatic guardrails and real-time human supervision.

WaaP’s security controls include daily spend limits, 2FA thresholds, auto-approve rules for low-risk operations, and time-bounded Privileges for scoped agent autonomy. These controls are enforced by the protocol, not the client. The signing service will not act without a valid, single-use approval from the Policy Engine.

Where Privy Is Ahead

We believe in being straightforward:

• Scale track record. 75M+ accounts across 1,000+ developer teams. WaaP is production-ready with multiple independent security audits, but Privy has more deployment history at massive scale.
• Broader chain support today. Privy supports Solana and Bitcoin now. WaaP supports EVM and Sui, with Solana planned.

Switching from Privy to WaaP

We built migration tooling specifically for this. Here’s what the process looks like:

1. We pre-generate accounts for your users using the Account Pregeneration API. Before you change anything in your app.
2. You swap the SDK. WaaP is EIP-1193 compliant, so if you’re using wagmi/ethers/viem, it’s a drop-in replacement.
3. Your users log in and land in a pre-generated WaaP wallet. No extra signup flow.
4. Assets transfer from old Privy wallets to new WaaP addresses (automated for server-side wallets, user-initiated for client-side wallets, ownership-transfer for smart wallets).

No other wallet provider offers inbound migration tooling.

Read the full migration guide →

Ready to Get Started?

• Try it yourself: Build a wallet in the Playground in under 5 minutes.
• Read the docs: Full SDK and CLI reference throughout this site.
• Run an agent: Set up an AI agent wallet in 5 minutes with waap-cli.