Architecture

T-Suite is a set of containerised Node.js / TypeScript services behind three single-page web apps, backed by MongoDB and Redis, connected by Kafka and gRPC, and anchored to smart contracts on several EVM chains and Cardano. This page describes the shape of the system; for a less technical tour see Architecture & Integrations.

System diagram

  Browsers (investors, issuers, asset managers, admins, transfer agents)
        │  HTTPS (REST)                         ▲  Server-Sent Events
        ▼                                       │
┌───────────────────────────────────────────────┴──────────────────────┐
│  T-Suite app (Marketplace)  ·  Admin console  ·  Transfer Agent app  │
│               single-page apps — React / TypeScript                  │
└──────────┬──────────────────────────┬─────────────────────┬──────────┘
           │                          │                     │
┌──────────▼─────────┐   ┌────────────▼─────────┐  ┌────────▼───────────┐
│  Marketplace API   │◄──┤  Admin API           │  │ Transfer Agent API │
│  (main API, jobs,  │   │  (HMAC-signed proxy) │  │                    │
│   SSE stream)      │   └──────────────────────┘  └────────────────────┘
└───┬────────┬───────┘          ▲     gRPC (internal calls)     ▲
    │        └──────────────────┴───────────────────────────────┘
    │                         Kafka (events)
    │   ┌──────────────────────┬──────────────────────┬─────────────────┐
    ▼   ▼                      ▼                      ▼                 ▼
┌──────────────┐   ┌──────────────────┐   ┌──────────────────┐  ┌──────────────┐
│ Notification │   │  Event service   │   │ Dividend service │  │ Cardano      │
│ service      │   │  (chain indexer) │   │                  │  │ service      │
└──────────────┘   └────────┬─────────┘   └──────────────────┘  └──────┬───────┘
                            │                                          │
┌───────────────────────────▼──────────────────────────────────────────▼──────┐
│  Chains: Base · Ethereum · Polygon · Arbitrum (+ EVM testnets) · Cardano    │
└─────────────────────────────────────────────────────────────────────────────┘

  Data: MongoDB · Redis · cloud blob storage
  Third parties: SumSub · Stripe · Bridge.xyz · SendGrid · Gmail · Anthropic · RPC providers

Frontend applications

App	Who uses it	What it contains
T-Suite app (Marketplace)	Investors, issuers, asset managers	Investor, Issuer and Asset Management platforms, Distribution Hub, Structuring, Trading, Stablecoin Studio, Custodian Wallet. Served under Libertum’s domain and under each whitelabel tenant’s custom domain.
Admin console	Libertum administrators	SuperAdmin operations: fees, plans, country restrictions, approvals, platform settings
Transfer Agent app	Transfer agents	Cap table, wallet whitelist decisions, transfer journal, transactions

All three are statically built single-page apps. They talk to the backend over HTTPS (JSON REST) and, for live updates, over a Server-Sent Events stream.

Backend services

Service	Responsibility
Marketplace API	The main API. Users and onboarding, offerings, orders and payments, subscriptions and modules, agreements and e-signature, Custodian Wallet, redemptions, governance, Distribution Hub, Structuring, Trading, Stablecoin Studio, scheduled jobs, and the real-time notification stream
Admin API	SuperAdmin operations (fees, country restrictions, approvals). Calls from the admin console into the marketplace API are signed server-to-server
Notification service	Email delivery and in-app notifications
Event service	Blockchain event indexer: polls each supported chain on a schedule and publishes what it finds to Kafka
Dividend service	Dividend processing
Transfer Agent API	Backend for the Transfer Agent app
Cardano service	CIP-20 and CIP-113 token operations and Cardano custodian signing

The Marketplace API is organised into components, one per domain — for example structuring, aiUsage, sseNotifications, custodianWallet, gasTreasury, bridge (T-Pay via Bridge.xyz), governance, p2p, hosting, investorStatements, agreements, redemption, distributionHub, countryRestrictions, feeConfig, and the XRPL infrastructure components xrplPlatform, xrplCredentialIssuer and xrplReserve.

Messaging: Kafka and gRPC

The services use two complementary channels:

• Kafka — asynchronous events. Producers publish and move on; consumers react in their own time. Two broad topic groups exist: notification topics (services ask the notification service to send an email or in-app notification) and product-update topics (the event service and the admin API tell the marketplace API about on-chain events and approval decisions). Real-time browser notifications are also fed from Kafka into the SSE stream.
• gRPC — synchronous internal calls. When one service needs an answer from another straight away — for example a user or KYC lookup, an approval action, or reading and marking in-app notifications — it uses gRPC. gRPC connects the marketplace, admin, notification and transfer agent services.

Neither Kafka nor gRPC is exposed outside the platform. Integrators only ever see the HTTPS API and the SSE stream.

Scheduled jobs

Recurring work runs with node-cron inside the Marketplace API — about two dozen jobs, such as expiring unpaid orders, opening Coming Soon listings at their launch time, redemption processing, the platform notification digest, monthly AI-usage billing and subscription expiry.

Because the API can run as more than one instance, each job takes a Redis-based lock before it runs, so only one instance executes a given job at a time.

Chain indexing is separate: the event service polls each chain on its own schedule and publishes events to Kafka.

Real-time delivery

The browser receives live updates (notifications, whitelist decisions, KYC/KYB approvals and similar) over a Server-Sent Events stream served by the Marketplace API. The stream is opened with a short-lived one-time ticket, so the access token never appears in a URL. See Real-time & webhooks.

Data and storage

Store	Used for
MongoDB	Primary document store — users, offerings, orders, subscriptions, agreements, custodian wallets, audit records and more
Redis	Session pinning, short-lived codes and tickets, caches, and the locks that keep scheduled jobs single-instance
Cloud blob storage	Uploaded files — branding, offering documents, KYC/KYB-related uploads, generated PDFs

Custodian Wallet private keys are stored encrypted (AES-256-GCM).

Chain access

EVM chains are reached through commercial RPC providers with failover. Cardano chain data comes from a Cardano data provider, and Cardano transactions are built and signed in the Cardano service. See Smart contracts for what runs on which chain.

Third-party integrations

Provider	Used for
SumSub	KYC (individuals) and KYB (entities)
Stripe	Card payments, subscription billing, Stripe Connect for issuer payouts, gas charges for custodian transactions
Bridge.xyz	T-Pay fiat on/off-ramp (limited availability)
SendGrid	Transactional email
Gmail (read-only OAuth)	Distribution Hub inbox connection
Anthropic Claude models	Libby AI and Structuring
Cloudflare	Custom domains for whitelabel tenants (Cloudflare for SaaS)
Commercial RPC providers	EVM chain access, with failover
Sentry	Error tracking

Inbound callbacks from providers (for example SumSub verification results and Stripe payment events) are verified by signature before they are processed.

Deployment posture

• Backend services are built as container images and run as containerised services on cloud VMs. Each image must boot successfully in a check run before it is rolled out.
• The T-Suite web app is a static build served from a CDN edge; whitelabel custom domains are served the same app.
• Production and the testing environment are separate deployments with separate data — see Environments & networks.