mexer is a CEX/DEX arbitrage runtime centered on MEXC Futures execution and OKX Web3 DEX price discovery. It watches synchronized market data, validates useful spread conditions, reserves workers from a multi-account pool, and manages each trade as an incident with entry, DCA, protection, exit, and reporting stages.
This package is a technical presentation layer only. It explains the current runtime shape and its public/private boundary without exposing runnable trading logic, account material, proxy inventory, certificates, raw anti-bot artifacts, or private execution recipes.
- The runtime is specifically about
MEXC FuturesversusOKX Web3 DEX, not a generic multi-exchange framework. - Live market data from both sides is merged into one hub and fanned out to the engine, WebSocket stream, and UI.
- Trade management is incident-based and includes validation, worker reservation, DCA, exits, and reporting.
- Worker orchestration is multi-account and stateful rather than single-session automation.
- The control surface includes HTTP endpoints, a live WebSocket feed, worker controls, incident snapshots, and report export.
- The execution path is anti-bot-aware and challenge-resilient at a capability level, while operational detail stays private.
| Area | Current shape |
|---|---|
| Primary runtime | Go daemon |
| CEX market data | MEXC Futures WebSocket |
| DEX market data | OKX Web3 DEX WebSocket |
| Control plane | HTTP API + WebSocket UI stream |
| UI | Static SPA served by the Go daemon |
| Persistence | JSON config/state files and optional PostgreSQL reporting |
| Worker layer | Multi-account execution with per-account state |
| Execution client | Browser-profiled HTTP/TLS execution with challenge detection and retry capabilities |
| Access control | mTLS outside development mode |
| Auxiliary tooling | Diagnostics, proxy checks, pair inspection, support CLIs |
- Coordinated account-farm execution instead of a single-account bot.
- Useful-spread validation rather than acting on every raw CEX/DEX gap.
- Entry discipline that combines spread checks, queue logic, and additional validation before execution.
- Runtime-level randomization across timing, order placement offsets, size shaping, and TP refresh cadence.
- Per-account browser/network identity continuity with sticky session and proxy affinity.
- Anti-detection layering around the execution path without turning the public package into an operational write-up.
MEXC FuturesandOKX Web3 DEXprices enter the runtime over separate WebSocket paths.- The stream hub normalizes ticks, keeps the latest snapshot, and broadcasts updates to the engine and UI.
- The execution service tracks anchor prices and waits for a useful spread, not just a transient raw gap.
- When a signal qualifies, the runtime validates the opportunity, checks worker availability, and reserves a worker set.
- Reserved workers execute the MEXC leg through a browser-profiled HTTP path with session continuity and challenge-aware retry logic.
- The incident stays alive through DCA, panic/max-lifetime protections, TP maintenance, and final close conditions.
- Incident snapshots, worker state, live ticks, and recent trade reports are exposed through the control plane.
| Surface | Status | Public claim |
|---|---|---|
| MEXC Futures market data via WebSocket | Active | The runtime ingests CEX ticks in real time and feeds them into the hub. |
| OKX Web3 DEX price feed via WebSocket | Active | The runtime ingests DEX-side prices for spread calculation. |
| MEXC execution POST path | Active with private prerequisites | Trade execution exists, but depends on private session material and controlled network conditions. |
| Scout / limit discovery | Conditional | Contract metadata and volume limits are refreshed through a dedicated scout path when scout accounts are available. |
| Web/API control plane | Active | The runtime exposes status, pair management, worker controls, incidents, reports, and live /ws updates. |
| Reports and CSV export | Conditional | Recent trades and CSV export exist when the reporting database is configured. |
| Anti-bot challenge handling | Active capability | The execution path detects challenge responses and includes a retry path after solver integration. |
See Integration Status for the conservative status table and caveats.
- Runtime overview and stack: Stack And Runtime
- Layered system map: Architecture Map
- Integration-by-integration status: Integration Status
- Engineering traits that make the runtime distinctive: Distinctive Characteristics
- Incident lifecycle: Trading Lifecycle
- Control surface: Control API
- Access, isolation, and anti-fraud posture: Security And Antifraud
- Honest runtime limits: Operating Constraints
- Public/private delivery boundary: Public/Private Boundary
- Conservative evidence summary: Evidence Snapshot
MEXC Futures WS ----\
>-- stream hub --> execution service --> incident manager --> execution client --> MEXC POST path
OKX DEX WS ---------/
\
\--> live snapshot + /ws + SPA monitor
Scout / check accounts --> contract metadata + volume limits --> execution service
Workers / account state --> reservation + shift state + warmup --> execution service
Incidents + completed trades --> optional PostgreSQL --> reports/latest + reports/export
See the fuller layered description in Architecture Map.
- The daemon boot path, HTTP routes, mTLS gate, stream hub, worker DTOs, incident snapshots, and report structs are directly visible in the current repository.
- The public claim about anti-bot-aware execution is based on capability-level evidence in the execution client and account/profile model, not on published challenge payloads.
- This package does not claim publish-safe performance benchmarks, profitability, or a formal acceptance suite that the repository does not contain.
See Evidence Snapshot.
- This package is not a runnable trading release.
- Private session material, certificates, account inventory, and controlled network conditions remain outside the public boundary.
- Anti-bot behavior, exchange policies, and challenge flows can change over time.
- Examples in this package are sanitized contract examples, not exported live data.
github_showcase/
├── README.md
├── .gitignore
├── docs/
│ ├── STACK_AND_RUNTIME.md
│ ├── ARCHITECTURE_MAP.md
│ ├── INTEGRATION_STATUS.md
│ ├── DISTINCTIVE_CHARACTERISTICS.md
│ ├── TRADING_LIFECYCLE.md
│ ├── CONTROL_API.md
│ ├── SECURITY_AND_ANTIFRAUD.md
│ ├── OPERATING_CONSTRAINTS.md
│ ├── PUBLIC_PRIVATE_BOUNDARY.md
│ └── EVIDENCE_SNAPSHOT.md
├── examples/
│ ├── status.json
│ ├── pair.json
│ ├── workers.json
│ ├── incident_snapshot.json
│ ├── trading_toggle.json
│ ├── proxy_check.json
│ ├── ws_price_tick.json
│ ├── ws_log_error.json
│ └── latest_trade.json
└── mock/
├── README.md
├── market_data.stub.txt
├── trading_engine.stub.txt
├── security.stub.txt
├── persistence.stub.txt
└── deploy/
├── runtime.service.example
└── runtime.env.example
- Stack And Runtime
- Architecture Map
- Integration Status
- Distinctive Characteristics
- Trading Lifecycle
- Control API
- Security And Antifraud
- Operating Constraints
- Public/Private Boundary
- Evidence Snapshot
- Examples
- Mock Boundaries
This showcase is meant to be readable on its own and portable as a public technical package. What it preserves is architecture, public surface, and reviewer-grade explanation. What it intentionally withholds is the set of materials that would turn the package into a runnable or replayable private operation.