Require confirmation before execution
The system creates an inspectable order preview and requires explicit user approval. This gives up some speed, but keeps an irreversible financial action behind a human decision point.
Trading Infrastructure·2026
Kaiyn Trading Bot
Structured trading workflow system for community-based market operations.
Signal Ingress
Telegram Auth
Confirm Execute
YES
NO
Audit State
StatusFilled
Latency42ms
1R Risk CheckEncrypted APIPostgreSQLDockerCI/CD
At a Glance
- Type
- Trading Infrastructure
- Public artifact
- Deployed in Kaiyn Capital operations
- My role
- Founder of Kaiyn Capital, product owner, and sole developer responsible for product requirements, the Telegram user flow, backend engineering, deployment, and ongoing operations.
- Focus
- Signal-to-execution workflow / Risk-aware order validation / Audit-ready backend infrastructure
Context and Operating Problem
Kaiyn Capital distributes market commentary and trading signals through Telegram. The operating problem was not simply parsing a message: users still had to verify the instrument, size the position, check exchange rules, and avoid repeated actions under time pressure.
The system was built to close that gap between signal publication and order submission with an explicit confirmation point, consistent risk calculations, persisted state, and an auditable execution path.
Live Demo
Key Decisions and Trade-offs
Persist workflow state in PostgreSQL
Pending orders, signals, and preview sessions resolve from short Telegram tokens to database-backed state. The added schema and migration work provides restart-safe workflows, audit records, and row-level locking against repeated confirmation.
Escalate ambiguous exchange results
Network timeouts and uncertain responses are not treated as failed orders or retried automatically. Deterministic client order IDs, a manual-review state, and later reconciliation reduce duplicate-order risk at the cost of administrative review.
Outcome and Evidence
The system is deployed and used in Kaiyn Capital operations. It implements the path from Telegram signals and order previews through fixed-risk sizing, exchange-rule validation, Bitget submission, persisted state, and audit records.
Docker-first CI checks migrations, typing, order-safety rules, and PostgreSQL integration. Deployment, health checks, encrypted offsite backups, and restore procedures are documented as part of the operating system rather than treated as afterthoughts.
Current Limitations
- The full post-submission lifecycle of limit orders is not tracked.
- Cancellation, expiry synchronization, and automatic take-profit orders remain outside the system boundary.
- The project has not undergone large-scale load or trading-volume simulation and does not claim that duplicate orders are impossible or that trading is profitable.
Representative Artifacts
Signal Workflow
Parsing unstructured Telegram messages into strict, validated JSON payloads.
Signal Webhook Payload
{
"asset": "BTC-USDT",
"action": "LONG",
"risk_level": "1R",
"timestamp": 1709283741
"action": "LONG",
"risk_level": "1R",
"timestamp": 1709283741
}
Strict JSON validation enforced
Confirmation-First Flow
Interactive Telegram UI requiring explicit user approval before execution.
Interactive Auth
Execute Trade?
BTC-USDT LONG @ 1R
Backend Audit Pipeline
PostgreSQL-backed state tracking designed to reduce duplicate submissions through idempotency controls and explicit execution states.
Immutable Audit Trail
14:02:01Signal received[ok]
14:02:02Risk validated (1R)[ok]
14:02:05User confirmed[ok]
14:02:06Order executed[ok]
14:02:06State committed to DB[ok]
Tech Stack
PythonTelegramPostgreSQLSQLAlchemyDockerGitHub Actions
Related writing
Read the confirmation-first workflow case studyThis project is presented as an engineering and workflow-design portfolio project. It does not represent financial advice or a claim of trading profitability.