TRADE

P2P-маркетплейс у Telegram

Прямі угоди між користувачами без посередника-біржі

✅ Готовий👤 Solo backend🌍 P2P · Telegram botDemo on request

Контекст

Усе почалось з картини. Художник Головний Герой / Main Character провів благодійний збір — кожна клітинка на полотні це людина, яка купила свій фрагмент за донат. Згодом його спільнота захотіла обмінюватися цими фрагментами між собою. Я збудував систему, яка це робить зручно і прозоро — P2P-маркетплейс із публічним реєстром угод. Задача була зробити це дешево, просто і ефективно.

Картина — кожна клітинка це донор — картина · фрагменти-клітинки

перейти в профіль

Моя роль: solo backend — від архітектури до прода. Telegram-бот, фоновий процесор, інтеграції з Notion і Telegram User API, Docker-деплой. Фронтенду нема — інтерфейс це сам Telegram, а публічна вітрина угод — Notion-сторінка.

Можете знати його по таким відео

@main_main_character

Проблема

Власник проєкту хотів дати спільноті можливість обмінюватися активами між собою, без того щоб самому бути посередником у кожній угоді. Готові P2P-біржі не підходили — потрібна була кастомна логіка під спільноту.

→Безпека угоди без escrow — як зробити так, щоб ні покупець, ні продавець не зник із грошима
→Анонімність учасників — реальні Telegram-ID не мають світитися публічно
→Чесність обсягу — кожен користувач торгує тільки в межах своєї квоти
→Публічна прозорість — кожна угода має лишатися як публічний запис
→Live-архів спілкування — для розборів спірних угод

Можливості

Telegram-бот з трьохшаровою персистенцією і фоновим воркером, який гарантує що жодна угода не загубиться навіть при падінні сервісу.

Whitelist-вхід — допускаються тільки учасники зі списку, з квотами на обсяг
Анонімність учасників — у публічному реєстрі світяться fake-ID замість реальних Telegram-ID
SELL flow — лот (кількість + ціна) → валідація квоти → публічний запис у реєстрі
BUY flow — глибокі deep-links ведуть на multi-step майстер: підтвердження покупця → реквізити оплати → скрін платежу → підтвердження продавця
Публічний реєстр угод у Notion — кожна угода доступна без логіну, як CMS-вітрина
Архів переписок — окремий процес пише історію кожного діалогу для розборів спірних угод

// system

Архітектура

3 процеси · async

queue → ledger → registry

testing

Telegram users

SELL · BUY flows

command

Telegram Bot API

Bot Server

aiogram · async · FSM

Queue

Redis + FSM state

Background Processor

atomic 3-step commit

Archive Monitor

user API · side-car

SQL Ledger

private, transactional

Public Registry

Notion · CMS view

Whitelist

Excel + quotas

closed testing

Складні рішення

Атомарність трьохшарової угоди

Кожну угоду треба зберегти у трьох системах одночасно (черга → транзакційна БД → публічний реєстр). Будь-яка з них може впасти. Якщо порядок неправильний — буде або фантомна угода без публічного запису, або втрачена транзакція.

Розв'язання → Фоновий процесор підтверджує запит з черги тільки після успішних INSERT і append у обидва сховища. Якщо публічна публікація відмовила — повторна перевірка чи запис вже існує (race-safe), і тільки потім ретрай. Гарантує "at-least-once delivery" без дублів.

Анонімність + аудит одночасно

Публічний реєстр не повинен світити реальні Telegram-ID учасників. Але для розбору спорів потрібен повний archive переписок із прив'язкою до реального ID.

Розв'язання → Двошарова система ідентифікації: fake-ID для публічних записів, real-ID — тільки приватно у транзакційній БД. Архів переписок ведеться за реальним ID у файловому сховищі, доступному тільки адміну.

Конкурентність без race conditions

Класичний бот на потоках страждає від race conditions у FSM — стан користувача може перезаписатися двома callback'ами одночасно.

Розв'язання → Повністю асинхронна архітектура, FSM-стан зберігається у спільному сховищі (а не в пам'яті процесу), фоновий процесор обробляє чергу послідовно. Можна підняти кілька інстансів бота — стан спільний.

Два Telegram-клієнти в одному проєкті

Bot API не дає доступу до повної історії переписок (тільки нові повідомлення). Для повного архіву потрібен user-account API з окремою авторизацією.

Розв'язання → Окремий side-car процес на user-account API сидить у фоні і пише історію в файловий архів. Не блокує основний бот, працює незалежно. Третій процес (моніторинг) під tmux із окремими логами.

Технології

Backend / runtime

Python 3.13aiogram 3asyncioaiohttphttpx

Persistence

Redis (queue + FSM)SQLite (transactional ledger)Notion API (public ledger)JSON archive

Інтеграції

Telegram Bot APITelegram User API (Telethon)Excel / openpyxl (whitelist)

Інфраструктура

Docker (linux/amd64)tmuxbash orchestration

Що це дає проти централізованої біржі

Кастомний P2P-бот для спільноти — там, де готові біржі не дозволяють встановити свої правила.

Параметр	Централізована біржа	Trade-бот
Кастомні правила	неможливо	повний контроль (whitelist, квоти, скрипти)
Комісія за угоду	0.1–1%	0
Прозорість угод	приватні логи біржі	публічний реєстр у Notion
Залежність від платформи	повна (можуть закрити, забанити)	нема — свій код, свій сервер
Анонімність учасників	KYC обов'язково	fake-ID, без KYC
Архів спорів	недоступний користувачу	повний JSON-архів переписок

Кастомні правила

Біржа

неможливо

Trade

повний контроль (whitelist, квоти, скрипти)

Комісія за угоду

Біржа

0.1–1%

Trade

Прозорість угод

Біржа

приватні логи біржі

Trade

публічний реєстр у Notion

Залежність від платформи

Біржа

повна (можуть закрити, забанити)

Trade

нема — свій код, свій сервер

Анонімність учасників

Біржа

KYC обов'язково

Trade

fake-ID, без KYC

Архів спорів

Біржа

недоступний користувачу

Trade

повний JSON-архів переписок

Що далі?

Це один з моїх кейсів. Решта зібрана на головній.

Перейти на головний екран Подивитись інші роботи