The build
These markets run on a public ledger, so every trade and every transfer of funds is visible. That makes it possible to ask whether a cluster of accounts is really one person, or whether an account that consistently buys just before news breaks was funded from the same source as several others.
The design decision that matters is the threshold for saying so. An accusation of insider trading is serious and the evidence is circumstantial, so the tool requires three separate lines of evidence to agree before it will use that label. If it cannot trace funding on the ledger, it does not lower the bar — it caps what it is willing to conclude and says so. Several known blind spots are documented rather than hidden, and one detection rule was removed entirely after I found it was firing on an ordinary feature of how the venue holds user funds.
The technical version
A three-tier scoring engine running daily scans over the top 200 markets by volume, tracing on-chain funding up to 3 hops, with 51 tests under pytest. A wallet is classified as an insider only when all three tiers corroborate. Without an on-chain key the third tier is disabled and classifications cap out one level lower, by design rather than by degradation.
Documented limits
Wallets using mixers are opaque to the third tier and are downgraded rather than guessed at. The venue's per-user history endpoints return empty for most wallets, so trading history cannot be reconstructed. The backtest's definition of a winner is retrospective, and therefore slightly optimistic.
One heuristic was retired outright: a dormant-wallet signal fired falsely on the venue's safe-proxy architecture, where activity routes through a proxy contract, so proxy-funded wallets are now excluded from it.
Python, on-chain tracing via an RPC (remote procedure call) endpoint — a server that answers queries about the public ledger — venue REST APIs, SQLite, pytest; scikit-learn, UMAP, HDBSCAN and Gaussian mixtures on the clustering side.