Skip to main content
Wraith Protocol is being built in five phases, from core cryptography and smart contracts through multichain expansion, a managed developer API, non-EVM chain support, and long-term research into trustless outsourced scanning. Phases 1 and 2 are complete. Phase 3 is the current focus.

​
Phase 1 — Foundation

Phase 1 delivered the complete cryptographic core, smart contracts, AI agent, and TEE infrastructure.
Stealth address cryptography — secp256k1 key derivation and stealth address generation for EVM chains, and ed25519 ECDH with domain-separated hashing for Stellar. Full scan and spend support on both curve families.
ERC-5564 and ERC-6538 implementations — ERC-5564 defines the announcement format (Stealth Address Messenger) and ERC-6538 defines on-chain meta-address storage (Stealth Meta-Address Registry). Both are fully implemented for EVM chains.
Smart contracts — Solidity contracts for EVM (Announcer, Registry, WraithSender, Names) and Soroban/Rust contracts for Stellar. Full test suites for both chain families.
Atomic send-and-announce (WraithSender) — transfers funds to a stealth address and publishes the announcement in a single transaction. Senders have no separate announce step.
Batch send and batch withdraw — send to multiple stealth addresses in one transaction, and withdraw from multiple stealth addresses in one transaction. Reduces gas cost and simplifies bulk operations.
Gas-sponsored withdrawals via EIP-7702 (WraithWithdrawer) — a sponsor pays the gas fee on behalf of a stealth address. Recipients never need to hold native tokens just to withdraw.
Human-readable .wraith names — an on-chain name registry that maps names to stealth meta-addresses. Ownership is proven by signing with the spending key. No wallet address is stored — the registry reveals nothing about the owner’s identity.
Subgraph indexing via Goldsky — real-time indexing of Announcement events for all EVM chains. Efficient payment scanning without scanning the entire chain.
AI agent system — Gemini integration with 17 tools covering stealth payments, scanning, withdrawals, invoicing, payment scheduling, and privacy analysis. Agents respond to natural language.
TEE deployment — agents run inside a Phala TEE (Intel TDX) using DStack key derivation. Private keys are derived inside the enclave and never written to disk or exposed to the host.
Payment links and invoicing — shareable payment URLs, QR codes, and payment status tracking. Agents create invoices and receive notifications when they are paid.
Scheduled payments — recurring stealth payments at daily, weekly, or monthly intervals. Schedules support pause, resume, and cancel.
Privacy analysis — a scoring engine that detects timing patterns, identical payment amounts, address correlation, and consolidation risks. The AI agent surfaces warnings before you send.

​
Phase 2 — Unified Platform

Phase 2 consolidated chain-specific implementations into a single SDK and a multichain TEE server.
Unified SDK (@wraith-protocol/sdk) — a single npm package with three entry points: the root (agent client), chains/evm (EVM crypto primitives), and chains/stellar (Stellar crypto primitives).
EVM chain crypto module (@wraith-protocol/sdk/chains/evm) — secp256k1 stealth address primitives including key derivation, stealth address generation, scanning, spending, meta-address encoding, and name signing.
Stellar chain crypto module (@wraith-protocol/sdk/chains/stellar) — ed25519 stealth address primitives including X25519 ECDH, domain-separated hashing, scalar math, and raw scalar signing for stealth key ownership.
Agent client SDK — Wraith and WraithAgent classes with the Chain enum. You can create a single-chain agent, a multichain agent (Chain[]), or an all-chain agent (Chain.All) from one unified interface.
Multichain TEE server — a single TEE server deployment handles every supported chain. The agent core, AI engine, storage, and tools are all chain-agnostic. New chains plug in without touching shared infrastructure.
EVM chain connector — a single connector covers every EVM chain via configuration (RPC URL, chain ID, contract addresses). No code changes are needed to add a new EVM chain.
Stellar chain connector — dedicated connector handling Stellar-specific operations: account creation for new stealth addresses, Soroban contract calls, Horizon balance lookups, and stealth key signing.
Smart contracts — finalized EVM (Solidity) and Stellar (Soroban/Rust) contracts for Announcer, Registry, Sender, and Names, with full test suites on both chain families.
Developer documentation — documentation site with SDK reference, architecture guides, and API reference.

