gendevelopment/dkgcopytrade

This repository appears to implement a Polymarket copy-trading system, with the core trading logic in Python and a thin PHP/browser layer for access, status, and scheduled operations.

1. Core responsibility

- The project is centered on monitoring Polymarket activity, mirroring or reacting to trades, and keeping track of positions and outcomes.

- The codebase suggests a mix of live automation, reporting, and post-trade settlement.

2. External market integration

- polymarket_api.py and polymarket_clob.py are the main integration points to Polymarket.

- One likely handles higher-level API calls and the other the CLOB/trading interface, which is the execution boundary for placing or managing orders.

3. Tracking / signal ingestion

- tracker.py is probably the main watcher that detects relevant trader or market events and turns them into actionable signals.

- tracker_web3.py suggests an alternate or complementary event source using Web3/on-chain data rather than only the standard API layer.

4. Trade execution and orchestration

- main.py is likely the primary runtime entrypoint that wires the tracker, API clients, database, and execution logic together.

- manual_resolve.py and redeem.py indicate separate operational paths for resolving markets or claiming settled value after outcomes are known.

5. Persistence and configuration

- database.py is the persistence boundary for storing tracked data, trade state, and computed results.

- config.py holds environment- or deployment-specific settings, likely including API credentials, account identifiers, and runtime options.

- setup_key.py suggests a one-time or admin flow for initializing signing keys or secret material.

6. Analytics subsystem

- analytics.py is the computation/reporting layer for performance metrics, trade summaries, or strategy analysis.

- analytics.html is the corresponding static UI surface for viewing those results.

7. Operational dashboard

- dashboard.py appears to serve a runtime dashboard or backend for operational visibility.

- dashboard_static.html is the browser-facing presentation layer for that dashboard, likely fed by data from Python or PHP endpoints.

8. PHP web/auth boundary

- api.php and auth.php provide a separate web/API layer, likely for browser access, session handling, or authenticated control actions.

- This implies the system is split between Python for trading/analytics and PHP for lightweight web serving or integration with existing hosting.

9. Scheduling / watchdog

- watchdog_cron.php is a cron-oriented health or maintenance hook.

- It likely monitors process liveness, triggers periodic tasks, or ensures the trading system stays operational.

10. Testing

- test_clob.py is a focused test module for the trading/exchange integration, which is the most critical and failure-prone boundary in the system.

11. Main data flow

- External Polymarket data comes in through the API/Web3 trackers.

- Python components normalize and persist state in the database.

- Trading actions are executed through the CLOB client.

- Analytics and dashboard code read from persisted state and expose results through HTML/PHP entrypoints.

12. Architecture boundary summary

- The clearest boundary is: Python = trading engine, tracking, analytics, persistence, while PHP/HTML = operator-facing web access and scheduled web-side automation.

- For an architecture diagram, the key nodes are the Polymarket integrations, the tracker/execution pipeline, the database, and the two UI layers (dashboard/analytics plus auth/API).