Skip to content
Capxul V2

Capxul V2 Architecture

Technical Design Document - March 2026
Start Reading Implementation Roadmap

Document Structure

Section titled “Document Structure”

This document defines the complete V2 architecture for Capxul, a financial operations platform on stablecoin rails. It is organized bottom-up by system layer, from on-chain infrastructure through money movement, data, identity, and operations.

Audience: Engineers, designers, and Claude Code — the daily consumers building from this architecture.

Status: Design Complete, Pending POC Validation

Part 1: Foundation

On-chain infrastructure (Safe, Payment Module, LlamaPay, Zodiac), smart account infrastructure (Openfort, session keys, auth, recovery).

Part 2: Money Movement

Payments and streaming, fiat ramp facade (off-ramp/on-ramp), card facade (virtual cards), cross-chain bridge facade.

Part 3: Data and Intelligence

Financial document layer, event indexing, dashboard metrics, and scheduled reporting.

Part 4: Identity and Compliance

KYC/KYB via Shufti Pro, tiered verification, jurisdictional thresholds.

Part 5: Operations

Phased independence from Openfort, implementation roadmap, open questions.

Part 6: Platform Engineering

Cross-cutting concerns: security model, testing, deployment, monitoring, authorization, and other platform-level architecture topics.

Core Principles

Section titled “Core Principles”

Three architectural invariants govern the entire V2 system:

  1. Pull-based architecture. All funds flow through the employee’s smart account. Salary streams accrue to the smart account. Downstream routing (bank, external wallet, virtual card, bridge) is configured by the recipient and executed from the smart account. Funds never skip the smart account.

  2. Infrastructure sovereignty. Every critical component has a path to self-hosting or is on-chain and immutable. Key management (OpenSigner), recovery (Shield), smart account contracts, Safe modules — all are open source. The hosted API dependency is temporary and replaceable.

  3. Facade pattern for external providers. Four facades (fiat ramp, card, bridge, identity verification) abstract all external providers behind common interfaces. Multiple providers can be active per facade, routed by geography. Adding or swapping a provider is a backend configuration change, not a platform rewrite. Convex is the source of truth, never the provider. See Chapter 1 for the definitive reference.