​
Phase 3 — Platform Launch

Phase 3 opens the platform to external developers with a managed API, a developer dashboard, and expansion to additional EVM chains.
  • Managed API — developer API keys, authentication, and rate limiting. You sign up, receive a key, and start building without running your own infrastructure.
  • Developer dashboard — usage analytics, agent management, and billing. Monitor API calls, manage agents, and track costs from a single interface.
  • Additional EVM chain deployments — the same EVM connector and Solidity contracts deploy to every EVM chain with no code changes:
    • Ethereum mainnet
    • Base
    • Polygon
    • Arbitrum
    • Optimism
    • Any other EVM-compatible chain
  • Cross-chain agent operations — a single agent operating across multiple chains simultaneously. One .wraith name resolves to multiple chain identities, and the AI routes each payment to the correct chain automatically.
  • Mobile SDK compatibility — @wraith-protocol/sdk works in React Native and Expo environments.

​
Why EVM expansion is fast

Adding a new EVM chain is a configuration and deployment task — no code changes are required. The process is:
  1. Deploy the same four Solidity contracts (Announcer, Registry, WraithSender, Names) to the new chain
  2. Set up announcement indexing (subgraph or custom indexer)
  3. Register the chain config (RPC URL, chain ID, contract addresses)
The platform’s EVM connector covers every EVM-compatible chain with identical logic. Only the network-specific parameters differ, which means adding Arbitrum, Optimism, or any other EVM chain takes hours, not weeks.

​
Phase 4 — Chain Expansion

Phase 4 extends the platform beyond EVM chains and Stellar to new chain families, adds on-chain private messaging, smart contract wallet gas sponsorship, and a consumer mobile app.
Each new chain family requires a new chain-specific connector and a deployed contract set. However, the agent core, AI engine, storage layer, and all tools remain identical — new chains slot in without touching the rest of the system.
  • Non-EVM chain integrations:
    • Solana — ed25519 curve (cryptographic primitives reusable from @wraith-protocol/sdk/chains/stellar). New Solana programs for announcements and names.
    • Starknet — STARK-friendly curve (special case, requires different cryptographic primitives). Cairo contracts.
    • Sui — ed25519 (crypto reusable from Stellar module). Move contracts.
    • Aptos — ed25519 (crypto reusable from Stellar module). Move contracts.
    • TON — ed25519 (crypto reusable from Stellar module). FunC/Tact contracts.
  • On-chain private messaging — ECDH-encrypted messages using the same stealth meta-address keys already used for payments. The sender is anonymous and no new key infrastructure is required.
  • ERC-4337 Paymaster — an alternative gas sponsorship path for smart contract wallets that do not support EIP-7702. Enables gas-sponsored withdrawals on any chain or wallet.
  • Mobile app / PWA — a consumer-facing mobile experience for managing stealth payments.
Solana, Sui, Aptos, and TON all use the ed25519 curve, so the cryptographic primitives from @wraith-protocol/sdk/chains/stellar are directly reusable for each of these chains. Only the address encoding, transaction format, and contract layer differ per chain. Starknet uses a different curve entirely and is treated as a separate implementation effort.

​
Phase 5 — Research

  • FHE-DKSAP (Fully Homomorphic Encryption-based Dual Key Stealth Address Protocol) — enables trustless outsourced scanning. A third-party scanning service can find incoming transfers on your behalf without ever seeing your viewing key. The scanning computation runs entirely on encrypted data. This removes the need to run your own scanning infrastructure or place any trust in the scanning provider.
FHE-DKSAP is a research-track item. It depends on advances in practical FHE performance and will be developed in parallel with production work rather than blocking platform features.