Appearance
Project Vision
What Vela is, why it exists, and where it's going. This document serves as the canonical vision statement — used internally for alignment and externally for investor preparation.
What Vela Is
Vela is the recurring value transfer primitive. VelaPay is the product surface.
The core job stays constant across the entire workspace: let a merchant pull exactly what a user or agent agreed to, on schedule, with enforcement happening at the Token-2022 transfer boundary instead of in off-chain trust logic.
Vela applies Nick Szabo's 1994 smart contract definition to recurring payments. In his original paper (Smart Contracts, Nakamoto Institute archive), Szabo defined a smart contract as:
"A computerized transaction protocol that executes the terms of a contract. The general objectives are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries."
Every recurring billing system that exists today — Stripe, bank mandates, ACH pull — violates this definition. The merchant holds the authorization and the rails. If they pull more than agreed, the only remedy is a dispute process run by a trusted intermediary (the bank, the card network, Stripe). The blockchain doesn't know the agreement existed.
Vela's transfer hook mandate is the first implementation of Szabo's vision for recurring payments: the agreed terms (amount, cadence, token, expiry) live in a mandate PDA, and the Token-2022 program calls the Vela program on every transfer. An unauthorized pull doesn't trigger a dispute — it fails. The chain executes the terms of the contract.
This is not an incremental improvement on existing recurring billing. It is a different security model.
Why It Exists
Two structural problems, neither solved, both compounding:
1. No native recurring billing primitive on Solana
Ten teams tried subscription billing across four Colosseum hackathons (Radar Sep 2024, Breakout Apr 2025, Cypherpunk Sep 2025, Renaissance Mar 2024). All failed:
- Zero prizes won in any track
- Zero accelerator spots across Colosseum C1–C4
- All used the same architecture: user delegates a token allowance → relayer pulls on schedule → application logic is supposed to enforce the agreement
- None used Token-2022 TransferHook, Arcium MPC, or any form of protocol-level enforcement
The problem isn't demand — the demand is proven by the number of independent attempts. The problem is execution. Colosseum's own co-founders say it explicitly: "Don't be afraid to build products that have been attempted before. Timing and execution matter a lot."
2. Public on-chain billing leaks business intelligence
Every Solana transaction is fully public. Every merchant who bills on-chain exposes:
- Their complete customer list (wallet addresses of every subscriber)
- Their revenue per period (pull amounts × cadence)
- Their churn rate (cancelled mandates over time)
- Their pricing tiers (different mandate amounts per customer segment)
- Their largest customers (highest mandate amounts)
A competitor can watch your billing program and reverse-engineer your entire go-to-market. This is not a theoretical risk — it's structural. It's the real reason no serious B2B SaaS uses on-chain billing today. The data leak eliminates commercial confidentiality.
The combination makes current approaches weak
On-chain businesses face a double bind: they can't bill recurring (no primitive) and they can't bill privately (no encryption). The few who attempt it leak their metrics. The result: serious on-chain businesses avoid billing on-chain entirely, defeating the purpose of being on-chain in the first place.
Market Evidence
The macro signals confirm timing. This is not a speculative thesis — it's an infrastructure gap at payments scale:
Stablecoins at payments scale
- Galaxy Research (Oct 2025): Stablecoin transfer volume is ~$265 billion over 30 days — approximately $3.2 trillion annualized. That's ~2× PayPal's 2023 payment volume.
- a16z State of Crypto 2025: Stablecoin transfer volume is nearly 3× Visa.
- Stripe acquired Bridge for $1.1B — validating the stablecoin payment infrastructure thesis at the highest possible signal.
- Patrick Collison (Stripe CEO): "Stablecoins are room-temperature superconductors for financial services."
- a16z (May 2025): "The Month Fintechs Embraced Stablecoins" — Stripe/Bridge processing $1.5B/month in stablecoin payment volume on Solana.
Investor thesis alignment
- a16z (Sam Broner, Feb 2026): "Stablecoins are programmable. Key features like arbitration, monthly billing, streaming payments" — explicitly naming recurring billing as a core stablecoin unlock.
- Pantera Capital (Nov 2025): HTTP 402 "Payment Required" was left undefined in the original HTTP spec. Stablecoins can finally realize the original vision of protocol-native payments. Privacy + payments is the convergence.
- Galaxy Research (Jan 2026): x402 is for software-paying-software. Agent commerce is the first real use case for crypto micropayments.
Subscription economy baseline
- The global subscription economy was $275B+ in 2024 (traditional, not crypto)
- Stripe Billing processes billions in recurring revenue
- Even capturing 0.1% of crypto-native recurring payments is a massive opportunity as stablecoin adoption accelerates
Current Product Stance
The workspace has shipped eight milestones. The vision is no longer conceptual — it's operational:
All shipped milestones
| Milestone | What Shipped |
|---|---|
| v1.0 — Billing Foundation | Protocol core (create_plan, subscribe, execute_pull, cancel), SDK + CLI (@vela/sdk on npm), merchant dashboard, landing page, developer docs |
| v1.1 — Arcium Privacy Layer | Wrapped USDC + transfer hook enforcement, keeper automation, checkout widget, encrypted analytics, private billing pipeline, fail-closed design |
| v1.2 — Protocol Admin Dashboard | Admin auth, monitoring, write ops, emergency controls, observability, immutable audit trail |
| v1.3 — Merchant Login UX | Email-first auth, SSO, org model for multi-user merchant teams |
| v1.4 — Agent Mandates | Agent budget mandates with transfer hook enforcement, daily limits, lifetime caps, authorized service lists |
| v1.5 — Hosted Checkout & Billing | Hosted checkout at pay.velapay.com, invoicing, customer portal, pricing table embed, payment links |
| v1.6 — Docs Revamp | 60-page MDX developer documentation site, comprehensive SDK reference, architecture ADRs |
| v1.7 — Protocol Modularity | Versioned accounts, token registry, SDK decoupling |
| v1.8 — In progress | Streaming payments, plan upgrades, multi-token support, webhook SDK, staging closure |
Product surfaces shipped (9 repos)
| Repo | Purpose |
|---|---|
vela-protocol | Anchor dual-program workspace — mandate registry + transfer hook, deployed on devnet |
vela-sdk | Published @vela/sdk on npm with CLI (vela simulate, vela status, vela create-plan) |
vela-dashboard | Merchant dashboard — plans, subscribers, webhooks, analytics, Arcium-encrypted metrics |
vela-admin | Protocol admin — monitoring, emergency controls, audit log |
vela-web | Public landing page on Cloudflare Workers |
vela-docs | 60 MDX-page developer documentation site (Starlight) |
vela-checkout | Hosted checkout flow at pay.velapay.com |
vela-portal | Subscriber portal — manage subscriptions, cancel, switch plans |
vela-widget | Embedded checkout loader + iframe |
Execution metrics
- 47 phases planned and executed
- 200+ plans completed
- 529+ commits since March 29, 2026
- ~30 commits/day (solo, AI-assisted)
- No other subscription billing project has shipped more than 2 components. VelaPay has shipped all 9.
4-Layer Architecture
Vela's architecture is designed as a stack, not a product. Each layer builds on the one below:
┌──────────────────────────────────────────────────────────────────┐
│ Layer 4: Applications │
│ Dashboard, Subscriber Portal, Agent Console, Admin Ops │
│ (what users touch) │
├──────────────────────────────────────────────────────────────────┤
│ Layer 3: Revenue Finance │
│ MRR Oracle, Revenue-Backed Lending, Subscription Marketplace │
│ (future — DeFi composability on billing data) │
├──────────────────────────────────────────────────────────────────┤
│ Layer 2: Billing Engine │
│ Mandate Registry, Stream Engine, Usage Meter, Keeper │
│ (core billing logic and scheduling) │
├──────────────────────────────────────────────────────────────────┤
│ Layer 1: Protocol Core + Privacy │
│ Vela Mandate (Transfer Hook) + Arcium MXE + Credentials │
│ (enforcement and encryption) │
├──────────────────────────────────────────────────────────────────┤
│ Base: Solana Token-2022, Squads, Arcium MXE Network │
│ (infrastructure Vela depends on) │
└──────────────────────────────────────────────────────────────────┘Why this stack matters
- Layer 1 is the irreplaceable foundation. Transfer hooks fire on every token transfer, making enforcement inescapable. Arcium makes billing logic opaque to the chain. These two properties — enforcement + privacy — are architecturally unique to Vela.
- Layer 2 is the billing brain. It handles scheduling (keeper), metering (usage tracking), streaming (per-second payments), and mandate lifecycle. This is where the four billing models converge: recurring pulls, streaming, usage metering, and agent budgets.
- Layer 3 is the DeFi unlock. Once you have cryptographically verified recurring revenue, you can build an MRR Oracle, revenue-backed lending, and a subscription marketplace — all without exposing individual merchant data.
- Layer 4 is the user experience. Dashboard, portal, widget, admin — these are product surfaces that make the protocol usable.
Layer dependency graph
Revenue Finance → Billing Engine → Protocol Core → Solana Token-2022
↓
Arcium MXENo layer can be removed without breaking the layers above it. The billing engine can't exist without transfer hook enforcement. Revenue finance can't exist without encrypted billing data. Applications can't exist without the billing engine.
What Is Validated vs Speculative
Validated (proven by shipping)
- Transfer-hook mandate enforcement as the core billing mechanism — live on devnet, demo shows overpull rejection at the validator level
- Multi-repo delivery model — 9 repos, each with independent deploy lifecycle, all shipping together
- Merchant and admin application surfaces — dashboard, admin, portal, checkout, widget all operational
- Arcium-powered encrypted billing logic — two-phase architecture (Arcium validates → PullApproval PDA → transfer hook consumes) designed around Arcium's async computation model
- Checkout widget infrastructure — 2.6KB gzipped, embeddable, Wallet Standard integration
- Hosted checkout and billing — payment links, invoicing, customer portal, pricing table embed
- SDK-first distribution model —
@vela/sdkon npm, CLI with simulate and status commands - Developer documentation — 60-page Starlight docs with quickstart, SDK reference, architecture ADRs
Speculative (not yet proven by market)
- Revenue finance layer (MRR Oracle, lending, marketplace) — architecturally designed but no merchant volume to validate
- Agent economy at scale — agent mandates work technically, but the agent commerce market is nascent (a16z, Galaxy Research identify it as 2026+ narrative)
- Subscriber-facing product surfaces — portal shipped but no user data to validate product-market fit
- Protocol governance — not designed yet, not needed until multi-merchant adoption
- Privacy as a market-facing pitch — four Arcium projects won zero prizes at Cypherpunk; privacy hasn't been validated as a winning pitch by judges or early adopters yet
Why Solana Still Matters
Vela is not chain-agnostic. It is Solana-native by architectural necessity. Four properties make this true:
1. Token-2022 Transfer Hooks
This is the irreplaceable dependency. The TransferHook extension lets Vela intercept every token transfer and validate it against an on-chain mandate PDA. This creates a mandatory validation gate that cannot be bypassed.
EVM token standards (ERC-20, ERC-777, ERC-1155) do not support execution hooks at the token program level. You can build an approval-based billing system on Ethereum, but you cannot build one where the token program itself enforces the billing rules on every transfer. Without TransferHook, Vela becomes another allowance wrapper.
2. Sub-cent transaction fees
Billing at monthly cadence (or more frequent — streaming is per-second) requires each enforcement transaction to be economically viable. Solana's sub-cent fees make a $9.99 monthly subscription cost pennies in enforcement overhead. Ethereum gas fees would make the same subscription cost $2–5 in gas alone.
3. Arcium MPC network
Arcium's encrypted compute network runs on Solana. Vela's privacy layer — encrypted billing logic, encrypted analytics, encrypted mandate validation — requires Arcium MPC circuits. This dependency is Solana-native.
4. 400ms finality
Pull confirmations are near-instant. Solana's ~400ms finality vs Ethereum's 12+ minutes matters for merchant UX: immediate confirmation vs waiting for blocks. For keeper automation (scheduled pulls), fast finality means the billing engine can execute and confirm within a single cron window.
Without these properties
Vela becomes another allowance wrapper — the same pattern every competitor uses. User approves spending, relayer pulls on schedule, application logic is supposed to enforce the agreement. The blockchain doesn't know or care. With these properties, Vela becomes a real protocol primitive where the chain itself executes the billing contract.
The Primitive vs Product Distinction
This distinction matters for investor conversations, for positioning, and for long-term defensibility.
Vela builds a primitive, not a product
Products get commoditized. A better UX, lower fees, or a VC-backed competitor can displace a product. Primitives get composed. Other things build on top of them.
Historical precedent:
- Token-2022 is a primitive. Orca, Raydium, Drift all build on it. Nobody competes with Token-2022 — they use it.
- Squads is a primitive. Protocol upgrade authorities, DAO treasuries, team multisigs all use it. Nobody competes with Squads — they build on it.
- Vela's mandate program, if adopted, becomes the primitive that every on-chain SaaS, every subscription DAO, and every agent orchestration platform builds billing on top of.
Structural lock-in
The switching cost is structural, not contractual. Once a merchant's billing logic is tied to a Vela mandate PDA, their customer relationships live in that PDA. Migrating to a new billing system means re-creating mandates with every subscriber — not just switching an API key.
This is the same lock-in that makes Squads sticky: not because it's the best UX, but because your program authorities are already there. Moving means re-creating your entire authority structure. For Vela, moving means re-creating your entire subscriber base.
The correct sequencing
Ship product → Get merchants → Prove value → Other protocols build on top → Declare primitiveNot:
Declare primitive → Hope products get built → WaitThe a16z essay "Getting ready to launch a token" is direct: "Finding product-market fit is the single most important focus." The same principle applies to declaring protocol primitiveness. Earn it with adoption. The protocol architecture is designed as a primitive. The go-to-market is designed as a product. Both are correct.
The One Sentence That Matters
Before architecture, before features, before roadmap — this is the sentence a merchant says to themselves:
"Finally — I can charge my subscribers monthly without Solana explorers showing every competitor my MRR."
Every product decision should be evaluated against whether it gets more merchants to that moment faster. If a feature doesn't serve that sentence, it's a distraction.
Sources: Nick Szabo "Smart Contracts" (Nakamoto Institute), Galaxy Research "The Future of Payments" (2025), a16z "State of Crypto 2025", a16z "How stablecoins will eat payments" (Sam Broner, Dec 2024), Pantera Capital (Nov 2025), Colosseum Copilot corpus (1,997 projects), internal planning artifacts (.planning/), project source code (9 repos).