WaaP vs Privy Server Wallets

WaaP and Privy both offer wallet infrastructure for AI agents. The difference is in how keys are managed and how humans stay in the loop.

With Privy server wallets, the full private key is reconstructed inside a single enclave every time an agent signs — a single point of failure. Oversight requires cryptographic quorum signatures from authorized key holders. With WaaP, key shares live in separate enclaves and are never combined. Oversight is one tap on Telegram. And WaaP is the only provider that offers inbound migration tooling — we bulk-generate agent wallets before you change a line of code.

Why Agent Developers Choose WaaP over Privy

How the Architecture Differs

The critical difference isn’t where keys are stored — it’s where they’re reconstructed.

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, all key material for all wallets is potentially exposed in one place.

WaaP: shares never in the same place

┌──────────────────┐    ┌──────────────────┐
│ Operator's Device│    │ WaaP Infrastructure│
│                  │    │                    │
│ ┌──────────────┐ │    │  ┌──────────────┐ │
│ │  Sovereign   │ │    │  │   Security   │ │
│ │    Share     │ │    │  │    Share     │ │
│ │ (auth-gated) │ │    │  │   (in TEE)   │ │
│ └──────────────┘ │    │  └──────────────┘ │
└──────────────────┘    └──────────────────┘
         │                        │
         └───── 2PC sign ────────┘
      (cooperate without combining)

WaaP uses 2-Party Computation (2PC). The operator’s Sovereign Share is gated by their authentication. WaaP’s Security Share stays in a separate TEE. They cooperate to produce a signature without the full key ever existing in one place. For a full breakdown, see Architecture & Security Model.

Planned upgrade: WaaP’s Security Share will be distributed across the Ika Network (decentralized validator set), further reducing the trust assumption on any single piece of infrastructure.

Human Oversight: Two Different Approaches

This is the most important difference for agent developers.

Privy: cryptographic quorums

Privy’s policy engine is powerful — function-level restrictions, time windows, asset allowlists, m-of-n quorum approvals. All enforced inside the TEE. But oversight is programmatic: if a transaction passes the rules, it executes. If you want a human to approve a specific action, you need a quorum of cryptographic key holders to sign.

This works well for enterprise teams with dedicated signing infrastructure. It’s high-friction for an individual developer supervising an AI agent from their phone.

WaaP: one-tap approval

WaaP’s security model assumes a single person — not a team with signing keys — is supervising an agent.

1. Agent proposes a transaction via waap-cli
2. If it exceeds auto-approve thresholds, the operator gets a Telegram or email notification
3. Operator taps “Approve” or “Deny”
4. Protocol enforces the decision

For routine operations, Permission Tokens let agents operate autonomously within scoped, time-bounded windows (max 2 hours). The agent handles the small stuff; the human handles the big stuff.

WaaP’s policy engine is simpler than Privy’s today — daily spend limits, 2FA thresholds, auto-approve rules vs. Privy’s function-level restrictions and time windows. The trade-off: accessibility over granularity. One tap on Telegram vs. managing cryptographic signing keys.

Pricing

Privy

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

Per-signature billing means costs scale directly with agent activity.

WaaP

• Agent CLI usage: Free through April 2026.
• Revenue model: Per-partner revenue share on agent transaction activity.
• No per-signature fees. No MAU caps.

Full Feature Comparison

Where Privy Is Ahead

We believe in being straightforward:

• Policy engine granularity. Function-level smart contract restrictions, time windows, asset allowlists, chain restrictions. WaaP’s policy engine is simpler today.
• Scale track record. 75M+ accounts across 1,000+ developer teams. Proven at massive scale with major deployments.
• Framework integrations. Already a wallet provider in AgentKit and ElizaOS. WaaP’s AgentKit integration is planned but not yet shipped.
• Solana and Bitcoin. Privy supports both today. WaaP supports EVM + Sui + Stellar, with Solana planned Q2 2026.

Switching from Privy Server Wallets to WaaP

1. We bulk-generate agent wallets using the Account Pregeneration API — before you change anything.
2. Install waap-cli — npm install -g @human.tech/waap-cli@latest in each agent’s runtime.
3. Transfer agent funds from Privy server wallet addresses to new WaaP addresses (batch-scriptable).
4. Replace SDK calls with waap-cli commands.
5. Configure policies — daily spend limits, 2FA thresholds, Permission Tokens.

No other wallet provider offers inbound migration tooling.

Read the full migration guide →

Ready to Get Started?

• Run an agent in 5 minutes — Install waap-cli with the quickstart guide.
• Read the docs — Full CLI reference and agent patterns.
• Try the Playground — Build a wallet in the Playground in under 5 minutes.