Documentation

Architecture

Token-x is four backend microservices, one Next.js frontend, and one shared PostgreSQL instance. Services communicate over HTTP and Redis pub/sub — no message broker required.

Services

apiGo:8100

Core REST API — auth, compliance, tokenization, ATS order management, notifications. Single writer to PostgreSQL. Dispatches blockchain requests to the chain service over HTTP.

chainGo:8101

EVM blockchain connector — nonce manager, transaction queue, event listener. Handles Avalanche, Ethereum, Polygon, Optimism, Base, and Hedera. Publishes chain events to Redis pub/sub.

matcherRust:8200

ATS order-matching engine. In-memory order book per offering using DashMap. Zero GC pauses, sub-millisecond matching. Persists fills to PostgreSQL. Subscribes to order events via Redis.

kytGo:8300

Know-Your-Transaction pipeline. Consumes chain events from Redis, calls Trustformer risk API, raises surveillance alerts. Runs as a separate process so chain-event processing never blocks the API.

webNext.js:3100

Next.js 14 App Router frontend — per-persona route groups (investor, issuer, compliance, transfer-agent, tokenization-agent, admin, ATS-operator). TanStack Query for dashboard polling.

Data Flow

web (Next.js :3100)
  └─► api (Go :8100)
        ├─► PostgreSQL (schema per service)
        ├─► Redis (pub/sub + task queue + nonce)
        ├─► chain (Go :8101)
        │     ├─► EVM nodes (Avalanche, Ethereum, Polygon…)
        │     └─► Redis pub/sub → chain events
        └─► matcher (Rust :8200)
              ├─► Redis (order/fill events)
              └─► PostgreSQL (matcher schema)

kyt (Go :8300) ← Redis (chain events) → Trustformer API

Database Schemas

api

users, investors, wallets, offerings, subscriptions, payments

chain

transactions, dead_letters, monitoring

compliance

transfer_restrictions, rules, kyb

audit

events (append-only, no DELETE/UPDATE)

matcher

orders, fills

kyt

tx_risk_scores, alerts

surveillance

alerts

lms

courses, lessons, enrollments, quizzes

public

goose migrations

Design Principles

Single writer

Only the API service writes to PostgreSQL. All other services read or write via the API over HTTP.

Chain abstraction

The API service never calls a blockchain directly — all on-chain operations go through the chain service, keeping signing keys out of the API process.

Compliance as a gate, not a layer

ERC-3643 enforces whitelist, freeze, and force-transfer at the smart-contract level. Application-layer compliance (KYC/AML) and contract-layer compliance are independently enforced.

Event-driven chain updates

The chain service publishes events to Redis pub/sub. The API service (cap table, fill settlement) and KYT service consume these asynchronously — no polling.

Temporal for multi-step flows

Redemption, key rotation, TWAP orders, and KYC approval chains run as Temporal workflows. Temporal provides durable execution with automatic retries and exactly-once guarantees.

Modular signers

The chain service supports a Signer interface: local hex key (dev/testnet) or Fireblocks MPC (production). Switch via SIGNER_BACKEND env var — no code changes.

Supported Networks

AvalancheEthereumPolygonOptimismBaseHederaSolanaAptosXRPLCordaProvenance

API Reference →Smart Contracts →East Africa Guide →