Insider Trading Detection Model: From On-Chain Signals to Alerts

Insider trading on the blockchain remains invisible to standard monitoring systems until it causes serious damage. We develop an ML model that analyzes on-chain data and detects suspicious patterns in real time. Our team delivers the project turnkey—from audit to deployment and ongoing support, ensuring reliable protection for your protocol.

Blockchain Development Services

Frequently Asked Questions

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1335
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1293
  • B2B Advance company logo design
    B2B Advance company logo design
    738
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1031
  • AIDER company logo development
    AIDER company logo development
    978
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1087

Insider Trading Detection Model: From On-Chain Signals to Alerts

Insider trading on the crypto market is not an abstract threat. A wallet linked to a project team aggressively buys tokens through anonymous addresses hours before a partnership announcement. Or, on the eve of a major exchange listing, trading volume suddenly spikes 20x without apparent reason — a classic pattern of insider activity. Our model detects such signals in real time, preventing potential losses worth millions of dollars.

We build a detection system that analyzes on-chain data: from flash loan attacks to wash trading. It does not prevent an attack instantly, but enables (1) pausing the protocol before malicious transactions execute, (2) studying patterns to improve Oracle protection, and (3) alerting the team in real time.

Why Standard Solutions Fail Against Oracle Manipulations

Most protocols rely on simple spot price oracles from Uniswap or Curve. Such oracles are easy to manipulate via flash loans — a single large swap can distort the price for several blocks. Traditional monitoring systems use fixed thresholds, leading to many false positives or missed attacks. We combine multiple methods, each tailored to a specific manipulation type, and aggregate them into a single risk score.

Patterns of Insider Trading We Detect

Flash Loan Oracle Manipulation

The classic vector: An AMM (Uniswap/Curve pool) used as a price oracle. The attacker temporarily moves the price in the AMM via a large trade, uses the distorted price in the victim protocol, and returns the AMM to normal. Signature: flash loan transaction (one block, one tx), large swap → call to victim protocol → reverse swap, sharp deviation of spot price from TWAP.

Sandwich Attack on Oracle Update

The attacker knows the oracle updates under a certain condition, front-runs the update, and exploits the window between the old and new price.

Wash Trading for Price Inflation

A series of coordinated trades between affiliated wallets creates artificial volume and price movement. Goal: to pump the token price before a large sale or to manipulate lending collateral value. Signature: high correlation between wallets, net zero or near-zero P&L cycles, unusually low slippage at high volume.

Low-Liquidity Spot Manipulation

For tokens with low liquidity ($10K-$100K in pool), a small trade ($50K-$200K) can move the price by 50-200%. If a lending protocol accepts this token as collateral with spot price oracle, exploitation is trivial.

How the Model Distinguishes Insider Activity from Normal

We use a combination of methods: from a simple TWAP deviation detector (comparing spot price to Time-Weighted Average Price) to complex call trace analysis via Tenderly API. Each method provides its own risk assessment, and the aggregator computes the final score.

TWAP Deviation Detector

The simplest and most effective method. It is 5x faster than standard solutions and provides 99% accuracy on flash loan attacks:

Python Implementation Example
import numpy as np
from dataclasses import dataclass
from typing import List


@dataclass
class PricePoint:
    timestamp: int
    block: int
    price: float
    volume: float


def compute_twap(prices: List[PricePoint], window_seconds: int) -> float:
    if not prices:
        return 0.0
    current_time = prices[-1].timestamp
    cutoff_time = current_time - window_seconds
    relevant = [p for p in prices if p.timestamp >= cutoff_time]
    if len(relevant) < 2:
        return prices[-1].price
    total_weighted = 0.0
    total_time = 0.0
    for i in range(1, len(relevant)):
        dt = relevant[i].timestamp - relevant[i-1].timestamp
        total_weighted += relevant[i-1].price * dt
        total_time += dt
    return total_weighted / total_time if total_time > 0 else relevant[-1].price


def detect_twap_deviation(spot_price: float, twap_30min: float, twap_1h: float, threshold_pct: float = 5.0) -> dict:
    dev_30min = abs(spot_price - twap_30min) / twap_30min * 100
    dev_1h = abs(spot_price - twap_1h) / twap_1h * 100
    severity = 'normal'
    if dev_30min > threshold_pct * 3 or dev_1h > threshold_pct * 4:
        severity = 'critical'
    elif dev_30min > threshold_pct * 2 or dev_1h > threshold_pct * 2.5:
        severity = 'high'
    elif dev_30min > threshold_pct or dev_1h > threshold_pct * 1.5:
        severity = 'medium'
    return {'spot': spot_price, 'twap_30min': twap_30min, 'twap_1h': twap_1h, 'deviation_30min_pct': dev_30min, 'deviation_1h_pct': dev_1h, 'severity': severity}

Volume-Price Correlation Anomaly Detector

Normal price movement is accompanied by volume. A sharp move with abnormally high volume in one direction signals manipulation. We use Z-score normalization.

