m.moddie / dev
← All projects
Project / 08

CryptoExchange

An archived P2P exchange prototype with ledger accounting and replaceable blockchain adapters.

Python · P2P · Multi-chainCryptoExchangeFastAPI / PostgreSQL / Redis / Web3.py / Next.js
01 / About the project

About the project

An archived P2P exchange prototype with ledger accounting and replaceable blockchain adapters.

02 / Architecture study

P2P exchange around accounting invariants

CryptoExchange is an unfinished white-label Telegram P2P exchange. The valuable part is its backend model: offers, deals, disputes and reputation sit around a double-entry ledger and replaceable blockchain clients.

03 / Product idea

Makers publish fiat offers, takers open deals, and crypto is held in the internal ledger until completion, cancellation or dispute resolution. Network indexers detect deposits, while dedicated workers process accounting, withdrawals and notifications.

Transaction boundary

Business state is committed in PostgreSQL; external chains are handled through adapters and workers.

APPLICATION FLOW
01

Telegram Mini App

User flows

02

FastAPI

Auth and commands

03

P2P modules

Offers, deals, disputes

04

Ledger + UoW

Holds and atomic transitions

05

Chain registry

TON, EVM and TRON adapters

06

Workers

Deposits, withdrawals, notifications

Architectural decisions

01

Ledger is the source of truth

Available and held funds are represented by balanced entries instead of mutable balance columns.

02

Atomic deal transitions

Unit of Work and row locks keep deal status, offer capacity and accounting mutations in one transaction.

03

Uniform business modules

Users, offers, deals, disputes and reputation follow the same model, schema, repository, service and provider layout.

04

Replaceable chain clients

BaseRPC and BaseIndexer isolate application logic from TON, EVM and TRON implementations selected through a registry.

05

Separate operational processes

Deposit, withdrawal, ledger and notification workers can restart and scale independently from the API.

Project map

The module boundaries describe the intended exchange lifecycle more clearly than the unfinished interface.

CRYPTOEXCHANGE / BACKEND
CRYPTOEXCHANGE / BACKEND
backend/srcapplication root
core/database/async engine · UoW · base repository
modules/accounting/ledger · holds · settlements
modules/p2p/exchange domain
offers/maker listings and available volume
deals/paid · complete · cancel lifecycle
disputes/review and resolution
reputation/post-deal reviews
payment_methods/fiat requisites
blockchain/registry and chain interfaces
clients/ton/TON RPC and indexer
clients/evm/Ethereum and BNB adapters
clients/tron/TRX and TRC20 adapter prototype
modules/notification/templates and delivery
infra/docker/four independent workers
frontend/Next.js Telegram Mini App prototype
Prototype boundary

The core domain and ledger were developed further than the presentation layer. The frontend still contains mock-oriented screens, and deposit sweeping, withdrawal processing and ledger validation were not completed as a verified end-to-end release.