Appearance
Investor FAQ
Detailed answers to the most common investor questions about VelaPay. Each answer is grounded in specific data points, competitor names, and technical architecture.
1. "How is this different from Stripe?"
Stripe is trusted middleware. VelaPay is trustless enforcement.
With Stripe, the payment processor sits between merchant and customer. Stripe sees every transaction, every amount, every customer. It charges 2.9% + $0.30 per transaction, takes 2–7 days to settle, and the merchant's billing logic is a black box that the customer must trust. Stripe processes over $1T annually — but it processes it as a trusted intermediary.
With VelaPay, the mandate is on-chain, the transfer hook enforces it, billing logic is encrypted via Arcium, and balances can be encrypted via Umbra. No intermediary sees merchant data. The subscriber knows exactly what they authorized because it's encoded in a mandate PDA that the validator checks on every transfer. An unauthorized pull doesn't trigger a chargeback dispute — the validator rejects it before the transfer executes.
The pricing gap is structural: Stripe charges 2–3% per transaction. VelaPay charges 1% via the Token-2022 Transfer Fee extension, built into the token transfer itself. Stripe takes 2–7 days to settle. VelaPay settles in ~400ms (Solana finality). Stripe is the ceiling for what trusted middleware can do. VelaPay is what happens when you remove the need for trust entirely.
And: Stripe sees everything. VelaPay's billing logic runs inside Arcium encrypted compute — the merchant's subscriber counts, revenue amounts, churn patterns, and pricing tiers are ciphertext that only the merchant can decrypt. No payments infrastructure on-chain has shipped a privacy architecture. VelaPay is the only one that has.
2. "How is this different from existing Solana payment tools?"
Sphere, Helio, and Superfluid all stop at "payment happened." None answer "where's my invoice?", "how do I cancel?", or "can I upgrade?" They're payment processors, not billing protocols.
More importantly, none use transfer hooks. Sphere offers custom payment UIs but no subscriptions. Helio does payment links with no subscription analytics. Superfluid does streaming on EVM but has no mandate enforcement. All of them use token allowances — the subscriber trusts the merchant not to overcharge. If the merchant (or their relayer) misbehaves, the blockchain doesn't stop it.
VelaPay's mandate is enforced by the Token-2022 program on every transfer. The enforcement runs inside the validator, not in application code. An unauthorized pull is rejected at the chain level before the transfer executes — it's not a rollback, not a dispute, not an error message. The transfer literally cannot happen. This is a fundamentally different security model: the subscriber doesn't need to trust the merchant, the relayer, or any intermediary. The chain enforces the agreement.
And none of those tools preserve merchant privacy. Sphere, Helio, Superfluid, Solana Pay, Stripe's Bridge — every one of them publishes transaction data in plaintext. VelaPay is the only payments infrastructure on-chain with a privacy architecture.
3. "Why Solana? Why not Ethereum/L2?"
Token-2022 TransferHook only exists on Solana. This is not a preference — it's an architectural requirement.
The chain-level rejection of unauthorized pulls only works because the Token-2022 program calls Vela's program on every transfer. This creates a mandatory validation gate that cannot be bypassed. EVM token standards (ERC-20, ERC-777, ERC-1155) don't support execution hooks at the token program level. You can build an approval-based billing system on Ethereum, but you can't build one where the token program itself enforces the billing rules on every transfer.
Additionally, Solana's sub-cent transaction fees make billing at monthly (or more frequent) cadence economically feasible. Ethereum gas fees would make a $9.99 monthly subscription cost $2–5 in gas alone. Solana's ~400ms finality means pull confirmations are near-instant, which matters for merchant UX (immediate confirmation vs. waiting for blocks). And Solana's throughput (~65k TPS theoretical) means VelaPay can scale to millions of active mandates without congestion concerns.
4. "What about competitors who tried this before?"
Colosseum's ML-derived project clustering tells the story cleanly. Two clusters cover the payments-infrastructure design space on Solana: v1-c16 "Stablecoin Payment Rails and Infrastructure" (202 projects) and v1-c26 "Simplified Solana Payment Solutions" (223 projects). Across 10+ hackathon cycles, those two clusters have produced zero billing-protocol winners and zero accelerator spots.
The named attempts: Aeon Protocol (6 people, vault escrow, no hooks), Subly (yield-funded consumer app, hardcoded Arcium check), Bundl (NestJS + MongoDB + cron, not a protocol), DMANDATE (mandate branding without mandate enforcement), MISK.FI (concept submission, no on-chain code), Pistis Pay (fork of Next.js SaaS template with Stripe), DePlan (usage-based only, no caps, won $5k in a different category), LinkWave, Sola, and BlockSub (all incomplete). None shipped an SDK, a dashboard, or developer documentation.
The category is not crowded with strong competitors — it is empty of real protocols. Every existing attempt is an allowance wrapper: user delegates a token allowance, a relayer pulls on schedule, application logic is supposed to enforce the agreement. If the relayer misbehaves, the blockchain doesn't stop it. That is an architectural ceiling, not an execution flaw. VelaPay is the first project to step outside it. Colosseum's own guide says it directly: "Don't be afraid to build products that have been attempted before. Timing and execution matter a lot." The idea is proven; execution is what was missing — and VelaPay has shipped 11 surfaces in 19 days to close that gap.
5. "What's the business model?"
Primary revenue: 1% transaction fee on all billing volume via Token-2022 Transfer Fee extension. This is not a separate charge — it's built into the token transfer itself. The fee is collected automatically on every pull payment. At $10M monthly billing volume, that's $100K/month ($1.2M annualized) in protocol revenue.
Phase 3: Revenue-backed lending. VelaPay's MRR Oracle computes aggregate monthly recurring revenue from encrypted billing data without exposing individual merchant revenues. Lenders see a threshold proof ("MRR > $X") rather than the actual number. Vela earns a lending margin on MRR-attested loans — merchants can borrow against their recurring revenue without revealing it.
Later phases: Marketplace fees. Transferable subscription credentials create a marketplace. Merchants can sell or transfer subscriber relationships, and Vela earns a marketplace fee on each transaction. Premium SaaS tiers for advanced dashboard features (custom analytics, team management, compliance reporting) add recurring revenue on top of transaction fees.
The unit economics are attractive: once a mandate is created, every pull generates fee revenue with zero marginal cost. The protocol doesn't need to acquire customers — it needs merchants to integrate @vela/sdk, and every one of their subscribers generates fees.
6. "What's the go-to-market?"
Tier 1: On-chain data/RPC/analytics SaaS — Companies like Helius, Triton, and Shyft have real monthly recurring revenue, their competitors watch their on-chain metrics, and they're developer-friendly (can integrate @vela/sdk in a day). They're the ideal first customers because they already charge recurring fees and already suffer from the privacy problem.
Tier 2: DePIN networks — Decentralized physical infrastructure networks charge node operators recurring fees. They need billing infrastructure and often have token-gated access. VelaPay's subscription credentials (Non-Transferable tokens) map naturally to DePIN's access control model.
Tier 3: AI agent frameworks — Agent budget mandates are the first protocol where an AI agent's spend ceiling is cryptographically enforced on-chain. Agent payments won 1st place in two tracks at the last Colosseum hackathon (MCPay $25k, Latinum $20k), but existing tools use per-request payments or wallet middleware with no spending caps. This is the agentic economy's missing primitive.
The SDK-first approach means every dApp integrating @vela/sdk becomes a distribution channel. The protocol grows with each integration, not with each end user.
7. "Why will merchants adopt this?"
Two reasons, and both are structural:
Reason 1: Every on-chain merchant currently leaks business intelligence. Their subscriber list, revenue, churn rate, and pricing tiers are all public on-chain. Every competitor, investor, and chain analyst can see these metrics in real-time. This is why no serious SaaS business uses on-chain billing today. VelaPay encrypts all billing data via Arcium MPC — subscriber counts, revenue amounts, churn patterns, pricing tiers — all become ciphertext. The merchant sees decrypted analytics on their dashboard. Everyone else sees encrypted blobs.
Reason 2: The alternatives are all worse. Manual billing means chasing payments and high churn. Unlimited token approvals mean the subscriber takes a security risk every time they subscribe (the merchant could drain their wallet). Off-chain schedulers mean centralized infrastructure that can go down and has no enforcement guarantees. VelaPay is the first native billing primitive that's simultaneously trustless (mandate enforced by the chain), private (Arcium encrypted compute), and composable (Token-2022 extensions for fees, metadata, and credentials).
The adoption curve starts with the merchants who feel the pain most acutely: on-chain SaaS companies whose competitors are already scraping their revenue data.
8. "What about AI agents?"
Agent payments won 1st place in two tracks at the last Colosseum hackathon: MCPay took $25k in Stablecoins, Latinum took $20k in AI. The market signal is clear.
But existing agent payment tools have a critical gap. MCPay uses x402 "Payment Required" headers for per-request payments — no recurring, no caps. Latinum manages agent budgets in a Nuxt server — if the server is compromised, budget limits are meaningless. Both treat spending limits as application logic, not protocol enforcement.
VelaPay's mandate system is the first where an agent's spend ceiling is enforced by the blockchain itself. You set: "Agent X can pull max Y USDC per period for service Z." Every pull is validated against the mandate PDA inside the transfer hook. A compromised agent cannot exceed its mandate — the validator rejects the transfer. This isn't middleware budget management that can be bypassed. It's cryptographic enforcement at the token program level.
As the agentic economy scales (a16z, Galaxy Research, and Alliance all identify this as the dominant narrative for 2026+), agents need allowances, not blank checks. VelaPay mandates are the protocol layer for agent commerce — the same way transfer hook mandates are the protocol layer for merchant billing.
9. "What's the tech moat?"
Four layers, each independently difficult to replicate, and compounding over time:
Layer 1: Transfer hook enforcement. The mandate validation runs inside Token-2022's transfer hook, which fires on every transfer of a Vela-billed token. This is Solana-native — EVM chains cannot replicate this architecture because ERC-20/ERC-777 don't support execution hooks at the token program level. Every competitor in the space uses allowance-based delegation, which means application-level trust, not protocol-level enforcement.
Layer 2: Arcium MPC circuits — the only payments infrastructure on-chain with a privacy architecture. The encrypted billing logic runs inside custom Arcium circuits that validate mandate_amount, plan_amount, subscriber_balance, timestamp, expiry, pulls_executed, and max_pulls — all as encrypted inputs. Building these circuits requires deep cryptographic engineering (MPC protocol design, encrypted computation, multi-party key management). The circuits are live in VelaPay today (encrypted-ixs/ with test_arcium_validation.rs covering the path end-to-end). The closest competitor (Subly) hardcoded their budget check to true because they couldn't get the encrypted comparison working. Across the entire 5,400+ Colosseum corpus, only two projects even combine Arcium with Token-2022 extensions — and neither applies it to billing.
Layer 3: Token-2022 composability. Transfer Fee (platform revenue), Metadata Pointer (on-chain plan terms), and Non-Transferable (subscription credentials) all combine in a single protocol. This composability is unique to Solana's Token-2022 program and creates a switching cost: once a merchant's billing logic is tied to Vela mandate PDAs, migrating means re-creating mandates with every subscriber. The mandate PDA encodes the customer relationship on-chain.
Layer 4: Shipping velocity as execution moat. 628+ commits in 19 days across 11 repositories. A well-funded team starting today inherits that deficit on a protocol that is already live on devnet with encrypted billing compute, a packaged SDK, hosted checkout, subscriber portal, embeddable widget, devnet synthetic load, and a published webhook library — each consuming @vela/sdk as the canonical integration path. The technical moat is Solana-native. The execution moat is what keeps it uncatchable while the technical moat ossifies.
The moat compounds: transfer hooks provide the enforcement, Arcium provides the privacy nobody else has shipped, Token-2022 extensions provide the revenue model and subscription primitives, and velocity keeps the distance growing. Replicating one layer is hard. Replicating all four, integrated into a single billing flow and already live, requires rebuilding the entire protocol from scratch — and catching a moving target.
10. "What are the biggest risks?"
Risk 1: Go-to-market is the hardest problem, not the protocol. On-chain billing merchants are rare today. The protocol works, but finding named design partners with real MRR who need private recurring billing is the critical path. Mitigation: SDK-first approach means every integration is a distribution channel; targeting on-chain SaaS companies (Helius, Triton, Shyft) who already feel the privacy pain.
Risk 2: Arcium dependency. The privacy layer depends on an external MPC network. If Arcium has downtime or changes their API, VelaPay's encrypted billing is affected. Mitigation: fail-closed design — if Arcium is unavailable, pulls are blocked entirely, not degraded to plaintext. Privacy is never optional. The protocol is architected so the billing primitive can operate without Arcium (fail-closed on privacy, not on correctness), but we treat private compute as a hard requirement in production — that's the differentiation.
Risk 3: Token-2022 adoption. VelaPay requires billing tokens to be Token-2022 mints. Standard USDC (the largest stablecoin by volume) is an SPL token, not Token-2022. This limits the addressable market to Token-2022 stablecoins. Strategy: target PYUSD (PayPal's stablecoin, which uses Token-2022), USDY, and new stablecoin issuers who are choosing Token-2022 as their default standard. The bet is that new stablecoins will default to Token-2022, and the trend supports this — every major new stablecoin launch in 2025-2026 has considered Token-2022 for its extension support.
Risk 4: Solo founder concentration — a staffing question, not an execution one. 11 shipped surfaces in 19 days is the output a Series A hire plan is supposed to produce. The shipping velocity (628+ commits, ~33/day) is the direct answer: execution is not the bottleneck. Hires arrive when scaling economics demand them — dedicated protocol engineers as on-chain surface area grows, a GTM lead when design partners ramp — not because the roadmap is stuck. The modular repo structure means specialized hires slot cleanly into protocol, SDK, or product without rearchitecture. Concentration on one founder today is a deliberate choice, not a vulnerability: it is what's letting the protocol outship every funded team in the category.
11. "What's the competitive landscape?"
Stripe: $1T+ volume, trusted intermediary, sees all merchant data. 2.9% + $0.30 per transaction, 2–7 day settlement. The incumbent — but they're a centralized payment processor, not a protocol. Their Bridge acquisition ($1.1B) validates the stablecoin payments thesis.
On-chain payment tools:
- Sphere — Custom payment UIs, no subscription billing
- Helio — Payment links and checkout, no subscription analytics
- Superfluid — Streaming only, EVM-based, no mandates, no transfer hooks
Hackathon attempts (all failed):
- Aeon Protocol (Radar, 6 people, 0 updates) — Vault escrow model, no transfer hooks, no privacy, no SDK
- Subly (Cypherpunk, 1 person) — Yield-funded consumer app, Arcium budget check hardcoded to
true, routes payments through PayPal - Bundl (Cypherpunk, 6 people, 0 updates) — NestJS + MongoDB + cron job, not a protocol
- DMANDATE (Cypherpunk, 1 person, 0 updates) — Mandate terminology without mandate enforcement, backend relayer
- MISK.FI (Cypherpunk, 1 person, 0 updates) — Concept submission, no on-chain code
- Pistis Pay (Cypherpunk, 2 people) — Fork of Next.js SaaS starter with Stripe, no Solana program
Colosseum cluster evidence:
- Cluster
v1-c16(Stablecoin Payment Rails): 202 projects, 0 billing winners - Cluster
v1-c26(Simplified Solana Payments): 223 projects, 0 billing winners - Zero subscription-billing companies across Colosseum C1–C4 accelerators
- Across the full 5,400+ corpus, only two projects combine Arcium + Token-2022 —
incognito-protocol(confidential marketplace) andzenlok(token vesting). Neither does billing. - Zero payments-infrastructure projects, anywhere, with a privacy architecture
The honest framing: VelaPay has no direct competitors. It has adjacent players who touch payments but don't solve billing (and none of whom have privacy), and it has failed hackathon projects that tried and didn't ship. Nobody is building what VelaPay is building — the Colosseum data says so at the cluster level, not just project-by-project.
12. "How does the privacy work technically?"
Arcium MPC (Multi-Party Computation) runs billing logic on encrypted data. The key architectural insight is that Arcium computation is asynchronous — it cannot run inside a transfer hook synchronously. So VelaPay uses a two-phase pattern:
Phase 1: Pre-validation. When a pull is requested, Arcium validates the following as encrypted inputs:
mandate_amount— the subscriber's authorized amountplan_amount— the merchant's plan pricesubscriber_balance— available fundstimestamp— is the pull within the billing period?expiry— is the mandate still active?pulls_executedvsmax_pulls— has the subscriber already been billed this period?
Only the boolean result (approved/denied) is revealed. Arcium stores a PullApproval PDA via callback, proving the encrypted computation passed without revealing any of the underlying values.
Phase 2: Transfer hook check. The transfer hook doesn't need to run the Arcium computation — it just checks that a valid PullApproval PDA exists. If it does, the transfer proceeds. If it doesn't, the transfer fails at the validator level.
Billing records are encrypted blobs stored on-chain. Only the merchant can decrypt them. On-chain observers see encrypted data — they can't determine subscriber counts, revenue amounts, or churn patterns.
MRR Oracle (Phase 3) computes aggregate monthly recurring revenue across merchants without exposing individual revenues. A lender sees a threshold proof ("this merchant's MRR exceeds $X") without seeing the actual number. This enables revenue-backed lending with privacy — the merchant proves they have sufficient recurring revenue without revealing what it is.
The privacy is fail-closed: if Arcium is unavailable, pulls are blocked entirely, not degraded to plaintext. Privacy is never optional.