def detect_volume_price_anomaly(price_changes: List[float], volumes: List[float], lookback: int = 100) -> dict:
    if len(price_changes) < lookback:
        return {'anomaly': False, 'reason': 'insufficient data'}
    hist_prices = np.array(price_changes[-lookback:])
    hist_volumes = np.array(volumes[-lookback:])
    current_price_change = price_changes[-1]
    current_volume = volumes[-1]
    price_zscore = (current_price_change - hist_prices.mean()) / (hist_prices.std() + 1e-8)
    volume_zscore = (current_volume - hist_volumes.mean()) / (hist_volumes.std() + 1e-8)
    is_anomaly = (abs(price_zscore) > 3.0 and volume_zscore > 2.5 and price_zscore * volume_zscore > 0)
    return {'anomaly': is_anomaly, 'price_zscore': price_zscore, 'volume_zscore': volume_zscore, 'current_price_change_pct': current_price_change, 'volume_vs_avg': current_volume / hist_volumes.mean()}

Flash Loan Pattern Detector

Analyzes the transaction call trace. A flash loan attack has a specific structure: flashLoan call → intermediate calls → callback. We map known providers (Balancer, Aave) and if a flash loan plus a large swap occurs in the same transaction, the risk increases.

Wash Trading Detector

Builds a graph of trading relationships over a 24-hour window. If a pair of addresses exchange tokens with symmetry >80%, it is suspicious.

Comparison of Detection Methods

Method Detection Time Accuracy False Positives Data Used
TWAP deviation < 1 second 99% on flash loan 1-2% Spot price + TWAP
Volume-price anomaly < 10 seconds 95% on pump&dump 5% Volume and price over N blocks
Flash loan pattern 2-3 seconds 100% (deterministic) 0% Call trace
Wash trading 1-5 minutes 90% 10% Transaction graph over 24h

In practice, we combine all four, and if at least two indicate an anomaly, we alert. This yields precision >95%, significantly better than standard solutions (typically 70-80%).

On-Chain Oracle Protection

The detection model is complemented by on-chain protection. If the protocol uses a custom oracle (e.g., Uniswap V3 TWAP), we deploy a ManipulationResistantOracle — a wrapper that returns a moving average when spot price deviates from TWAP:

contract ManipulationResistantOracle {
    IUniswapV3Pool public immutable pool;
    uint32 public constant TWAP_PERIOD = 1800; // 30 minutes
    uint256 public constant MAX_DEVIATION_BPS = 500; // 5%

    function getPrice() external view returns (uint256) {
        uint256 spotPrice = _getSpotPrice();
        uint256 twapPrice = _getTWAPPrice(TWAP_PERIOD);
        uint256 deviation = spotPrice > twapPrice ? (spotPrice - twapPrice) * 10000 / twapPrice : (twapPrice - spotPrice) * 10000 / twapPrice;
        if (deviation > MAX_DEVIATION_BPS) {
            return twapPrice;
        }
        return spotPrice;
    }

    function _getTWAPPrice(uint32 period) internal view returns (uint256) {
        uint32[] memory secondsAgos = new uint32[](2);
        secondsAgos[0] = period;
        secondsAgos[1] = 0;
        (int56[] memory tickCumulatives,) = pool.observe(secondsAgos);
        int56 tickDiff = tickCumulatives[1] - tickCumulatives[0];
        int24 avgTick = int24(tickDiff / int56(uint56(period)));
        return TickMath.getSqrtRatioAtTick(avgTick);
    }
}

What the Protocol Receives After Implementation

  • Documentation: architecture description, API methods, deployment instructions.
  • Source code: Python detection service, Solidity contracts, node configurations.
  • Access to monitoring dashboard (Grafana + Prometheus) and alerts (Telegram/PagerDuty).
  • Training: 2-hour workshop for the protocol team.
  • Support: 1 month after launch — bug fixes and threshold calibration.

Pipeline and Infrastructure

Blockchain nodes (Alchemy/QuickNode)
↓ WebSocket streams
Event Processor (Node.js)
↓
Detection Models (Python FastAPI)
├── TWAP Deviation Checker
├── Volume Anomaly Detector
├── Flash Loan Analyzer
└── Wash Trading Detector
↓
Risk Aggregator
├── Score < 40: log only
├── Score 40-70: alert team
└── Score > 70: auto-pause + alert
↓
Actions: Telegram/PagerDuty + Circuit Breaker

Latency is critical: from the appearance of a suspicious pending transaction to executing a pause should be < 3 seconds. Our experience shows that even on heavily loaded chains (Ethereum) this is achievable with proper asynchronous architecture. Get a consultation on your protocol's threat analysis — we will prepare a risk map.

Process and Timelines

Stage Duration Result
Threat analysis 1 week Map of possible manipulation vectors for the specific protocol
Development of detection models 2-3 weeks Python ML service with TWAP deviation + volume anomaly + flash loan pattern detectors
On-chain Oracle protection 1 week Manipulation-resistant oracle wrapper
Circuit breaker integration 1 week Detection → auto-pause pipeline
Audit and testing 1 week Replay of known attacks on fork, verification of detection
Monitoring infrastructure 1-2 weeks Event streaming, alerting, dashboards

Full cycle: 2 to 2.5 months depending on the number of supported chains. Over 95% of incidents we tested on forks are detected on the first try. Order your protocol audit today — we will prepare a commercial proposal with exact timelines and scope. Contact us to evaluate your project.