Method
How Proof Systems generates and validates market intelligence.
What we do
Proof Systems runs an autonomous trading bot that scans every integrated exchange across 19 pairs monitored across 4 exchanges 24/7. When it finds a price difference worth trading, it executes both sides simultaneously. It never holds directional exposure. It doesn't bet on market direction.
The strategies
Cross-Exchange Arbitrage (XARB)
Same asset, different prices on two exchanges. The system captures the spread by executing both sides simultaneously. The spread minus fees is the profit.
Triangular Arbitrage (TRIG)
Three trades in a circle on one exchange. BTC to ETH, ETH to USD, USD to BTC. If the math works out to more than the starting amount, the system executes all three.
Mean Reversion (MREV)
Asset pairs that normally move together sometimes diverge. When the gap gets statistically extreme, bet on it closing. Works on slower timescales.
Flash Crash Harvesting (FCR)
Sudden price drops on one exchange while others hold steady. The system detects the dislocation and captures the spread across exchanges. Rare but high-spread.
Funding Rate Arbitrage (FUND)
Perpetual futures pay periodic funding rates. When rates are extreme, hold opposing positions on spot and futures to capture the rate.
Why we publish everything
Every other signal service publishes the wins and buries the losses. We publish detection outcomes — misses where tracked, down days, costs incurred. Outcome tracking is per-strategy and honest about what's instrumented. The track record is verifiable from signal #0001. Sequential IDs mean nothing can be hidden.
How spread persistence is measured
Spreads in this dataset come from live WebSocket feeds across the active venues (Coinbase, Kraken, OKX, Crypto.com). When a cross-venue difference exceeds a route's detection threshold, we log it with a millisecond timestamp.
Every detected spread is then re-fetched via REST at the point a trade would be attempted. The re-fetch pulls fresh order book state from both legs and recomputes the spread net of fees, latency, and book depth at intended trade size. Spreads that fail this re-check are dropped from the persistence dataset and accounted for under CAPTURE CONTEXT with a labeled reason — decay, fee threshold, insufficient depth, REST unavailable, and so on.
Persistence figures, TOP ROUTES rankings, and per-route ERL metrics use the re-checked set.
The current record covers detection-side and verify-side outcomes. Execution-side outcomes — captured spread, slippage, time-to-fill — will be measured from the first live trade.
How to read a signal
Net captured vs gross spread vs fees
Gross spread is the raw price difference. Fees are exchange costs on both sides. Net captured is what's left — the actual profit.
Data quality (Live WS vs REST)
Live WS means the price came from a real-time WebSocket feed. REST means it came from a polling request — slightly less fresh.
Market regime
Ranging, trending, or volatile. The system detects regime changes and adjusts which strategies are active.
Capture rate
How often the system successfully executes a detected spread condition. Not every signal results in a trade — speed matters.
Verify link
Every signal has a unique ID. Use it at /verify to see the full record.
P&L attribution
We separate trading alpha from market beta. When we report P&L, we show exactly how much came from the spread we captured vs market price movement during the hold period. These are different things. We show both.
Bot activity — not financial advice.