vela-admin

Internal admin dashboard for the VelaPay protocol team. Separate Cloudflare Worker with distinct auth model, never exposed to merchant traffic.

Purpose and Role

• Protocol monitoring and health views (TVL, mandate counts, merchant counts, volume).
• Keeper write operations — monitor, force-retry, control keeper workers.
• Protocol config management — update transfer hook, keeper authority, token configs.
• Emergency controls — pause protocol, unpause protocol, admin cancel mandates.
• Merchant management — lookup merchants, inspect subscriptions, investigate issues.
• Observability — event stream, reconciliation, cost tracking.
• Immutable audit trail — every admin action logged with wallet, timestamp, parameters, result.

Tech Stack

Technology	Version	Purpose
React	19.x	UI library (admin SPA)
Hono	4.12.x	API layer (Cloudflare Worker)
Cloudflare Workers	—	Compute runtime
Cloudflare Service Bindings	—	Internal RPC to dashboard Worker
@vela/sdk	latest	Protocol interactions, PDAFactory
Tailwind CSS	4.2.x	Styling

Directory Structure

vela-admin/
├── src/
│   ├── app/                   # React SPA
│   │   ├── components/
│   │   │   ├── monitoring/    # Protocol health, TVL, mandate counts
│   │   │   ├── keepers/       # Keeper management, retry controls
│   │   │   ├── merchants/     # Merchant lookup, subscription inspection
│   │   │   ├── emergency/     # Pause/unpause, admin cancel
│   │   │   ├── config/        # ProtocolConfig, TokenConfig management
│   │   │   └── audit/         # Immutable audit trail viewer
│   │   └── hooks/             # Data fetching hooks
│   ├── worker/                # Hono Worker (backend API)
│   │   ├── index.ts           # Worker entry, service binding setup
│   │   ├── auth.ts            # SIWS verification against ProtocolConfig.admin
│   │   └── routes/
│   │       ├── monitoring.ts
│   │       ├── keepers.ts
│   │       ├── emergency.ts
│   │       ├── config.ts
│   │       └── audit.ts
│   └── lib/
├── wrangler.toml              # Service binding: DASHBOARD_SERVICE → vela-dashboard
└── package.json

Deployment Target

• Cloudflare Workers: Separate Worker with service binding to dashboard.
• Domain: Internal-only (not on merchant-facing domain).

Dependencies

What It Depends On

Dependency	Type	Purpose
vela-dashboard	Service binding	Backend API access, D1 operations
@vela/sdk	npm package	Protocol interactions, on-chain reads
ProtocolConfig PDA	On-chain	Admin wallet verification

What Depends on It

Nothing. The admin dashboard is a terminal consumer — no other repo depends on it.

Current Status

• v1.2 complete: Full admin operations dashboard with monitoring, emergency controls, and audit trail.
• v1.7 updates: TokenConfig management (init, update, kill-switch).
• v1.8 updates: Stream settlement keeper monitoring, multi-token admin views.

Notable Design Decisions

Service Binding (Not Direct D1 Access)

Admin never directly accesses D1. All database operations go through service binding to the dashboard Worker. This ensures schema coordination, auth isolation, and audit trail consistency.

SIWS Auth Against On-Chain Admin Field

Admin auth is wallet-gated — verified against ProtocolConfig.admin on-chain. Not email-based, not org-based. Only wallets listed in the ProtocolConfig PDA can access admin operations.

Browser-Signs, Server-Logs Model

Admin transactions are signed in the browser (wallet) and logged on the server. Private keys never leave the browser. Every action has a wallet signature for non-repudiation.

Typed Confirmation Gates

Destructive operations (pause, cancel) require typed confirmation (enter operation name) and TOTP 2FA. Critical operations (unpause after incident, update transfer hook) require a second admin approval.

On-Chain Credential Derivation

Admin operations that interact with on-chain accounts derive credentials from current on-chain state at transaction time, not from D1 cache. This prevents stale-cache bugs during emergency operations.

Separate Worker (Why Not Part of Dashboard)

• Different auth model: SIWS vs email-primary. No shared session logic.
• Never exposed to merchant traffic: Admin traffic is isolated from merchant endpoints.
• Independent deployment: Admin can be updated during incidents without touching merchant code.
• First-class ops tooling: Admin is a first-class repo, not an implementation detail inside the dashboard.