🚨 Detect Rapid Asset Draining Events
Issue: #143
Type: Feature
Priority: Critical
Estimated Effort: 2–3 days
🧠 Concept
Implement a real-time detection module that identifies rapid asset depletion from monitored wallets by continuously analyzing balance changes, outgoing transactions, and transfer velocity.
The detector should distinguish between expected activity and potentially malicious draining behavior, generating high-priority alerts when wallets experience sudden or abnormal loss of assets.
This feature serves as an early warning system for wallet compromises, private key theft, malicious contract interactions, or unauthorized fund movements.
⚠️ Problem
Compromised wallets are often emptied within seconds or minutes after an attacker gains access. Traditional monitoring based solely on transaction volume or periodic balance checks may detect the incident too late.
Common attack scenarios include:
- Stolen private keys
- Wallet compromise
- Phishing attacks
- Malicious contract approvals
- Automated draining bots
- Exploited multisig wallets
- Insider fund transfers
Without rapid asset-draining detection:
- Security teams may not be notified until all assets are lost.
- Large financial losses can occur before manual intervention.
- Multiple suspicious transfers may appear as isolated events instead of a coordinated attack.
- Incident response is delayed.
📁 Implementation Scope
src/modules/detection/draining/
Suggested structure:
draining/
├── asset-draining.service.ts
├── asset-draining.detector.ts
├── balance-monitor.service.ts
├── velocity-analyzer.service.ts
├── alert-generator.service.ts
├── repository/
├── dto/
├── entities/
├── interfaces/
├── enums/
└── utils/
✅ Requirements
Balance Monitoring
Continuously monitor balances for configured wallets.
Track:
- Native token balance
- Token balances (where supported)
- Balance deltas
- Outgoing transfers
- Incoming transfers
- Current portfolio value (if valuation data is available)
The monitoring interval should be configurable.
Asset Draining Detection
Detect rapid balance reductions using configurable thresholds such as:
- Percentage of balance lost
- Absolute asset value transferred
- Number of outgoing transactions
- Number of destination addresses
- Draining within a configurable time window
Example scenarios:
- 90% of wallet balance transferred within 2 minutes
- Multiple high-value transfers in rapid succession
- Assets distributed across many recipient addresses
- Entire wallet emptied after a single approval
Thresholds should be configurable rather than hardcoded.
Velocity Analysis
Analyze transaction behavior to identify abnormal activity.
Metrics may include:
- Transactions per minute
- Assets transferred per minute
- Rate of balance depletion
- Burst transaction detection
- Consecutive outgoing transfers
- Average transfer interval
Higher transaction velocity should contribute to the overall risk score.
Risk Scoring
Assign a severity score based on factors such as:
- Percentage of assets drained
- Monetary value (if available)
- Transaction velocity
- Number of destination addresses
- Wallet importance (if metadata exists)
- Historical wallet behavior
Suggested severity levels:
Severity should increase automatically as additional suspicious activity is observed.
Emergency Alerts
Generate alerts immediately when suspicious draining activity is detected.
Alerts should include:
- Wallet address
- Network
- Time detected
- Current balance
- Estimated assets lost
- Percentage drained
- Number of transactions involved
- Number of recipient addresses
- Severity level
- Detection reason
Alerts should be consumable by existing notification or incident-response modules.
Event Correlation
Correlate related transfers into a single draining incident when appropriate.
Examples:
- Multiple transfers occurring within a short time window
- Sequential transfers from the same wallet
- Transfers triggered from the same transaction sequence
This reduces alert fatigue while providing investigators with a unified view of the incident.
Persistence
Store detected draining events for:
- Incident investigation
- Historical reporting
- Trend analysis
- Audit purposes
Avoid duplicate incident records for the same draining event.
Error Handling
The detection service should:
- Handle temporary blockchain node failures gracefully
- Retry transient network errors
- Continue monitoring unaffected wallets if one wallet fails
- Log monitoring failures for observability
🔒 Non-Functional Requirements
- Configurable monitoring intervals and detection thresholds
- Idempotent event processing
- Efficient balance polling and transaction analysis
- Structured logging for all detections
- Modular detector architecture for future detection rules
- Type-safe DTOs and interfaces
- Unit-testable detection logic
- Scalable to monitor large numbers of wallets concurrently
🎯 Acceptance Criteria
🚨 Detect Rapid Asset Draining Events
Issue: #143
Type: Feature
Priority: Critical
Estimated Effort: 2–3 days
🧠 Concept
Implement a real-time detection module that identifies rapid asset depletion from monitored wallets by continuously analyzing balance changes, outgoing transactions, and transfer velocity.
The detector should distinguish between expected activity and potentially malicious draining behavior, generating high-priority alerts when wallets experience sudden or abnormal loss of assets.
This feature serves as an early warning system for wallet compromises, private key theft, malicious contract interactions, or unauthorized fund movements.
Compromised wallets are often emptied within seconds or minutes after an attacker gains access. Traditional monitoring based solely on transaction volume or periodic balance checks may detect the incident too late.
Common attack scenarios include:
Without rapid asset-draining detection:
📁 Implementation Scope
Suggested structure:
✅ Requirements
Balance Monitoring
Continuously monitor balances for configured wallets.
Track:
The monitoring interval should be configurable.
Asset Draining Detection
Detect rapid balance reductions using configurable thresholds such as:
Example scenarios:
Thresholds should be configurable rather than hardcoded.
Velocity Analysis
Analyze transaction behavior to identify abnormal activity.
Metrics may include:
Higher transaction velocity should contribute to the overall risk score.
Risk Scoring
Assign a severity score based on factors such as:
Suggested severity levels:
Severity should increase automatically as additional suspicious activity is observed.
Emergency Alerts
Generate alerts immediately when suspicious draining activity is detected.
Alerts should include:
Alerts should be consumable by existing notification or incident-response modules.
Event Correlation
Correlate related transfers into a single draining incident when appropriate.
Examples:
This reduces alert fatigue while providing investigators with a unified view of the incident.
Persistence
Store detected draining events for:
Avoid duplicate incident records for the same draining event.
Error Handling
The detection service should:
🔒 Non-Functional Requirements
🎯 Acceptance Criteria