Skip to content

roadmap.mdx

Latest commit

 

History

History
110 lines (88 loc) · 8.31 KB

roadmap.mdx

File metadata and controls

110 lines (88 loc) · 8.31 KB
title Roadmap
description Development phases and upcoming features

Phase 1 — Foundation (done)

The core protocol is complete: stealth address cryptography, smart contracts, AI agent, and TEE deployment.

  • [x] Stealth address cryptography — secp256k1 (EVM/CKB) and ed25519 (Stellar/Solana). Full key derivation, stealth address generation, scanning, and spending.
  • [x] ERC-5564 and ERC-6538 implementations — Stealth Address Messenger (announcement format) and Stealth Meta-Address Registry (meta-address storage) standards.
  • [x] Smart contracts — Solidity (EVM), Soroban/Rust (Stellar), Anchor (Solana), and RISC-V (CKB). Announcer, registry, sender, and name contracts on all four chain families.
  • [x] Atomic send-and-announce (WraithSender) — transfer funds to a stealth address and publish the announcement in one transaction. No separate steps for the sender.
  • [x] Batch send and batch withdraw — multiple stealth addresses in one transaction. Reduces gas cost and simplifies bulk operations.
  • [x] Gas-sponsored withdrawals via EIP-7702 (WraithWithdrawer) — a sponsor pays gas on behalf of the stealth address. The stealth address holder doesn't need native tokens for gas.
  • [x] Human-readable .wraith names — on-chain name registry mapping names to stealth meta-addresses. Deployed on all four chains.
  • [x] Subgraph indexing via Goldsky — real-time indexing of Announcement events for efficient payment scanning on EVM chains.
  • [x] AI agent system — Gemini integration with 17 tools. Natural language stealth payments, scanning, withdrawals, invoicing, scheduling, and privacy analysis.
  • [x] TEE deployment — Phala TEE (Intel TDX) with DStack key derivation. Agent private keys derived inside the enclave and never stored on disk.
  • [x] Payment links and invoicing — shareable payment URLs, QR codes, and payment status tracking. Agents create invoices and get notified when paid.
  • [x] Scheduled payments — recurring stealth payments with daily/weekly/monthly intervals. Pause, resume, and cancel support.
  • [x] Privacy analysis — scoring engine that detects timing patterns, identical amounts, address correlation, and consolidation risks. The AI agent warns proactively.

Phase 2 — Unified Platform (done)

Consolidating chain-specific implementations into a single SDK and multichain TEE server.

  • [x] Unified SDK (@wraith-protocol/sdk) — single npm package with subpath exports: chains/evm, chains/stellar, chains/solana, and chains/ckb.
  • [x] EVM chain crypto module (@wraith-protocol/sdk/chains/evm) — secp256k1 stealth address primitives. Key derivation, stealth address generation, scanning, spending, meta-address encoding, name signing, and transaction builders.
  • [x] Stellar chain crypto module (@wraith-protocol/sdk/chains/stellar) — ed25519 stealth address primitives. X25519 ECDH, domain-separated hashing, scalar math, and raw scalar signing.
  • [x] Solana chain crypto module (@wraith-protocol/sdk/chains/solana) — ed25519 stealth address primitives. Base58 address encoding, Anchor program integration, and transaction signing.
  • [x] CKB chain crypto module (@wraith-protocol/sdk/chains/ckb) — secp256k1 stealth address primitives adapted for CKB's Cell model. SHA-256 shared secret hashing, blake160 address hashing, Cell-based scanning.
  • [x] Spectre TEE server — multichain NestJS server with the ChainConnector interface. One deployment handles all chains.
  • [x] EVM chain connector — single EVMConnector class covering all EVM chains.
  • [x] Stellar chain connector — StellarConnector handling Stellar-specific operations.
  • [x] Solana chain connector — SolanaConnector implementing the ChainConnector interface.
  • [x] CKB chain connector — CKBConnector implementing the ChainConnector interface. get_cells RPC scanning, Cell-based announcements.
  • [x] Smart contracts on 4 chains — EVM (Solidity), Stellar (Soroban/Rust), Solana (Anchor), CKB (RISC-V). Full test suites.
  • [x] Demo app — multichain demo at demo.usewraith.xyz with wallet integration for all 4 chains (RainbowKit, Freighter, Solana Wallet Adapter, CCC).
  • [x] Developer documentation — documentation site at docs.usewraith.xyz with SDK reference, architecture guides, and API reference.

Phase 3 — Platform Launch (in progress)

Public developer API with managed infrastructure. Consumer-facing products.

  • [ ] Managed API — developer API keys, authentication, and rate limiting. Developers sign up, get a key, and build.
  • [ ] Developer console — usage analytics, agent management, and billing at console.usewraith.xyz.
  • [ ] Mainnet deployments — deploy contracts to mainnet on all supported chains.
  • [ ] Mobile app — consumer wallet for sending and receiving stealth payments. Simple send/receive interface that handles stealth address mechanics behind the scenes.
  • [ ] Fiat onramp/offramp — buy crypto and have it land directly in a stealth address. Sell from stealth addresses with the same unlinkability.
  • [ ] Fiber Network integration — stealth addresses over CKB's payment channel network for instant, near-free private payments.
  • [ ] Additional EVM chain deployments — each new EVM chain is config + contract deployment with no code changes:
    • Ethereum mainnet
    • Base
    • Polygon
    • Arbitrum
    • Optimism
  • [ ] Cross-chain agent operations — a single agent operating across multiple chains simultaneously. One .wraith name, multiple chain identities, AI routes to the correct chain.
  • [ ] Mobile SDK compatibility — ensure @wraith-protocol/sdk works in React Native and Expo environments.

Why EVM expansion is fast

Adding a new EVM chain requires:

  1. Deploy the same 4 Solidity contracts (Announcer, Registry, Sender, Names)
  2. Set up announcement indexing (subgraph or custom indexer)
  3. Register the chain config in the connector registry

No new code. The EVMConnector handles all EVM chains with the same logic — only the RPC URL, chain ID, and contract addresses differ.

import { Chain } from "@wraith-protocol/sdk";

// Adding Arbitrum — same connector, new config
chainRegistry.register(Chain.Arbitrum, new EVMConnector({
  chainId: 42161,
  rpcUrl: "https://arb1.arbitrum.io/rpc",
  explorerUrl: "https://arbiscan.io",
  contracts: {
    announcer: "0x...",
    registry: "0x...",
    sender: "0x...",
    names: "0x...",
  },
}));

Phase 4 — Chain Expansion

New chain families beyond the current four. Each requires a new ChainConnector implementation and a contract set, but the agent core, AI engine, storage, and tools remain identical.

  • [ ] Hedera — EVM-compatible smart contracts via Hedera Smart Contract Service. HTS for token transfers, HCS for announcement messages, Mirror Nodes for indexing.
  • [ ] Starknet — STARK-friendly curve (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 existing stealth meta-address keys. No new key infrastructure needed.
  • [ ] ERC-4337 Paymaster — alternative to EIP-7702 for smart contract wallet compatibility.

Non-EVM chain effort

Unlike EVM chains (which are config-only), each new chain family requires:

  1. A new ChainConnector class implementing the standard interface
  2. Stealth address contracts deployed on the target chain
  3. Chain-specific transaction building and signing logic

However, the ed25519 cryptographic primitives from @wraith-protocol/sdk/chains/stellar are reusable for Sui, Aptos, and TON. Only the address encoding, transaction format, and contract layer differ. Starknet is a special case requiring a different curve entirely.

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 for a user without ever seeing the viewing key. The scanning computation happens on encrypted data.