Skip to Content
OverviewArchitecture & Security ModelArchitecture

Core Architecture

WaaP is built to avoid single points of failure: no single user, company, or section of code should be able to move funds on its own. Users and companies make mistakes. They lose seed phrases, ship exploitable code, or keep poor operational security. The user experience reflects almost none of this; security happens behind the scenes.

Two things carry that guarantee, and it is worth separating them clearly:

  1. Where the signing key lives. In an attested enclave, or split across the Ika validator set.
  2. What has to be true before that key is used. An authorization decision that is made independently of the client, and verified again before signing.

Most of WaaP’s security comes from the second one.

Signing modes

Standard mode. Enclave custody (default)

New WaaP accounts use standard mode. The signing keys are generated and held inside a Trusted Execution Environment running a minimal codebase:

KeyCurveChains
t1secp256k1EVM, Sui
t2ed25519Solana

No key material is held on the user’s device. There is no browser keyshare, no client-side key generation ceremony, and nothing in local storage that can sign. A device compromise cannot exfiltrate a key, because the device never has one.

This is a deliberate change from WaaP’s earlier two-party model. Rather than splitting the key so that a compromised device holds half of it, WaaP keeps the key out of the device entirely and puts the security boundary on authorization. See The authorization gate below.

Squid. Ika threshold dWallets

Squid mode signs with a shared dWallet whose key material is distributed across the Ika  network rather than held by any single operator:

KeyCurveChains
sqd1secp256k1EVM
sqd2ed25519Sui, Solana

Squid is opt-in and must be initialized explicitly; it is not a fallback for standard mode. See Squid Mode for the app and agent integration paths.

A note on names. Standard mode and Squid are the product names. The underlying protocols carry their own: standard mode is TAP, and Squid is built on the IKA Lite shared-dWallet protocol. You will meet the protocol names in a few places where they reach the surface. Key names are t1/t2 for standard mode and sqd1/sqd2 for Squid.

The authorization gate

Custody answers “who holds the key”. The gate answers “what will it sign”, and it applies identically to standard and Squid mode, on EVM, Sui, and Solana.

1. The exact bytes are parsed before any decision is made. WaaP does not authorize a request based on what the client says it is doing. The canonical chain bytes are decoded and verified first, so the transaction that is reviewed is the transaction that gets signed.

2. The Policy Engine returns one structured decision. It resolves the registered signer and weighs simulation, reputation, authority, and spend evidence against the account’s policy. Daily spend limits, risk thresholds, and whether multifactor authorization is required.

3. Approval is a narrow, single-use token. When the Policy Engine approves, it issues an authenticated approval bound to the user, the exact transaction digest, the wallet and key, the operation and its revision, a purpose, and an expiry. It is redeemed exactly once. Burned before signing, not after. So a captured or replayed approval cannot sign a second transaction, and cannot sign a different transaction at all.

4. The signer verifies independently. The Policy Engine decides; the key manager re-verifies the user, digest, wallet, key, and operation before it will sign. A single compromised service does not produce a signature.

5. Reviewed bytes are never mutated. Prebuilt and partially signed transactions keep their exact bytes. The one exception is a typed, explicitly authorized late-finalization step for a Solana recent blockhash.

The practical consequence: an attacker who fully controls a user’s browser can request a transaction, but cannot approve one outside the account’s policy, cannot reuse an approval, and cannot alter a transaction after it was reviewed.

Session credentials

The wallet binds its session to a non-extractable key held in the browser using DPoP, and every request carries a fresh proof. A stolen session token is not sufficient on its own. WaaP does not depend on third-party cookies, which are blocked or partitioned in most browsers.

Legacy 2PC accounts

Accounts created before standard mode used two-party computation, with one share on the device and one in the enclave. Those accounts convert the next time they sign in:

  • the enclave reconstructs the original secp256k1 key and verifies it derives the expected address before importing it as t1;
  • EVM and Sui addresses are unchanged, so funds and history are preserved;
  • a t2 key is added, giving the account a Solana address.

Conversion happens once. Until an account converts, it keeps its original two-party behavior.

Last updated on
How a Signature Is ProtectedWaaP vs Embedded Wallet Services