AZ
Back to constellation
Web3Draft

Settleo

Non-custodial P2P / OTC crypto-settlement platform built as ~24 independent services around a single authoritative ledger.

TypeScriptNode.jsgRPCTigerBeetleRedisMongoDBSolidityNext.js 15React 19styled-components

Overview

What it is

Settleo is a non-custodial peer-to-peer and OTC crypto-settlement platform, built as roughly two dozen independently deployable services. Retail users trade through the consumer app, desks trade through the business app, and operators watch it all from an internal console — but every one of those surfaces is downstream of the same rule: value only moves in one place.

The problem

When money is on the line, "a bunch of services that each touch balances" is a recipe for double-spends and irreconcilable state. The hard part isn't building one service — it's building sixteen-plus of them without letting any two of them disagree about how much money exists.

The architecture

Settleo is organised around a small set of load-bearing decisions:

  • A single-writer ledger. settleo-ledger is the sole writer to TigerBeetle and exposes double-entry settlement over gRPC. No other service writes balances.
  • A deny-by-default gateway/BFF. settleo-gateway terminates the internet: HMAC + token auth, deny-by-default authorization, rate limiting, idempotency, signed routing, and WebSocket fan-out — backed by a Redis-only store.
  • AWS-IAM-style authz. settleo-iam issues and introspects tokens and evaluates policies with deny-wins semantics.
  • Reorg-safe indexing. settleo-indexer ingests per-chain EVM events and credits the ledger reorg-safely, so a rolled-back block never leaves a phantom balance.
  • A shared, hardened foundation. The @settleo/* libraries (config, validation, auth/HMAC, events, ledger-client) carry the cross-cutting controls, targeting OWASP ASVS L2+ platform-wide and L3 for the auth/events/ledger-client packages.

Highlights

  • Money is modelled as integer minor units (u128-safe), never floats.
  • Every inbound byte — HTTP, gRPC, events, webhooks, chain data — is treated as untrusted data, never instructions, and validated at the boundary.
  • A STRIDE threat model was produced before code, mapping every threat to a mitigation and at least one security test.

Related write-ups

Write-up in progress

A companion post for this project is being drafted. Check back soon.