TRADE

P2P-Marketplace in Telegram

Direkte Trades zwischen Usern ohne Exchange-Mittelsmann

✅ Bereit👤 Solo backend🌍 P2P · Telegram botDemo auf Anfrage

Kontext

Alles begann mit einem Bild. Der Künstler Holovnyi Heroi / Main Character führte eine Spendensammlung durch — jede Zelle auf der Leinwand ist ein Mensch, der sein Fragment als Spende kaufte. Mit der Zeit wollte seine Community diese Fragmente untereinander tauschen. Ich habe ein System gebaut, das das bequem und transparent macht — ein P2P-Marketplace mit öffentlichem Deal-Register. Die Aufgabe war, das günstig, einfach und effektiv zu machen.

Bild — jede Zelle ist ein Spender — Bild · Fragment-Zellen

zum Profil

Meine Rolle: solo backend — von der Architektur bis in die Produktion. Telegram-Bot, Background-Processor, Integrationen mit Notion und Telegram User API, Docker-Deploy. Kein Frontend — das Interface ist Telegram selbst, und die öffentliche Deal-Auslage ist eine Notion-Seite.

Vielleicht kennst du ihn aus diesen Videos

@main_main_character

Problem

Der Projekt-Owner wollte der Community die Möglichkeit geben, Assets untereinander zu tauschen, ohne selbst Mittelsmann bei jedem Trade zu sein. Fertige P2P-Exchanges passten nicht — eine custom Logik für die Community wurde gebraucht.

→Trade-Sicherheit ohne Escrow — wie sicherstellen, dass weder Käufer noch Verkäufer mit dem Geld verschwindet
→Anonymität der Teilnehmer — echte Telegram-IDs dürfen nicht öffentlich sein
→Volumen-Integrität — jeder User tradet nur innerhalb seiner Quota
→Öffentliche Transparenz — jeder Trade bleibt als öffentlicher Eintrag
→Live-Konversations-Archiv — für die Klärung strittiger Trades

Fähigkeiten

Telegram-Bot mit dreischichtiger Persistenz und einem Background-Worker, der garantiert, dass kein Trade auch bei einem Service-Crash verloren geht.

Whitelist-Zugang — nur Teilnehmer von der Liste werden zugelassen, mit Volumen-Quoten
Anonymität der Teilnehmer — im öffentlichen Register erscheinen Fake-IDs statt echter Telegram-IDs
SELL-Flow — Lot (Menge + Preis) → Quota-Validierung → öffentlicher Eintrag im Register
BUY-Flow — Deep-Links führen zu einem Multi-Step-Wizard: Käufer-Bestätigung → Zahlungsdaten → Zahlungs-Screenshot → Verkäufer-Bestätigung
Öffentliches Deal-Register in Notion — jeder Deal ohne Login zugänglich, wie eine CMS-Auslage
Konversations-Archiv — ein separater Prozess schreibt die Historie jedes Dialogs für die Klärung strittiger Deals

// system

Architektur

3 Prozesse · 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

Harte Probleme

Atomizität eines dreischichtigen Trades

Jeder Trade muss in drei Systemen gleichzeitig gespeichert werden (Queue → transaktionale DB → öffentliches Register). Jedes davon kann ausfallen. Bei falscher Reihenfolge — entweder ein Phantom-Trade ohne öffentlichen Eintrag, oder eine verlorene Transaktion.

Lösung → Ein Background-Processor bestätigt die Queue-Anfrage erst nach erfolgreichem INSERT und Append in beide Stores. Wenn die öffentliche Publikation fehlschlug — erneute Prüfung, ob der Eintrag bereits existiert (race-safe), dann erst Retry. Garantiert „at-least-once delivery" ohne Duplikate.

Anonymität + Audit gleichzeitig

Das öffentliche Register darf keine echten Telegram-IDs der Teilnehmer zeigen. Aber zur Streit-Klärung wird ein vollständiges Archiv der Konversationen mit Bezug zur echten ID gebraucht.

Lösung → Zweischichtiges Identitätssystem: Fake-ID für öffentliche Einträge, Real-ID nur privat in der transaktionalen DB. Das Konversations-Archiv wird unter der echten ID in einem Datei-Store geführt, der nur dem Admin zugänglich ist.

Konkurrenz ohne Race Conditions

Ein klassischer Thread-basierter Bot leidet unter FSM-Race-Conditions — der User-State kann von zwei Callbacks gleichzeitig überschrieben werden.

Lösung → Vollständig asynchrone Architektur, FSM-State im geteilten Store (nicht im Prozess-Speicher), Background-Processor verarbeitet die Queue sequenziell. Mehrere Bot-Instanzen möglich — der State ist geteilt.

Zwei Telegram-Clients in einem Projekt

Bot API gibt keinen Zugriff auf die volle Nachrichtenhistorie (nur neue Nachrichten). Für ein vollständiges Archiv wird die User-Account-API mit separater Auth gebraucht.

Lösung → Ein separater Side-Car-Prozess auf der User-Account-API läuft im Hintergrund und schreibt die Historie in ein Datei-Archiv. Blockiert nicht den Haupt-Bot, läuft unabhängig. Ein dritter Prozess (Monitoring) unter tmux mit separaten Logs.

Tech Stack

Backend / runtime

Python 3.13aiogram 3asyncioaiohttphttpx

Persistence

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

Integrationen

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

Infrastruktur

Docker (linux/amd64)tmuxbash orchestration

Was es vs. einer zentralisierten Exchange gibt

Custom P2P-Bot für eine Community — dort, wo fertige Exchanges keine eigenen Regeln zulassen.

Parameter	Zentralisierte Exchange	Trade-Bot
Eigene Regeln	unmöglich	volle Kontrolle (Whitelist, Quoten, Skripte)
Gebühr pro Trade	0.1–1%	0
Trade-Transparenz	private Exchange-Logs	öffentliches Notion-Register
Plattform-Abhängigkeit	volle (kann geschlossen, gebannt werden)	keine — eigener Code, eigener Server
Anonymität der Teilnehmer	KYC verpflichtend	Fake-ID, kein KYC
Streit-Archiv	für User unzugänglich	volles JSON-Archiv der Konversationen

Eigene Regeln

Exchange

unmöglich

Trade

volle Kontrolle (Whitelist, Quoten, Skripte)

Gebühr pro Trade

Exchange

0.1–1%

Trade

Trade-Transparenz

Exchange

private Exchange-Logs

Trade

öffentliches Notion-Register

Plattform-Abhängigkeit

Exchange

volle (kann geschlossen, gebannt werden)

Trade

keine — eigener Code, eigener Server

Anonymität der Teilnehmer

Exchange

KYC verpflichtend

Trade

Fake-ID, kein KYC

Streit-Archiv

Exchange

für User unzugänglich

Trade

volles JSON-Archiv der Konversationen

Was kommt als Nächstes?

Das ist einer meiner Cases. Der Rest ist auf der Hauptseite.

Zur Hauptseite Andere Arbeiten anschauen