glm_crypto_trading_platform

Modular research-to-production stack for running grid-based trading on Binance, enriched with sentiment and strategy microservices.

Comment

GLM Crypto Trading Platform - Kiro Hack Pine Project Submission

Project information

Project Story | Project Story

About the Project | About the Project

GLM Crypto Trading Platform is a professional cryptocurrency quantitative trading system that combines the best practices of modern software engineering, machine learning and financial engineering.

Source of Inspiration (Inspiration)

This project stems from a deep understanding of the special nature of the encryption market:

  1. Unique challenges in the Web3 market

  • 7x24 all-you-crest market, need automation strategy

  • Extreme fluctuations and the risk of "killing pigs" occur frequently

  • Emotional drive is obvious, and social media has a huge impact.

  1. The limitations of traditional quantitative systems

  • The monomer architecture cannot support multi-policy parallel

  • Lack of defense mechanism against Web3's unique risks

  • Policy behavior is inexplicable and difficult to debug and optimize

  1. Personal experience

  • Witnessing the burst of positions caused by excessive leverage in the bear market

  • Chasing high quilt covers in the FOMO market

  • Realize the need for a "self-disciplined" intelligent trading system

What I Learned (What I Learned)

This project is a journey of deep integration of full-stack technology and financial engineering:

Technical level:

  • Event-driven architecture: Use Redis Streams to realize asynchronous communication between microservices and understand the power of CQRS mode

  • Strategy plug-in: Designed BaseStrategy abstraction and StrategyEngine engines, and experience the elegance of interface-oriented programming

  • State Management: Realize centralized state storage and solve the problem of state consistency in distributed systems.

  • Front-end Engineering: Use React + TypeScript + Zustand To Build A Professional Financial Visualization Interface

Financial engineering level:

  • P vs Q Framework: Understand the essential difference between the implicit volatility (P) of the market and the model predicted volatility (Q)

  • Gamma Scalping: Master the strategy of capturing volatility value through Delta neutral hedging

  • Intention-oriented architecture: Innovatively introduce the three-layer decision-making structure of "state → intention → signal"

  • Combined risk control: Multi-dimensional risk control mechanisms such as leverage limitation, FOMO defense, and macro cycle adaptation have been realized.

Software engineering level:

  • Domain Driven Design (DDD): Divide trading, strategy, risk control and market into clear domain boundaries

  • Dependence Injection: Loose coupling is realized through the dependency injection system of FastAPI

  • Test Pyramid: Design a layered strategy for unit testing, integrated testing and end-to-end testing

  • Document-driven development: Design the architectural document first, and then code the implementation to ensure that the design intention is clearly conveyed.

Building Process (How I Built It)

The project has gone through three main iterative stages:

Phase 1: Monomer Verification (2023 Q4)

  • Quickly build GridTrader monomer prototypes

  • Verify the feasibility of the grid trading strategy in Binance

  • Accumulate an understanding of CCXT library and exchange API

Phase 2: Architecture Decoupling (2024 Q2)

  • Realize the limitations of monomer architecture

  • Introduce the Redis Streams message bus

  • Design plug-in strategy layer and centralized state storage

  • Split into three major microservices: trading / sentiment / strategy

Phase 3: Intention Architecture Upgrade (2025 Q1)

  • In the face of complex decision-making scenarios (macro, emotional, risk), the original "conditional judgment" model is stretched to the limit.

  • Innovative introduction of MarketState aggregate state container

  • Design _decide_intent() intention decision-maker to realize the explanability of strategic behavior

  • Complete the combined risk control and FOMO defense mechanism

Reasons for choosing the technology stack:

  • Python: Factual standards of financial quantification, rich data science library

  • FastAPI: High-performance asynchronous framework, native support for OpenAPI documents

  • Redis Streams: Lightweight message bus, more suitable for small and medium-sized scenarios than Kafka

  • React + TypeScript: Type-safe front-end development, Ant Design provides professional UI components

  • Docker Compose: Simplify the local development and deployment process

