Solution architecture · C4 model
A stablecoin fintech, drawn the way builders and boards both read it.
This is a vendor-neutral reference architecture — the shape of any stablecoin fintech, whether you build it in-house or assemble it from providers, and independent of which specific service you use. We use the C4 model — Context, Containers, Components — so an executive can grasp the landscape in ten seconds and an engineer can find where a change lands. Each view is annotated by a technical product manager on what it means for the product and the roadmap.
- C1 · Context→Who uses the platform and which external systems it depends on.
- C2 · Container→The deployable/services inside the platform and how they split responsibility.
- C3 · Component→Inside one container — here, the Ledger · Treasury core that holds the truth.
C1 · System context
People, the platform, and the outside world
To everyone outside, StablePeg is one system. Underneath, every provider is its own latency and failure domain.
People
System
External systems
- End customer→onboards, holds balance, spends card, sends money
- End customer→deposits and withdraws stablecoin on-chain, and transfers to other users
- Platform→verifies identity (KYC/KYB) before any regulated product is provisioned
- Platform→screens users and transactions with fraud + on-chain KYT
- Platform→mints/burns against reserves via the issuer/custodian
- Ops & compliance→works cases, disputes, and reconciliation inside the platform
The board-level story fits on this one diagram: identity and risk gate access, the platform holds the money, and every external provider sits behind an adapter — so it is replaceable, and swapping a KYC or card vendor is a contained change, never a platform rewrite.
C2 · Containers
Inside the platform: services split by responsibility
Grouped by role. The one rule that holds it together: Ledger · Treasury is the single source of truth; everything else keeps a projection and reconciles back to it.
Experience edge
Product services
Money core
Platform backbone
Data stores
This is where roadmap bets live. Product services talk through the event backbone and each keep a read-model, never inventing their own balance — they subscribe to the ledger. Because they sit on a stable money core, we can launch a new card program or payout corridor without touching how money is actually held. Independent deploys, contained blast radius.
C3 · Component
Inside Ledger · Treasury — the container that holds the truth
Zooming into the money core. Everything here is append-only and event-sourced, so we can always answer “what did we believe, and when.”
Ledger · Treasury container
This component is why Finance, Compliance, and Support can trust one number. Authorization holds, clearing, and settlement are separate postings against the same journal, never overwritten, and balances are a projection that can always be rebuilt — so when anyone disagrees with a customer, the reconciliation engine’s break is the artifact that settles it. That’s a support-cost and trust win, not just an engineering nicety.
See it in motion