vela-demo

A live, public-facing demo surface that exercises the full VelaPay billing funnel — subscribe → execute_pull → upgrade → cancel — against devnet staging. Doubles as a dogfooding harness for the protocol team and a "this actually works" anchor for prospects evaluating VelaPay.

Purpose and Role

• Show prospects what subscribing, paying, upgrading, and cancelling actually look like end-to-end on devnet.
• Force the protocol team to use their own SDK from a fresh app every release — friction here surfaces friction the average integrator will hit.
• Provide a fixed reference implementation: when integrators ask "how do I wire X with the SDK?", vela-demo is the answer.
• Validate the full Arcium round-trip in a real-world UI (the demo is one of the few surfaces that exercises @arcium-hq/client directly).

Tech Stack

Technology	Version	Purpose
TypeScript	^5.8.x	Language
Bun	1.3.x	Package manager
Vite	7.x	Build tool
React	19.2.x	UI library
Hono	^4.12.x	Worker API surface
@vela/sdk	local link	Full SDK — every protocol interaction
@vela/brand	local link	Brand tokens, fonts, primitives
@arcium-hq/client	0.9.3	Arcium MXE client — encrypts inputs, decrypts callback payloads
@coral-xyz/anchor	^0.32.1	Anchor TS client
@solana/web3.js	^1.98.x	Solana client
@solana/spl-token	^0.4.14	Token-2022 helpers
@solana/wallet-standard-features	^1.3.x	Wallet Standard discovery
@wallet-standard/{app,base,react}	latest	Wallet connection bridge
Tailwind CSS	4.2.x	Styling
@cloudflare/vite-plugin	^1.13.x	CF dev integration (assets binding)
Biome	latest	Lint + format

Directory Structure

vela-demo/
├── src/
│   ├── client/               # React app
│   ├── worker/
│   │   └── index.ts          # Hono Worker (CF assets + API routes)
│   └── lib/
├── scripts/
│   ├── init-devnet.ts        # Seeds the demo merchant + plan on devnet
│   └── demo-runner.ts        # Headless walkthrough for CI
├── tests/                    # bun:test
├── public/                   # Static assets
├── index.html                # Vite entry
├── vite.config.ts
├── wrangler.toml
└── package.json

Deployment Target

• Cloudflare Worker with assets binding (./dist/client served as SPA, Worker handles /api/*).
• Single-page-application not-found handling enabled for client-side routing.
• Env vars (in wrangler.toml):
  • SOLANA_RPC_URL — devnet RPC
  • VELA_PROGRAM_ID — CVM6UqbwKgHckZzm8R2qbN3BWhCTdk1PsSeEQLchkwKT
  • ARCIUM_CLUSTER_OFFSET — 456 (devnet cluster)

Operational Workflow

# First-time setup
bun install
bun run init                 # seeds demo merchant + plan on devnet

# Local development
bun run dev                  # Vite dev server with CF Worker shim

# Headless demo runner (used by CI smoke tests)
bun run demo

# Deploy
bun run deploy               # vite build && wrangler deploy

Consumers / Dependencies

Source	How
@vela/sdk	Every protocol interaction
@vela/brand	Tokens, fonts, primitives
@arcium-hq/client	MXE inputs
Devnet staging	Target of all transactions
Wallet Standard wallets	Subscriber-side connection

Notable Design Decisions

Public-Facing

The demo ships at a stable URL so the project has a fixed "click here, watch it work" link for prospects, partners, and conference talks. Local-only demos rot — the deploy enforces that the surface stays current.

Real Arcium, Real Devnet

The demo doesn't mock Arcium or the protocol. Every action issues a real devnet transaction with real MXE round-trips. Issues that only manifest with real network behavior (RPC retries, MXE timeouts, wallet popup ordering) surface here first.

Headless Demo Runner

scripts/demo-runner.ts walks the funnel without a UI — useful for CI smoke and for scripted recordings. Keeps the funnel logic separated from React state so future surfaces can reuse it.

Brand-Faithful

The demo imports @vela/brand at full fidelity. It's the closest thing the team has to a "what does VelaPay look like for an end customer?" reference, and discrepancies between the demo and the merchant dashboard are treated as bugs in the brand layer.

Related

• Brand tokens: vela-brand →
• SDK: vela-sdk →
• Devnet program IDs: Environment Registry →
• Synthetic E2E worker (lower-level coverage): vela-synthetic →