Fort Knox — The Kronos Treasury

One-Line Pitch

A single payment and credit service that every Kronos app plugs into — so none of them have to think about wallets, exchange rates, Stripe fees, or transaction ledgers.

The Problem It Solves

Every Kronos app that touches money needs the same five things: a wallet system, a way to charge users, a currency conversion layer, a transaction ledger, and a way to handle payment failures gracefully. Building this independently in each app is expensive, inconsistent, and means bugs get replicated across codebases.

More importantly: Stripe charges ~11% on small transactions. For a £2.50 internal credit top-up, that’s £0.27 per transaction. Running those through an internal credit layer (PGLB — Proof Gram Liger Bubble) instead of Stripe turns that 11% into 0% for most day-to-day operations.

Fort Knox solves both problems: centralised treasury so only one codebase handles money, and an internal credit system that short-circuits Stripe for repeat users.

What It Does

Core Services

The Credit System (PGLB)

User tops up £20 with Stripe  →  Fort Knox credits 2000 PGLB to their wallet
User buys something for £5    →  Fort Knox debits 500 PGLB  (no Stripe call)
User needs a refund           →  Fort Knox credits back 500 PGLB  (instant)
User wants cash out           →  Fort Knox initiates Wise transfer

The net result: Stripe gets called once (on top-up). Everything else is internal. For apps with high repeat-purchase rates (like Kendo Cards↗), this dramatically reduces transaction costs.

Architecture

App Layer
├── kendocards.com    → POST /api/v1/checkout
├── proudly.app       → POST /api/v1/debit
├── proofserver       → GET  /api/v1/balance
└── any future app    → same API

        ↓  API Key auth (X-API-Key header)

Fort Knox (Go service — fortknox.krisadamstv.com)
├── /api/v1/wallets        Wallet CRUD
├── /api/v1/rates          Live FX rates
├── /api/v1/checkout       Create a charge intent
├── /api/v1/debit          Debit a wallet
├── /api/v1/credit         Credit a wallet
├── /api/v1/transactions   Ledger read
└── /api/v1/payout         Trigger Wise payout

        ↓

PostgreSQL (Supabase)   Stripe API   Wise API

Who Uses Fort Knox

The design intention: no Kronos app should ever integrate Stripe directly. They integrate Fort Knox, and Fort Knox handles the Stripe relationship. This keeps all payment compliance, key management, and ledger hygiene in one place.

The Numbers

For a product like Kendo Cards — where customers buy 10 cards at once, then reorder next quarter — the credit model pays for itself immediately.

Auth Model

Every app gets an API key (fk_app_name_uuid). Keys are scoped to specific operations — a read-only key can check balances but not debit. Keys can be rotated without touching the consuming app (Fort Knox stores the rotation state).

# Health (no auth)
curl https://fortknox.krisadamstv.com/health

# Rates (API key required)
curl https://fortknox.krisadamstv.com/api/v1/rates \
  -H "X-API-Key: fk_your-api-key"

# Debit a wallet
curl -X POST https://fortknox.krisadamstv.com/api/v1/debit \
  -H "X-API-Key: fk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"wallet_id": "wlt_abc123", "amount_pglb": 500, "idempotency_key": "order_xyz"}'

Infrastructure

• Language: Go
• DB: PostgreSQL via Supabase
• Live at: https://fortknox.krisadamstv.com
• Port: 8083 (internal), Caddy terminates TLS
• Process management: systemd, auto-restart

Constraints & Reality Check

• Single point of failure: Fort Knox down = all Kronos apps’ payments are down. Needs health alerting and quick restart path.
• Supabase dependency: If Supabase has an outage, Fort Knox can’t read/write the ledger. Mitigation: read replicas and write queuing.
• Stripe API changes: Stripe has changed their API semantics before. Fort Knox is the single point of adaptation — one update fixes all apps.
• PGLB is not regulated currency: It’s an internal credit system, not a regulated e-money instrument. Keeping it clearly “credits for Kronos services” keeps it outside FCA scope.
• Key management: API keys stored as bcrypt hashes in the DB. Leaking a key doesn’t expose the DB. Rotation is instant.

Next Actions

• Add wallet-level spending limits (cap how much an app can debit per day)
• Build PGLB top-up UI (self-serve credit purchase page)
• Rate caching with 60s TTL (currently hits Wise API on every /rates call)
• Alerting on failed transactions > N per minute
• Audit log endpoint for per-app transaction history