Challenges I Faced (Challenges I Faced)

  1. The complexity of asynchronous programming

  • Problem: The mental model of Python asyncio is very different from the synchronization code, and it is easy to be deadlocked.

  • Solve: Formulate strict asynchronous specifications and use asyncio.create_task() to manage background tasks

  1. Event Sequential Guarantee

  • Problem: The consumer group of Redis Streams may lead to event disorder

  • Solution: Design power equality processing and state machine for key paths (such as order life cycle)

  1. Front-end and back-end field mapping

  • Problem: Front-end and back-end fields are easy to be inconsistent in fast iteration

  • Solve: Write the frontend_backend_api_mapping.md verification document and use the TypeScript type definition as a contract

  1. Difference between strategy backtest and actual market

  • Question: Excellent performance in the backtest, but the actual market is a loss

  • Solve: Slippage simulation, handling fee calculation, and market shock modeling are introduced

  1. Web3 unique risk

  • Problem: Traditional risk control cannot cope with extreme scenarios such as "killing pigs"

  • Solve: Innovatively introduce FOMO defense at the strategy layer, cooperate with the leverage limit of the risk control layer, and form double insurance

Built With | Technology Stack

Backend Technologies

  • Python 3.11 - Core Development Language

  • FastAPI - Asynchronous Web framework, providing REST API

  • Redis - Message Bus (Redis Streams) + Status Storage

  • CCXT - Unified Exchange API Interface

  • asyncio - Asynchronous I/O framework

  • Pydantic - Data Verification and Setting Management

Machine Learning

  • StatsModels - GLM (Generalized Linear Model) Volatility Prediction

  • scikit-learn - Feature Engineering and Model Evaluation

  • HuggingFace Transformers - FinBERT Financial Sentiment Analysis

  • Tweepy - Twitter Data Capture

Frontend Technologies

  • React 18 - User Interface Library

  • TypeScript - Type-safe JavaScript hyperset

  • Ant Design - Enterprise UI Component Library

  • Zustand - Lightweight status management

  • TanStack Query - Server-side Status Management and Caching

  • Recharts - Data Visualization Chart

  • Vite - Quick Building Tool

DevOps & Infrastructure

  • Docker - Containerized Deployment

  • Docker Compose - Multi-container arrangement

  • GitHub Actions - CI/CD Automation (Planning)

  • Redis - Persistent Storage + Message Queue

Data & Storage Data & Storage

  • Redis Streams - Event bus and message queue

  • Redis Hash/Set - Status Storage and Cache

  • PostgreSQL - Persistent storage (under planning)

Financial Engineering Financial Engineering

  • Black-Scholes Model - Option Pricing

  • Greeks Calculation - Delta / Gamma / Vega / Theta Calculation

  • P vs Q Framework - Volatility Trading Framework

  • GLM Volatility Model - Volatility Prediction Model

Try It Out | Online Experience

Local deployment (recommended)


#1. Clone warehouse

Git clone https://github.com/RichedYu/glm_crypto_trading_platform.git

Cd glm_crypto_trading_platform

#2. Configure environment variables

Cp services/trading_service/.env.example services/trading_service/.env

Cp services/sentiment_service/.env.example services/sentiment_service/.env

Cp services/strategy_service/.env.example services/strategy_service/.env

# Edit the .env file and fill in your Binance API Key (optional, for real disk)

# If you only test the architecture, you can use the default configuration.

#3. Start all services

Docker compose up --build

#Four. Access the front-end (development mode)

CD frontend

Npm install

Npm run dev

# Visit http://localhost:5173

API document

Code warehouse

  • GitHub: https://github.com/RichedYu/glm_crypto_trading_platform

  • Documents: Check the docs/ directory to understand the architecture design

  • architecture_decoupling.md - Architecture decoupling scheme

  • strategy_intent_architecture_upgrade.md - Strategy Intention Upgrade Report

  • system_architecture_diagram.md - System architecture diagram

  • frontend_backend_api_mapping.md - Front-end and back-end API mapping verification

Key Features | Core Features

one. Event-Driven Architecture (Event-Driven Architecture)

  • ✅ Message bus based on Redis Streams

  • ✅ Support market.tick, strategy.signal, order.fill, risk.alert and other event types

  • ✅ Asynchronous decoupling, support multi-policy parallel operation

2. Intent-Oriented Strategy (Intent-Oriented Strategy)

  • ✅ Innovative "state → intention → signal" three-layer decision-making structure

  • ✅ MarketState aggregate state container, unified decision-making dimension

  • ✅ Strategic behavior can be explained, and the front-end can directly display the semantics of intention.

