Build Update
What we've shipped so far.
Vaaya is the wallet for AI agents — sign in, add a card, and your agent
(Claude Code, Cursor, Codex CLI) can discover and pay for verified APIs on your behalf:
web search, image generation, compute sandboxes, email, and GTM tools, with ledger-based
billing and overdraft protection.
Shipped & live
01Auth & onboarding Live
- Google sign-in via Auth.js v5
- Card setup with Stripe
- $100 signup grant, applied idempotently on first card add
02OAuth 2.1 server Live
- Authorization-code flow with PKCE
- Dynamic client registration (RFC 7591)
- Discovery endpoints (RFC 8414 / 9728)
- Refresh-token rotation + nightly stale-token sweep
03Three payment rails Live
- x402 — USDC on Base mainnet via Coinbase CDP
- MPP — Stripe SPT or Tempo chain settlement
- Card / REST — Vaaya-held vendor keys
04Ledger accounting Live
- Balance computed from an append-only ledger, serialized writes
- Automatic card top-up on overdraft
- Per-user and global daily spending caps
- Full transaction history with audit logging
05MCP transport Live
- HTTP
/mcp endpoint for Claude Code, Claude Desktop, Cursor
- Stdio shim
@vaaya/mcp for Codex CLI
- Tool-catalog auto-discovery with one-command installer
06Merchant proxy Live
- External agents pay Vaaya for compute (E2B) and image gen (fal) over sell-side x402
- Per-(vendor, action) pricing in the catalog
- Settles into a dedicated proxy wallet
07Consult engine Live
- Intent classifier routes agents to the right service
- Per-user conversation memory across turns
- Knowledge guides per category: compute, search, scraping, email, GTM
08GTM funnel In progress
- Company & persona search with email enrichment (Prospeo)
- LinkedIn / email connect, invites, DMs, sends (Unipile)
- Per-user throttling tuned to platform-safe limits
- Flag-gated rollout, off by default
Stack
| Layer | Technology |
|---|
| Frontend | Next.js 15 App Router · React 19 · TypeScript |
| Backend | Next.js route handlers · Node.js ≥ 20 · pnpm monorepo |
| Database | Supabase Postgres + Drizzle ORM |
| Auth | Auth.js v5 (Google) + in-house OAuth 2.1 server |
| Payments | Stripe · Coinbase CDP (x402 / USDC on Base) · Tempo (MPP) |
| Quality | Vitest · Biome · Zod-validated configuration |
| Deploy | Vercel (web) · Fly.io (worker + nightly cron) |
Data model — 14 tables
| Area | Tables |
|---|
| Identity | users with balance tracking |
| OAuth | oauth_clients · grants · access_tokens · refresh_tokens · sessions · authorization_codes |
| Money | ledger_entries (source of truth) · transactions · x402_ledger (idempotency + replay) |
| Ops | audit_log · async_jobs |
| Agents | consult_memory — per-user context for the consult engine |
| GTM | connected_accounts · gtm_send_log (throttle tracking) |
How it's built
- Agent-pay-for-APIs only. No send / transfer / swap surface — peer-to-peer transfers are explicitly out of scope.
- Idempotency-first. Every paid call carries an idempotency key; even the signup grant can't double-apply.
- Public-client OAuth done right. The stdio shim runs a loopback PKCE flow; tokens live locally with owner-only file permissions.
- Throttling as pure logic. Send caps are stateless, unit-tested functions applied against the send log at runtime.
- Structured knowledge. Each service category ships a guide the consult engine uses to coach agents on parameters, prices, and prerequisites.
Up next — GTM v1, the cold-outbound funnel
| Phase | Scope |
|---|
| Phase 0 | Vendor contracts + coverage gate (search / enrich accuracy) |
| Phases 1–3 | Config, schema, LinkedIn / email connect flow |
| Phases 4–6 | Prospect search & enrichment, throttling, send dispatch |
| Phases 7–8 | Consult coaching, flag-gated rollout |