================================================================================
GITIBOT NODE.JS → GOLANG MIGRATION - COMPLETE TRACKING PLAN
Project: GitiNext Wallet Backend Migration Date Started: October 6, 2025 Goal: Migrate complete Node.js backend (gitibot-back-main/) to Go microservices with containerization and independent testing capability
================================================================================
📊 CURRENT STATE ANALYSIS
┌─────────────────────────────────────────────────────────────────────────────┐ │ 1. FRONTEND (TMA - gitinext-telegram/) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ Status: ✅ COMPLETE UI - WAITING FOR BACKEND │ │ - Next.js 14 Telegram Mini App │ │ - 40+ API endpoints required (documented in APIINTEGRATION*.md) │ │ - All components using mock data from /public/fakeddata.json │ │ - Zustand stores ready for API integration │ └─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐ │ 2. LEGACY BACKEND (Node.js - gitibot-back-main/) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ Status: ✅ FULLY FUNCTIONAL - PRODUCTION RUNNING │ │ │ │ API Controllers (20+): │ │ ├─ accountingController.js - Financial accounting operations │ │ ├─ Admins_Controller.js - Admin user management │ │ ├─ Broadcast_Controller.js - Message broadcasting │ │ ├─ Config_Controller.js - System configuration │ │ ├─ Identity_Controller.js - User identity/KYC │ │ ├─ Monitoring_Controller.js - System monitoring │ │ ├─ Network_Controller.js - Network management │ │ ├─ Payments_Controller.js - Payment processing │ │ ├─ Statistics_Controller.js - System statistics │ │ ├─ Support_Controller.js - Support tickets │ │ ├─ Transaction_Controller.js - Transaction management │ │ ├─ Uid_Controller.js - UID operations │ │ ├─ Users_Controller.js - User management │ │ ├─ VoucherRate_Controller.js - Voucher rate management │ │ ├─ Vouchers_Controller.js - Voucher operations │ │ └─ Withdrawal_Controller.js - Withdrawal processing │ │ │ │ Database Models (25+): │ │ ├─ Users.js - User accounts │ │ ├─ UserCards.js - Bank card information │ │ ├─ UserWallets.js - Crypto wallets │ │ ├─ UserTransactionHistory.js - Transaction records │ │ ├─ TransactionLogs.js - System transaction logs │ │ ├─ TransactionHistory.js - User transaction history │ │ ├─ CardTransactions.js - Card-to-card transactions │ │ ├─ Withdrawals.js - Withdrawal requests │ │ ├─ Vouchers.js - Voucher records │ │ ├─ BlockchainTransactions.js - Blockchain transaction records │ │ ├─ Config.js - System configuration │ │ ├─ Admins.js - Admin users │ │ ├─ VerificationRequests.js - Identity verification requests │ │ ├─ VerifyCodes.js - Verification codes (phone/email) │ │ ├─ LevelUpRequests.js - User level upgrade requests │ │ ├─ AccountRecoveryRequest.js - Account recovery requests │ │ ├─ ManualChanges.js - Manual balance adjustments │ │ ├─ Broadcasts.js - Broadcast messages │ │ ├─ Networks.js - Network configuration │ │ ├─ NetworkTokens.js - Supported tokens per network │ │ ├─ CurrencyRates.js - Exchange rates │ │ └─ FeeConfigurations.js - Fee settings │ │ │ │ Services (25+): │ │ ├─ authService.js - Authentication & authorization │ │ ├─ dbService.js - Database operations wrapper │ │ ├─ blockchainService.js - Blockchain operations (Exonyx) │ │ ├─ blockchainUIService.js - Blockchain UI helpers │ │ ├─ voucherService.js - Voucher operations (PS/HOT/UTOPIA) │ │ ├─ voucherRateService.js - Voucher rate management │ │ ├─ transactionService.js - Transaction processing │ │ ├─ transactionHistoryService.js - Transaction history queries │ │ ├─ walletService.js - Wallet management │ │ ├─ userCardService.js - Card verification & management │ │ ├─ finnotechService.js - FinnoTech banking API │ │ ├─ finnotechClient.js - FinnoTech HTTP client │ │ ├─ finnotechProxyClient.js - FinnoTech proxy client │ │ ├─ finnotechInquiryService.js - FinnoTech inquiry operations │ │ ├─ paymentProvider/paystar.js - Paystar payment gateway │ │ ├─ paymentProvider/uid.js - UID payment provider │ │ ├─ providers/PaystarProvider.js - Paystar provider wrapper │ │ ├─ providers/PaystarDepositProvider.js - Paystar deposit handling │ │ ├─ paystarManagementService.js - Paystar management │ │ ├─ coreService.js - Core service coordinator │ │ ├─ accountingService.js - Accounting operations │ │ ├─ monitoringService.js - System monitoring │ │ ├─ adminMonitoringService.js - Admin monitoring │ │ ├─ levelUpNotificationService.js - Level-up notifications │ │ ├─ networkConfigService.js - Network configuration │ │ ├─ networkFeeUpdater.js - Network fee updates │ │ ├─ simpleNetworkFeeService.js - Network fee calculations │ │ └─ withdrawalLimitService.js - Withdrawal limit enforcement │ │ │ │ External API Integrations (7): │ │ ├─ Exonyx Blockchain API - TRX/USDT/BNB wallet operations │ │ │ ├─ Base URL: api.exonyxco.com/api/v1/reseller │ │ │ ├─ Auth: API Key in header │ │ │ └─ Features: wallet creation, balance, transactions, webhooks │ │ ├─ Paystar Payment Gateway - payment processing │ │ │ ├─ Auth: API Key + Secret │ │ │ └─ Features: deposits, withdrawals, IBAN, POL transactions │ │ ├─ FinnoTech Banking API - banking integration │ │ │ ├─ Auth: OAuth + Proxy support │ │ │ └─ Features: deposits, withdrawals, card verification │ │ ├─ PS Voucher API - Gaming platform vouchers │ │ │ ├─ Auth: API Key + Secret │ │ │ └─ Features: buy, sell, redeem, check status │ │ ├─ HOT Voucher API - Hot wallet vouchers │ │ │ ├─ Auth: Security key │ │ │ └─ Features: voucher management, tracking │ │ ├─ UTOPIA Voucher API - UUSD cryptocurrency vouchers │ │ │ ├─ Auth: Token + Card ID │ │ │ └─ Features: buy UUSD, sell, human-readable codes (USD-XXXX-XXXX) │ │ └─ Price APIs - Cryptocurrency price data │ │ ├─ CoinGecko API │ │ └─ CoinMarketCap API │ │ │ │ Bot Features: │ │ ├─ Telegraf bot framework with session management │ │ ├─ Persian language UI with custom keyboards │ │ ├─ User authentication & registration │ │ ├─ Wallet management (TRX, USDT, BNB, Toman) │ │ ├─ Buy/Sell/Swap operations │ │ ├─ Deposit/Withdrawal flows │ │ ├─ Voucher purchase/sale/redemption │ │ ├─ Transaction history & receipts │ │ ├─ Card verification & management │ │ ├─ Identity verification (KYC) │ │ ├─ Support ticket system │ │ └─ Admin notifications & broadcasts │ │ │ │ Security Features: │ │ ├─ Atomic database transactions (prevents partial state corruption) │ │ ├─ User lock system (prevents race conditions) │ │ ├─ Transaction verification & validation │ │ ├─ Rate limiting (express-rate-limit) │ │ ├─ JWT authentication for admin panel │ │ ├─ Session management (telegraf-mysql-session) │ │ └─ Comprehensive logging & audit trails (winston) │ └─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐ │ 3. NEW BACKEND (Go - gitinext-golang/services/) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ Status: ⚠️ PARTIALLY IMPLEMENTED - CRITICAL GAPS │ │ │ │ Existing Services: │ │ ├─ ✅ gateway/ - HTTP server (partial routes only) │ │ ├─ ⚠️ wallet/ - Structure exists, SIGNERS BROKEN │ │ │ └─ ❌ ton_tron_placeholders.go returns “not implemented” │ │ ├─ ⚠️ watcher/ - Structure exists, COMPLETELY EMPTY │ │ │ ├─ ❌ ton/watcher.go has only empty stubs │ │ │ └─ ❌ tron/watcher.go has only empty stubs │ │ ├─ ✅ account/ - Basic CRUD, needs KYC/verification extension │ │ ├─ ✅ storage/ - MinIO integration working │ │ ├─ ✅ telegrambot/ - Basic bot structure │ │ └─ ✅ packages/ - Shared utilities (logger, metrics, etc.) │ │ │ │ Missing Services (MUST CREATE): │ │ ├─ ❌ market/ - Market data, prices, charts │ │ ├─ ❌ transaction/ - Transaction history, buy/sell/swap │ │ ├─ ❌ payment/ - Paystar, FinnoTech, card-to-card │ │ ├─ ❌ voucher/ - PS, HOT, UTOPIA voucher operations │ │ ├─ ❌ blockchain/ - Exonyx API integration │ │ ├─ ❌ support/ - Ticket management │ │ └─ ❌ kyc/ - KYC/verification workflows │ └─────────────────────────────────────────────────────────────────────────────┘
================================================================================
🎯 MIGRATION STRATEGY
Approach: BOTTOM-UP (Infrastructure First) Rationale:
- Signers and watchers are foundation for ALL blockchain operations
- Can’t test deposits/withdrawals without working watchers
- Can’t test wallet operations without working signers
- Building on broken foundation leads to massive rework
Timeline: 8 weeks for complete migration
Phase 0: Foundation (Week 1) - Fix critical infrastructure Phase 1: Core Services (Week 2) - Market, Transaction services Phase 2: Financial (Week 3-4) - Payment, Voucher, Blockchain services Phase 3: User Services (Week 5) - Support, KYC, Account extensions Phase 4: Integration (Week 6) - Gateway routes, Admin panel, Frontend Phase 5: Production (Week 7-8) - Containerization, Testing, Monitoring
================================================================================
📋 DETAILED TASK BREAKDOWN
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 0: FOUNDATION - FIX CRITICAL INFRASTRUCTURE (Week 1) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 0.1: FIX TON SIGNER (CRITICAL) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🔴 CRITICAL - BLOCKS: Wallet creation, Deposits, Withdrawals Estimated Time: 4-6 hours Status: [ ] NOT STARTED
Files to Modify: services/wallet/internal/wallet/service/signer/ton_tron_placeholders.go services/wallet/go.mod (add tonutils-go dependency)
Files to Reference: services/wallet/internal/wallet/domain/service/ton_wallet_generator_v4r2.go Node.js: gitibot-back-main/services/blockchainService.js
Dependencies to Add: github.com/xssnick/tonutils-go v1.8.0+
Implementation Steps: [ ] 1.1 Remove placeholder tonSigner struct [ ] 1.2 Import tonutils-go library [ ] 1.3 Implement BIP39 mnemonic generation (24 words) [ ] 1.4 Implement BIP44 derivation path: m/44’/607’/0’/0’/0’ (TON) [ ] 1.5 Implement ed25519 keypair generation [ ] 1.6 Implement v4R2 wallet contract address generation [ ] 1.7 Support bounceable/non-bounceable address forms [ ] 1.8 Support testnet vs mainnet detection (EQ/UQ prefixes) [ ] 1.9 Implement Address() method: - Input: PubKey (ed25519), Chain (TON/TON_TESTNET) - Output: Friendly address (EQ… or UQ…) - Validation: Checksum verification [ ] 1.10 Implement SignTx() method: - Input: Chain, PrivKey, payload (transaction bytes) - Output: Signed transaction bytes - Support: Basic transfers, jetton transfers [ ] 1.11 Integrate existing ton_wallet_generator_v4r2.go code [ ] 1.12 Write unit tests with golden vectors [ ] 1.13 Test against Tonkeeper/Tonhub generated addresses
Testing Checklist: [ ] Generate mnemonic → derive keys → create address [ ] Compare addresses with Tonkeeper for same mnemonic [ ] Verify bounceable ↔ non-bounceable conversion [ ] Test testnet vs mainnet address generation [ ] Sign sample transaction and verify signature [ ] Test with multiple derivation indices
Reference Implementation (Node.js): Location: gitibot-back-main/services/blockchainService.js Look for: Exonyx wallet creation calls (delegates to Exonyx API) Note: Node.js uses Exonyx API, Go will use native tonutils-go
Success Criteria: ✓ tonSigner implements Signer interface completely ✓ Generated addresses match Tonkeeper for same mnemonic ✓ Signatures are valid and verifiable on-chain ✓ All unit tests pass ✓ No “not implemented” errors
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 0.2: FIX TRON SIGNER (CRITICAL) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🔴 CRITICAL - BLOCKS: Wallet creation, Deposits, Withdrawals Estimated Time: 4-6 hours Status: [ ] NOT STARTED
Files to Modify: services/wallet/internal/wallet/service/signer/ton_tron_placeholders.go services/wallet/go.mod (add TRON dependencies)
Dependencies to Add: github.com/fbsobreira/gotron-sdk v0.4.0+ github.com/ethereum/go-ethereum v1.13.0+ (for secp256k1 & keccak256) github.com/tyler-smith/go-bip39 v1.1.0+ github.com/tyler-smith/go-bip32 v1.0.0+
Implementation Steps: [ ] 2.1 Remove placeholder tronSigner struct [ ] 2.2 Import gotron-sdk and go-ethereum [ ] 2.3 Implement BIP39 mnemonic generation [ ] 2.4 Implement BIP44 derivation path: m/44’/195’/0’/0/0 (TRON) [ ] 2.5 Implement secp256k1 keypair generation [ ] 2.6 Implement Address() method: - Input: PubKey (secp256k1 uncompressed), Chain (TRON/TRON_TESTNET) - Process: 1. Strip 0x04 prefix from uncompressed pubkey 2. Keccak256 hash of pubkey bytes 3. Take last 20 bytes 4. Prepend 0x41 (mainnet) or 0xa0 (testnet) 5. Base58Check encode - Output: T… address (mainnet) or appropriate testnet prefix [ ] 2.7 Implement SignTx() method: - Input: Chain, PrivKey, payload (raw transaction) - Output: Signed transaction with signature - Support: TRX transfers, TRC20 token transfers [ ] 2.8 Implement TRC20 contract interaction helpers [ ] 2.9 Write unit tests with golden vectors [ ] 2.10 Test against TronLink generated addresses
Testing Checklist: [ ] Generate mnemonic → derive keys → create address [ ] Compare addresses with TronLink for same mnemonic [ ] Verify T… address format [ ] Test mainnet vs testnet address generation [ ] Sign sample TRX transfer and verify [ ] Sign sample TRC20 transfer and verify [ ] Test with multiple derivation indices
Reference Implementation (Node.js): Location: gitibot-back-main/services/blockchainService.js Look for: Exonyx wallet creation calls (delegates to Exonyx API) Note: Node.js uses Exonyx API, Go will use native gotron-sdk
Success Criteria: ✓ tronSigner implements Signer interface completely ✓ Generated addresses match TronLink for same mnemonic ✓ Addresses start with T… (mainnet) ✓ Signatures are valid and verifiable on-chain ✓ All unit tests pass ✓ No “not implemented” errors
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 0.3: COMPLETE TON WATCHER (CRITICAL) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🔴 CRITICAL - BLOCKS: Deposit detection Estimated Time: 8-10 hours Status: [ ] NOT STARTED
Files to Modify: services/watcher/internal/watcher/chains/ton/watcher.go services/watcher/internal/watcher/chains/ton/client.go services/watcher/go.mod (add dependencies)
Dependencies to Add: github.com/xssnick/tonutils-go v1.8.0+
Implementation Steps: [ ] 3.1 Create TONClient struct in client.go: - RPC endpoint configuration - HTTP client with retry + backoff - Circuit breaker pattern - API rate limiting [ ] 3.2 Implement GetLatestBlock() method: - Connect to TON RPC (ton.org API or own node) - Fetch latest masterchain block - Return block height + hash [ ] 3.3 Implement GetBlock(height) method: - Fetch block by seqno (sequence number) - Parse block header - Extract transactions - Return Block struct [ ] 3.4 Implement GetTransaction(address, lt, hash) method: - Fetch transaction details - Parse message body - Detect transfer amounts - Return Transaction struct [ ] 3.5 Implement ProcessBlock() in watcher.go: - Iterate through all transactions in block - Check if destination address is in monitored list - Parse transfer amount (TON or jetton) - Create deposit record [ ] 3.6 Implement ProcessTransaction(): - Validate transaction structure - Extract sender, receiver, amount - Check against monitored addresses - Handle jetton (USDT-TON) transfers separately [ ] 3.7 Implement IsDepositTransaction(): - Check if receiver is in our address list - Verify transaction is confirmed (20+ blocks) - Filter out internal contract calls - Return true only for valid deposits [ ] 3.8 Implement ProcessDeposit(): - Create deposit record in database - Set idempotency key: (chain, tx_hash, msg_hash) - Write to outbox table for event processing - Emit event via NATS/Redis [ ] 3.9 Implement cursor management: - Load last processed block from chain_cursors table - Update cursor after successful block processing - Handle reorgs (if block hash changed, rewind 10 blocks) [ ] 3.10 Implement confirmation counting: - Don’t credit deposits until 20 confirmations - Update deposit status: pending → confirming → confirmed [ ] 3.11 Add monitoring metrics: - Last processed block height - Blocks per second - Deposits detected counter - Confirmation lag [ ] 3.12 Implement graceful shutdown: - Stop on SIGTERM/SIGINT - Finish processing current block - Update cursor before exit
Testing Checklist: [ ] Connect to TON testnet [ ] Fetch latest block successfully [ ] Parse transactions from block [ ] Detect test deposit to monitored address [ ] Create deposit record in database [ ] Verify idempotency (reprocessing same block doesn’t duplicate) [ ] Test reorg handling [ ] Test graceful shutdown
Reference Implementation (Node.js): Location: gitibot-back-main/services/blockchainService.js Look for: Exonyx webhook handling (webhooks/blockchain) Note: Node.js uses Exonyx webhooks, Go will poll directly
Success Criteria: ✓ Watcher connects to TON RPC successfully ✓ Processes blocks continuously without errors ✓ Detects deposits to monitored addresses ✓ Creates deposit records with idempotency ✓ Handles reorgs correctly ✓ Metrics are exposed and accurate ✓ Graceful shutdown works
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 0.4: COMPLETE TRON WATCHER (CRITICAL) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🔴 CRITICAL - BLOCKS: Deposit detection Estimated Time: 8-10 hours Status: [ ] NOT STARTED
Files to Modify: services/watcher/internal/watcher/chains/tron/watcher.go services/watcher/internal/watcher/chains/tron/client.go (create) services/watcher/go.mod
Dependencies to Add: github.com/fbsobreira/gotron-sdk v0.4.0+
Implementation Steps: [ ] 4.1 Create TronClient struct in client.go: - TronGrid API endpoint (api.trongrid.io) - HTTP client with retry + backoff - Circuit breaker pattern - API key management - Rate limiting (5 req/sec) [ ] 4.2 Implement GetLatestBlock() method: - Call: GET /wallet/getnowblock - Parse block number - Return block height + hash [ ] 4.3 Implement GetBlock(height) method: - Call: POST /wallet/getblockbynum {“num”: height} - Parse block data - Extract transactions - Return Block struct [ ] 4.4 Implement GetTransaction(txid) method: - Call: POST /wallet/gettransactionbyid - Parse transaction data - Extract TRC20 events from logs - Return Transaction struct [ ] 4.5 Implement GetTRC20Transfer(txid) method: - Parse transaction logs for Transfer event - Event signature: Transfer(address,address,uint256) - Decode: from, to, amount - Verify contract address is USDT (TR7…) [ ] 4.6 Implement ProcessBlock() in watcher.go: - Iterate through all transactions - Filter TRC20 contract calls - Check if receiver is in monitored list - Parse transfer amount (handle 6 decimals for USDT) [ ] 4.7 Implement ProcessTransaction(): - Detect TRC20 Transfer events - Extract from/to addresses - Convert amount to decimal (USDT has 6 decimals) - Verify contract is whitelisted (USDT, USDC, etc.) [ ] 4.8 Implement IsDepositTransaction(): - Check if receiver matches monitored addresses - Verify transaction is confirmed (19+ blocks) - Verify contract is whitelisted token - Filter out failed transactions [ ] 4.9 Implement ProcessDeposit(): - Create deposit record in database - Set idempotency key: (chain, tx_hash) - Store: token_contract, from_address, to_address, amount, decimals - Write to outbox table - Emit event [ ] 4.10 Implement cursor management: - Load last processed block from chain_cursors table - Update cursor after successful block processing - Handle TronGrid API pagination [ ] 4.11 Implement confirmation counting: - Don’t credit deposits until 19 confirmations - Update deposit status: pending → confirming → confirmed [ ] 4.12 Add monitoring metrics: - Last processed block height - TRC20 transfers detected - Deposits created - API error rate [ ] 4.13 Implement graceful shutdown
Testing Checklist: [ ] Connect to TronGrid testnet (Shasta) [ ] Fetch latest block successfully [ ] Parse TRC20 Transfer events [ ] Detect test USDT deposit to monitored address [ ] Handle USDT decimals correctly (6 decimals) [ ] Create deposit record in database [ ] Verify idempotency [ ] Test with failed transactions (don’t credit) [ ] Test graceful shutdown
Reference Implementation (Node.js): Location: gitibot-back-main/services/blockchainService.js Look for: Exonyx webhook handling Note: Node.js uses Exonyx webhooks, Go will poll TronGrid
TRC20 USDT Contract Addresses: Mainnet: TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t Testnet: TG3XXyExBkPp9nzdajDZsozEu4BkaSJozs (Shasta)
Success Criteria: ✓ Watcher connects to TronGrid successfully ✓ Processes blocks continuously ✓ Detects TRC20 USDT deposits to monitored addresses ✓ Correctly handles USDT 6-decimal format ✓ Creates deposit records with idempotency ✓ Metrics are exposed ✓ Graceful shutdown works
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 0.5: CREATE BALANCE CHECKING SERVICE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🔴 HIGH - BLOCKS: TMA balance display Estimated Time: 4-6 hours Status: [ ] NOT STARTED
Files to Create: services/wallet/internal/balance/service.go services/wallet/internal/balance/rpc_clients.go services/wallet/internal/balance/cache.go
Implementation Steps: [ ] 5.1 Create BalanceService struct: - Redis client for caching - TON RPC client - TRON RPC client - Configuration (RPC URLs, API keys) [ ] 5.2 Implement GetBalance(address, network, token): - Check Redis cache first (key: balance:{network}:{token}:{address}) - If cache miss, query blockchain RPC - Cache result with 30s TTL - Return balance in appropriate decimals [ ] 5.3 Implement GetTONBalance(address): - Call TON RPC: getAddressBalance - Parse nanoTON amount - Convert to TON (divide by 1e9) - Return as decimal string [ ] 5.4 Implement GetTRC20Balance(address, contract): - Call TronGrid: /wallet/triggerconstantcontract - Contract: balanceOf(address) - Parse hex result - Convert based on token decimals (6 for USDT) - Return as decimal string [ ] 5.5 Implement GetTRXBalance(address): - Call TronGrid: /wallet/getaccount - Parse balance field (in SUN) - Convert to TRX (divide by 1e6) - Return as decimal string [ ] 5.6 Implement batch balance fetching: - GetMultipleBalances(addresses, network, token) - Parallel queries with worker pool (limit 10 concurrent) - Aggregate results [ ] 5.7 Implement cache invalidation: - InvalidateBalance(address, network, token) - Called after deposit/withdrawal - Delete from Redis [ ] 5.8 Add circuit breaker for RPC calls: - Track failure rate - Open circuit after 5 failures in 10s - Half-open after 30s [ ] 5.9 Add HTTP handler: - GET /api/v1/wallet/balance?address=X&network=Y&token=Z - Validate inputs - Call BalanceService - Return JSON response [ ] 5.10 Add metrics: - Balance query duration - Cache hit/miss rate - RPC error rate
Testing Checklist: [ ] Query TON balance for known address [ ] Query TRX balance for known address [ ] Query USDT-TRC20 balance for known address [ ] Verify caching works (2nd query faster) [ ] Test cache expiration (wait 31s, query again) [ ] Test batch balance queries [ ] Test circuit breaker (simulate RPC failures) [ ] Test HTTP endpoint
Reference Implementation (Node.js): Location: gitibot-back-main/services/blockchainService.js Method: getBlockchainBalance(), getWalletBalanceData()
Success Criteria: ✓ Can query balances for TON, TRX, USDT-TRC20 ✓ Caching reduces query time by 90%+ ✓ Circuit breaker prevents cascading failures ✓ HTTP endpoint returns correct JSON ✓ Metrics are accurate
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 0 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 0 Completion Criteria: ✓ All signers working (TON + TRON) ✓ All watchers working (TON + TRON) ✓ Balance service working for all networks ✓ Can create wallets end-to-end ✓ Can detect deposits end-to-end ✓ Can query balances end-to-end
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 1: CORE SERVICES (Week 2) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 1.1: CREATE MARKET SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🟡 HIGH - BLOCKS: TMA market page Estimated Time: 10-12 hours Status: [ ] NOT STARTED
Files to Create: services/market/cmd/server/main.go services/market/internal/market/service.go services/market/internal/market/price_fetcher.go services/market/internal/market/transport/grpc/handler.go services/market/internal/market/transport/http/handler.go services/market/internal/market/domain/entity/asset.go services/market/internal/cache/redis.go services/market/go.mod services/market/Dockerfile shared-schema/proto/market/v1/market.proto
Implementation Steps: [ ] 1.1.1 Scaffold market service directory structure [ ] 1.1.2 Create protobuf definitions: - Asset message (id, symbol, name, price_usd, price_toman, change_24h, volume_24h, logo_url) - GetAssetsRequest/Response - GetAssetRequest/Response - GetPricesRequest/Response - GetChartDataRequest/Response [ ] 1.1.3 Generate Go code from proto: buf generate [ ] 1.1.4 Create Asset entity: - ID, Symbol, Name, PersianName - Type (coin, token, memecoin) - Networks (which networks support this asset) - Metadata (logo, description, links) [ ] 1.1.5 Create database migrations: - assets table - asset_prices table (historical) - asset_networks table (many-to-many) [ ] 1.1.6 Implement CoinGecko client: - API: https://api.coingecko.com/api/v3/ - Endpoint: /simple/price?ids=X&vs_currencies=usd - Endpoint: /coins/markets?vs_currency=usd - Rate limit: 10-50 calls/min (depends on plan) - Implement retry with backoff [ ] 1.1.7 Implement Nobitex client (for Toman prices): - API: https://api.nobitex.ir/ - Endpoint: /market/stats - Parse Toman prices for supported coins [ ] 1.1.8 Implement price aggregation logic: - Fetch from CoinGecko (USD) - Fetch from Nobitex (Toman) - Calculate weighted average if multiple sources - Store in Redis with 1-minute TTL [ ] 1.1.9 Implement GetAssets(): - Return list of all supported assets - Include current prices - Support search/filter by symbol, name, type - Pagination support [ ] 1.1.10 Implement GetAsset(symbol): - Return single asset details - Include price history (24h high/low) - Include volume data [ ] 1.1.11 Implement GetPrices(symbols[]): - Batch price query - Return map of symbol -> price [ ] 1.1.12 Implement GetChartData(symbol, timeframe): - Timeframes: 1h, 24h, 7d, 1m, 1y - Fetch from CoinGecko market_chart endpoint - Cache heavily (24h+ for old data) - Return OHLC data [ ] 1.1.13 Implement background price updater: - Run every 30 seconds - Fetch prices for all assets - Update Redis cache - Store in database (for historical queries) [ ] 1.1.14 Implement gRPC service [ ] 1.1.15 Implement HTTP REST handlers (for gateway) [ ] 1.1.16 Add Prometheus metrics [ ] 1.1.17 Add health check endpoint [ ] 1.1.18 Write Dockerfile
Testing Checklist: [ ] Fetch prices from CoinGecko successfully [ ] Fetch Toman prices from Nobitex [ ] Price caching works correctly [ ] GetAssets returns all supported assets [ ] GetAsset returns correct data for BTC [ ] GetChartData returns OHLC data [ ] Background updater runs continuously [ ] gRPC calls work from gateway [ ] Service starts independently in Docker
Reference Implementation (Node.js): Location: gitibot-back-main/services/voucherRateService.js Method: getCoinGeckoPrice(), getNobitexPrice() Note: Node.js has basic price fetching, expand in Go
Assets to Support Initially:
- BTC (Bitcoin)
- ETH (Ethereum)
- USDT (Tether)
- TRX (Tron)
- BNB (Binance Coin)
- TON (Toncoin)
- USDC (USD Coin)
Success Criteria: ✓ Service runs independently ✓ Fetches prices from external APIs ✓ Caching reduces API calls ✓ gRPC interface works ✓ Metrics exposed ✓ Docker container builds and runs
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 1.2: CREATE TRANSACTION SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🟡 HIGH - BLOCKS: TMA transaction history, buy/sell Estimated Time: 12-14 hours Status: [ ] NOT STARTED
Files to Create: services/transaction/cmd/server/main.go services/transaction/internal/transaction/service.go services/transaction/internal/transaction/processor.go services/transaction/internal/transaction/fee_calculator.go services/transaction/internal/transaction/domain/entity/transaction.go services/transaction/internal/transaction/domain/repository/transaction.repository.go services/transaction/internal/transaction/transport/grpc/handler.go services/transaction/go.mod services/transaction/Dockerfile services/transaction/migrations/001_create_transactions.sql shared-schema/proto/transaction/v1/transaction.proto
Implementation Steps: [ ] 1.2.1 Scaffold transaction service directory structure [ ] 1.2.2 Create protobuf definitions: - Transaction message - GetTransactionsRequest/Response (with pagination) - GetTransactionRequest/Response - CreateBuyOrderRequest/Response - CreateSellOrderRequest/Response - CreateSwapOrderRequest/Response [ ] 1.2.3 Generate Go code from proto [ ] 1.2.4 Create database migrations: - transactions table: - id (ULID) - user_id - type (buy, sell, swap, deposit, withdrawal, voucher_buy, voucher_sell) - from_asset, from_amount - to_asset, to_amount - rate, fee_amount, fee_asset - status (pending, processing, completed, failed, cancelled) - network (TRON, TON, BSC, INTERNAL) - tx_hash (blockchain transaction hash, if applicable) - metadata (JSON for extra data) - created_at, updated_at, completed_at - Indexes: - user_id + created_at DESC - user_id + status - tx_hash (unique) - created_at + status [ ] 1.2.5 Implement Transaction entity [ ] 1.2.6 Implement TransactionRepository: - Create(tx) - FindByID(id) - FindByUserID(userId, pagination) - FindByTxHash(txHash) - UpdateStatus(id, status) [ ] 1.2.7 Implement FeeCalculator: - CalculateBuyFee(amount, asset) - CalculateSellFee(amount, asset) - CalculateSwapFee(fromAmount, fromAsset, toAsset) - CalculateNetworkFee(network, asset) - Load fee config from database (fee_configurations table) [ ] 1.2.8 Implement GetTransactions(): - Fetch paginated transaction history for user - Support filters: type, status, date range - Include: asset details, rates at time of transaction - Return in descending order (newest first) [ ] 1.2.9 Implement GetTransaction(id): - Fetch single transaction details - Include all metadata - Include blockchain explorer link [ ] 1.2.10 Implement CreateBuyOrder(): - Input: userId, asset, amount, paymentMethod - Validate: user exists, amount > minimum - Calculate: fees, total cost - Check: user balance (if paying with Toman) - Create: transaction record (status: pending) - Lock: user balance for pending order - Return: order ID [ ] 1.2.11 Implement CreateSellOrder(): - Input: userId, asset, amount - Validate: user has sufficient balance - Calculate: fees, net amount to receive - Lock: asset balance - Create: transaction record (status: pending) - Queue: for processing - Return: order ID [ ] 1.2.12 Implement CreateSwapOrder(): - Input: userId, fromAsset, fromAmount, toAsset - Validate: user has sufficient balance - Fetch: current exchange rate from market service - Calculate: toAmount, fees - Lock: fromAsset balance - Create: transaction record (status: pending) - Process: atomic swap (deduct fromAsset, credit toAsset) - Unlock and update: balances - Update: transaction status to completed - Return: transaction details [ ] 1.2.13 Implement transaction processing pipeline: - Listen to transaction queue (NATS/Redis) - Process pending transactions - Update statuses - Handle failures with rollback [ ] 1.2.14 Implement balance locking mechanism: - LockBalance(userId, asset, amount) - UnlockBalance(userId, asset, amount) - Use Redis for distributed locking - Prevent race conditions [ ] 1.2.15 Implement atomic balance updates: - Use database transactions - Update multiple balances atomically (for swaps) - Rollback on any failure [ ] 1.2.16 Add event emission: - Emit transaction_created event - Emit transaction_completed event - Emit transaction_failed event - Write to outbox table [ ] 1.2.17 Implement gRPC service [ ] 1.2.18 Add metrics and health checks [ ] 1.2.19 Write Dockerfile
Testing Checklist: [ ] Create buy order successfully [ ] Verify balance is locked during pending order [ ] Create sell order successfully [ ] Create swap order and verify atomic balance update [ ] Test insufficient balance scenarios [ ] Test fee calculations [ ] Test transaction history pagination [ ] Test concurrent transactions (no race conditions) [ ] Test transaction rollback on failure [ ] Service runs independently in Docker
Reference Implementation (Node.js): Location: gitibot-back-main/services/transactionService.js Methods: processBuy(), processSell(), processSwap() Location: gitibot-back-main/models/TransactionHistory.js
Success Criteria: ✓ Can create buy/sell/swap orders ✓ Balance locking prevents double-spend ✓ Atomic operations ensure consistency ✓ Transaction history is accurate ✓ Fees calculated correctly ✓ Events emitted to outbox ✓ Service runs independently
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 1.3: ADD GATEWAY ROUTES FOR TMA ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🟡 HIGH - BLOCKS: TMA frontend integration Estimated Time: 8-10 hours Status: [ ] NOT STARTED
Files to Modify: services/gateway/cmd/main.go services/gateway/internal/handlers/wallet_handler.go services/gateway/internal/handlers/market_handler.go services/gateway/internal/handlers/transaction_handler.go services/gateway/internal/handlers/auth_handler.go services/gateway/internal/middleware/auth.go services/gateway/internal/middleware/cors.go services/gateway/internal/middleware/rate_limit.go
Routes to Add (based on gitinext-telegram/API_INTEGRATION_QUICK_REFERENCE.md):
[ ] 1.3.1 Authentication Routes: POST /tma/auth/verify - Verify Telegram initData (EXISTING) POST /auth/refresh - Refresh access token POST /auth/logout - Invalidate tokens GET /auth/me - Get current user
[ ] 1.3.2 Wallet Routes: POST /api/v1/wallet/hd - Create HD wallet (EXISTING) GET /api/v1/wallets - List user wallets (EXISTING) GET /api/v1/wallet/default - Get default wallet (EXISTING) GET /api/v1/wallet/:id - Get wallet details (EXISTING) POST /api/v1/wallet/:id/set-default - Set default wallet (EXISTING) GET /api/v1/wallet/balance - Get wallet balance (NEW)
[ ] 1.3.3 Market Routes: GET /api/v1/market/assets - List all crypto assets GET /api/v1/market/asset/:symbol - Get asset details GET /api/v1/market/prices - Get current prices GET /api/v1/market/chart/:symbol - Get historical chart data
[ ] 1.3.4 Transaction Routes: GET /api/v1/transactions - List user transactions GET /api/v1/transactions/:id - Get transaction details POST /api/v1/transactions/buy - Buy cryptocurrency POST /api/v1/transactions/sell - Sell cryptocurrency POST /api/v1/transactions/swap - Swap tokens
[ ] 1.3.5 Deposit Routes: GET /api/v1/wallet/deposit/address/:asset - Get deposit address GET /api/v1/wallet/deposit/:id/status - Check deposit status GET /api/v1/wallet/deposits - List deposit history
[ ] 1.3.6 Withdrawal Routes: POST /api/v1/wallet/withdraw - Submit withdrawal GET /api/v1/wallet/withdraw/limits/:asset - Get withdrawal limits GET /api/v1/wallet/withdrawals - List withdrawal history GET /api/v1/wallet/withdraw/:id - Get withdrawal status
Implementation Steps: [ ] 1.3.7 Implement HTTP handlers: - Parse JSON request body - Validate inputs (use go-playground/validator) - Extract user from JWT token - Call appropriate gRPC service - Handle gRPC errors → HTTP status codes - Return JSON response [ ] 1.3.8 Add CORS middleware: - Allow origins: TMA domain, TWA domain - Allow methods: GET, POST, PUT, DELETE - Allow headers: Authorization, Content-Type - Allow credentials: true [ ] 1.3.9 Add rate limiting middleware: - 100 requests per minute per user - 1000 requests per minute per IP - Use Redis for distributed rate limiting [ ] 1.3.10 Add authentication middleware: - Verify JWT token from Authorization header - Extract user ID from token - Inject user context into request - Return 401 if invalid/expired [ ] 1.3.11 Add request logging middleware: - Log: method, path, user_id, duration, status - Use structured logging (zap) [ ] 1.3.12 Add error handling middleware: - Catch panics - Map errors to appropriate HTTP status codes - Return consistent error JSON format [ ] 1.3.13 Update OpenAPI/Swagger documentation
Testing Checklist: [ ] All routes respond correctly [ ] Authentication middleware works [ ] Rate limiting enforces limits [ ] CORS allows TMA origin [ ] Request logging works [ ] Error responses are consistent [ ] Swagger docs are accurate
Success Criteria: ✓ All 40+ TMA endpoints implemented ✓ JWT authentication works ✓ Rate limiting prevents abuse ✓ CORS configured correctly ✓ Swagger docs up to date
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 1 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 1 Completion Criteria: ✓ Market service operational ✓ Transaction service operational ✓ Gateway routes implemented ✓ TMA can fetch prices ✓ TMA can view transaction history ✓ TMA can execute buy/sell/swap
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 2: FINANCIAL SERVICES (Week 3-4) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 2.1: CREATE PAYMENT SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🟠 MEDIUM - BLOCKS: payment gateways Estimated Time: 14-16 hours Status: [ ] NOT STARTED
[DETAILED TASK BREAKDOWN TO BE ADDED]
Note: Covers Paystar, FinnoTech, Card-to-Card, IBAN deposits Reference: gitibot-back-main/services/paymentProvider/ Reference: gitibot-back-main/services/finnotechService.js
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 2.2: CREATE VOUCHER SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🟠 MEDIUM - BLOCKS: Voucher operations Estimated Time: 14-16 hours Status: [ ] NOT STARTED
[DETAILED TASK BREAKDOWN TO BE ADDED]
Note: Covers PS, HOT, UTOPIA vouchers Reference: gitibot-back-main/services/voucherService.js Reference: gitibot-back-main/bot/ps_voucher.js Reference: gitibot-back-main/bot/hot_voucher.js Reference: gitibot-back-main/bot/utopia_voucher.js
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 2.3: CREATE BLOCKCHAIN SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Priority: 🟠 MEDIUM - BLOCKS: Exonyx integration Estimated Time: 10-12 hours Status: [ ] NOT STARTED
[DETAILED TASK BREAKDOWN TO BE ADDED]
Note: Exonyx API client for wallet operations Reference: gitibot-back-main/services/blockchainService.js
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 2 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 3: USER SERVICES (Week 5) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 3.1: CREATE SUPPORT SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 3.2: CREATE KYC SERVICE (NEW MICROSERVICE) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 3.3: EXTEND ACCOUNT SERVICE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 3 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 4: INTEGRATION & FLOWS (Week 6) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 4.1: ADMIN PANEL BACKEND ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 4.2: WEBSOCKET SERVER ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 4.3: END-TO-END DEPOSIT FLOW ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 4.4: END-TO-END WITHDRAWAL FLOW ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 4 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 5: PRODUCTION READINESS (Week 7-8) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 5.1: CONTAINERIZATION ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 5.2: DOCKER COMPOSE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 5.3: DATABASE MIGRATIONS ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 5 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 6: FRONTEND & TESTING (Week 8+) │ └─────────────────────────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 6.1: FRONTEND API INTEGRATION ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 6.2: INTEGRATION TESTING ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TASK 6.3: MONITORING & OBSERVABILITY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [DETAILED TASK BREAKDOWN TO BE ADDED]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END OF PHASE 6 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
================================================================================
📊 PROGRESS TRACKING
PHASE 0: FOUNDATION [ ] Task 0.1: TON Signer 0% [ ] Task 0.2: TRON Signer 0% [ ] Task 0.3: TON Watcher 0% [ ] Task 0.4: TRON Watcher 0% [ ] Task 0.5: Balance Service 0% ──────────────────────────────────────────────── Phase 0 Progress: 0%
PHASE 1: CORE SERVICES [ ] Task 1.1: Market Service 0% [ ] Task 1.2: Transaction Service 0% [ ] Task 1.3: Gateway Routes 0% ──────────────────────────────────────────────── Phase 1 Progress: 0%
PHASE 2: FINANCIAL SERVICES [ ] Task 2.1: Payment Service 0% [ ] Task 2.2: Voucher Service 0% [ ] Task 2.3: Blockchain Service 0% ──────────────────────────────────────────────── Phase 2 Progress: 0%
PHASE 3: USER SERVICES [ ] Task 3.1: Support Service 0% [ ] Task 3.2: KYC Service 0% [ ] Task 3.3: Account Extension 0% ──────────────────────────────────────────────── Phase 3 Progress: 0%
PHASE 4: INTEGRATION [ ] Task 4.1: Admin Panel 0% [ ] Task 4.2: WebSocket 0% [ ] Task 4.3: Deposit Flow 0% [ ] Task 4.4: Withdrawal Flow 0% ──────────────────────────────────────────────── Phase 4 Progress: 0%
PHASE 5: PRODUCTION [ ] Task 5.1: Containerization 0% [ ] Task 5.2: Docker Compose 0% [ ] Task 5.3: Migrations 0% ──────────────────────────────────────────────── Phase 5 Progress: 0%
PHASE 6: FRONTEND & TESTING [ ] Task 6.1: Frontend Integration 0% [ ] Task 6.2: Testing 0% [ ] Task 6.3: Monitoring 0% ──────────────────────────────────────────────── Phase 6 Progress: 0%
════════════════════════════════════════════════════════════════════════════════ OVERALL PROGRESS: 0/24 tasks completed (0%) ════════════════════════════════════════════════════════════════════════════════
================================================================================
🎯 CURRENT SPRINT
Sprint: Phase 0 - Week 1 Status: READY TO START Next Task: 0.1 - Fix TON Signer
Tasks in This Sprint:
- [ ] TON Signer - 4-6 hours
- [ ] TRON Signer - 4-6 hours
- [ ] TON Watcher - 8-10 hours
- [ ] TRON Watcher - 8-10 hours
- [ ] Balance Service - 4-6 hours
Sprint Goal: Complete all critical infrastructure to enable wallet operations and deposit detection.
Blockers: None Risks: None identified yet Dependencies: tonutils-go, gotron-sdk, go-ethereum libraries
================================================================================
📝 NOTES & DECISIONS
2025-10-06: Migration plan created
- Chose bottom-up approach (infrastructure first)
- Defined 6 phases over 8 weeks
- Identified 24 major tasks
- Created detailed breakdown for Phase 0 (5 tasks)
- Phases 2-6 tasks to be detailed as we progress
Next Steps:
- Get approval from team
- Start Phase 0, Task 0.1 (TON Signer)
- Update progress after each task completion
- Detail Phase 2 tasks after Phase 0 completion
================================================================================