3. Multi-strategy support

  • ✅ Grid Strategy - Grid trading, suitable for shock market

  • ✅ PQ Vol Trader - P vs Q Volatility arbitrage

  • ✅ Delta Hedger - Gamma Scalping Delta Hedging

  • ✅ Plug-in architecture, easily expand new strategies

four. Portfolio Risk Management (Portfolio Risk Management)

  • ✅ Real-time Greeks monitoring (Delta / Gamma / Vega / Theta)

  • ✅ Portfolio leverage limit (gross_notional / equity)

  • ✅ FOMO defense mechanism, automatic downshift under extreme emotions

  • ✅ Macro cycle adaptation, different risk control strategies in the bull and bear market

five. Sentiment Analysis (Sentiment Analysis)

  • ✅ Twitter data capture and FinBERT emotional scoring

  • ✅ FOMO index calculation, identify the risk of "killing pig plate"

  • ✅ Real-time emotional signal injection strategy decision-making

6. Professional front-end visualization

  • ✅ Trading Dashboard - Real-time transaction monitoring

  • ✅ Options Panel - Gamma Console and P-Q Display

  • ✅ Risk Panel - Combine risk radar and alarm flow

  • ✅ Strategy Center - Strategy Configuration and Backtest Analysis

  • ✅ Sentiment Panel - Visualization of Emotional Indicators

Innovation Highlights | Innovation Highlights

one. Intention-Oriented Architecture (Intent-Oriented Architecture)

The traditional quantitative system jumps directly from "conditional judgment" to "order signal", which makes strategic behavior difficult to understand. We innovatively introduce the "intent layer":


Market Data → MarketState (State Aggregation)

→ Intent Decision (Intent Decision)

→ Strategy Signal (signal)

→ Risk Veto (risk control)

→ Execution (Execution)

Advantages:

  • Strategic behavior can be explained: the front-end directly displays semantic intentions such as "increase_long_gamma"

  • Easy to debug: the intention decision-making logic can be tested separately without running the complete strategy.

  • Risk control friendly: The risk control layer can impose different constraints on the type of intention.

2. Web3 Risk Defense System

For the unique risks of "killing pigs" and FOMO in the crypto market, a double-layer defense is designed:

Strategic-side active defense:


If fomo_score > threshold:

Return {"intent_type": "hold", "reason": "high_fomo_risk"}

Passive constraints on the risk control side:


If new_leverage > max_leverage:

Return veto("combination leverage exceeds the limit")

3. P vs Q Volatility Trading Framework

The P vs Q theoretical framework of the academic community has been realized:

  • P (Physical Measure): The implicit volatility of the market is pushed back from the option price

  • Q (Risk-Neutral Measure): GLM model predicts volatility

  • Trading signal: Short volatility when Q > P, short volatility when Q < P

four. Microservice + plug-in hybrid architecture

Cleverly combine the advantages of microservices and plug-ins:

  • Service-level decoupling: trading / sentiment / strategy independent deployment

  • Strategy-level plug-in: Support multi-policy hot plugging within the same service

  • Optimal balance: It has the independence of microservices and avoids the complexity of excessive splitting.

Roadmap | Future Planning

Phase 4: Intent Eventization (Q2 2025)

  • [ ] Abstract Intent into a formal event type StrategyIntentEvent

  • [ ] Realize the independent service of Intent Executor

  • [ ] Support one intention mapping to multiple orders (combination strategy)

Phase 5: Macro/Emotional Deep Integration (Q3 2025)

  • [ ] Improve the macro cycle identification model

  • [ ] Introduce on-chain indicators (fund rate, position holding, capital flow)

  • [ ] Multi-factor FOMO model (price momentum + social mood + turnover)

Phase 6: Production-level Deployment (Q4 2025)

  • [ ] Kubernetes deployment scheme

  • [ ] PostgreSQL persistence and audit log

  • [ ] Prometheus + Grafana Monitoring System

  • [ ] API Gateway + Flow Limiting + Melting

Team | Team

license

MIT License - Open Source Protocol, welcome to learn and contribute

Acknowledgements | Thank you

  • Binance API - Provide a stable trading interface

  • HuggingFace - Open source FinBERT model

  • FastAPI Community - Excellent asynchronous framework

  • React Ecology - Powerful front-end tool chain

Built with ❤️ for the Kiro Hackathon

Make quantitative trading more intelligent, safer and explainable!

Share this project:

Updates