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 and signs whenever the request passes its rules. Oversight requires cryptographic quorum signatures from authorized key holders. With WaaP, an independent Policy Engine authorizes each transaction on its own and issues a single-use approval that the Key Manager re-verifies before signing. 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 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, all key material for all wallets is potentially exposed in one place.

WaaP: every signature is authorized, not just capped

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

WaaP holds signing keys inside a Trusted Execution Environment, so the agent process never handles key material. The difference from a server wallet is not where the key sits. It is that the party that decides and the party that signs are different services, and the agent controls neither.

The Policy Engine authorizes every request against the operator’s spend limits, risk thresholds, and 2FA settings, after decoding the exact chain bytes. It issues an approval bound to one operator, one transaction digest, and one operation; the Key Manager re-verifies it independently and burns it before signing. A compromised agent can propose transactions, but cannot approve one outside policy, reuse an approval, or point one at a different transaction.

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.

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, Privileges 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 June 2026.
• Pricing: Free to integrate today. Tiers above the free ceiling are not finalised.
• 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, with Solana planned.

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, Privileges.

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.