Skip to main content
This page provides realistic, production-ready detection rules that demonstrate what Blocklight can actually detect. Each example follows the recommended field order and includes explanations of what it does, why those fields are chosen, what to expect, and the potential for false positives.
File Structure: In examples that use lists or macros, notice they are defined outside of rules (at the file level) before the rules that use them. This allows them to be reused by multiple rules in the same file. See Lists & Macros for details.

​
High-Value Transfers

​
Large ETH Transfer

Detect transfers of significant amounts of native tokens (ETH, RBTC, etc.). 
- rule: Large ETH Transfer
  desc: Detects transfers of large amounts of ETH (>100 ETH)
  tags: ["monitoring", "high-value", "transfer"]
  condition: >
    tx.value > 100 ether and
    tx.to != null
  output: >
    Large ETH transfer detected: %tx.value_eth ETH from %tx.from to %tx.to (tx: %tx.hash)
  priority: WARNING
  enabled: true
What it does: Monitors transactions with native token values exceeding 100 ETH (or equivalent on other chains). This is a straightforward value check against the transaction’s value field. Why these fields:
  • tx.value > 100 ether - Direct comparison of transaction value in native token units
  • tx.to != null - Excludes contract deployments (which have null recipient)
What to expect: You’ll get alerts for legitimate large transfers, whale movements, and potentially suspicious high-value transactions. This is useful for operational awareness and compliance tracking. False positives: This will generate alerts for all large transfers, including legitimate ones. Adjust the threshold (100 ether) based on your monitoring needs. For high-volume chains, consider using aggregation to reduce alert frequency.

​
Very Large ETH Transfer

Detect extremely large transfers that may indicate significant events. 
- rule: Very Large ETH Transfer
  desc: Detects transfers of very large amounts of ETH (>1000 ETH)
  tags: ["monitoring", "high-value", "transfer", "critical"]
  condition: >
    tx.value > 1000 ether and
    tx.to != null
  output: >
    CRITICAL: Very large ETH transfer detected: %tx.value_eth ETH from %tx.from to %tx.to (tx: %tx.hash)
  priority: CRITICAL
  enabled: true
What it does: Identifies transactions with extremely high native token values (1000+ ETH). This is a higher threshold version of the large transfer rule. Why these fields:
  • tx.value > 1000 ether - Very high threshold to catch only exceptional transfers
  • tx.to != null - Ensures it’s a transfer, not a contract deployment
What to expect: Much fewer alerts than the 100 ETH threshold. These are typically significant events worth immediate attention. False positives: Very low false positive rate - only triggers for exceptional transfers. However, legitimate whale movements will still trigger this rule, which may be considered false positives depending on your use case.

​
Token Operations

​
Token Burn Detection

Detect when tokens are sent to the zero address (burn address). 
- rule: Token Burn Detected
  desc: Detect token burn to zero address
  tags: ["defi", "token", "burn"]
  condition: >
    tx.transfers.any(to == "0x0000000000000000000000000000000000000000000000000000000000000000")
  output: >
    Token burn detected: %tx.transfers.count(to == "0x0000000000000000000000000000000000000000000000000000000000000000") transfers to zero address in tx %tx.hash
  priority: WARNING
  enabled: true
What it does: Identifies ERC-20 Transfer events where tokens are sent to the zero address (0x0000...0000), which is the standard way to burn tokens on EVM chains. Why these fields:
  • tx.transfers.any(to == "...") - Checks if any transfer in the transaction goes to the zero address
  • Uses the padded zero address format (66 characters with 0x prefix) as required by EVM
What to expect: Alerts for legitimate token burns (common in DeFi for deflationary mechanisms) and any transfers to the burn address. This is a factual detection with no interpretation. False positives: Low false positive rate - only triggers when there’s an actual transfer to the zero address. However, many protocols use token burns legitimately, so you’ll see both legitimate and potentially suspicious burns. Whether legitimate burns are “false positives” depends on your monitoring goals.

​
Unlimited Token Approval

Detect when a user approves the maximum possible amount (type(uint256).max) to a spender. 
- rule: Unlimited Token Approval
  desc: Detect unlimited token approval (max uint256)
  tags: ["security", "approval", "phishing"]
  condition: >
    tx.approvals.any(amount == "115792089237316195423570985008687907853269984665640564039457584007913129639935")
  output: >
    Unlimited approval detected in tx %tx.hash: spender can access all tokens
  priority: CRITICAL
  enabled: true
What it does: Detects ERC-20 Approval events where the approval amount equals the maximum uint256 value (2^256 - 1), which effectively gives unlimited spending access to the spender. Why these fields:
  • tx.approvals.any(amount == "...") - Checks if any approval in the transaction uses the max uint256 value
  • The exact string value is required (this is the decimal representation of type(uint256).max)
What to expect: Alerts for unlimited approvals, which are often used in phishing attacks but can also be legitimate (some DEXs recommend unlimited approvals for gas efficiency). This is a factual detection - the approval amount is either max or it’s not. False positives: Medium false positive rate - legitimate DEX interactions often use unlimited approvals for gas efficiency. These are technically correct detections but may not be security-relevant depending on your context. Consider combining with other signals (e.g., known malicious addresses) to reduce false positives.

​
Watchlist-Based Detection

​
Known Attacker Activity

Monitor transactions from addresses on your threat intelligence watchlist. 
- list: known_attackers
  items:
    - "0x1234567890123456789012345678901234567890"
    - "0x0987654321098765432109876543210987654321"

- rule: Known Attacker Activity
  desc: Transaction from known attacker address
  tags: ["security", "watchlist", "attacker"]
  condition: >
    tx.from in (known_attackers)
  output: >
    Known attacker activity detected: %tx.from sent %tx.value_eth ETH in tx %tx.hash
  priority: CRITICAL
  enabled: true
What it does: Monitors transactions originating from addresses in your threat intelligence watchlist. This is a simple address matching rule. Why these fields:
  • tx.from in (known_attackers) - Checks if the transaction sender is in your watchlist
  • Uses a list component to maintain your threat intelligence addresses
What to expect: Alerts whenever a known attacker address sends a transaction. This is 100% accurate - if the address is in your list and sends a transaction, you’ll get an alert. False positives: Low false positive rate - this only triggers for addresses you’ve explicitly added to your watchlist. However, false positives can occur if your watchlist contains outdated addresses, incorrectly flagged addresses, or addresses that have been cleared of wrongdoing. You must maintain an accurate, up-to-date watchlist.

​
Sanctioned Address Interaction

Detect transactions involving OFAC-sanctioned or other compliance-monitored addresses. 
- list: sanctioned_addresses
  items:
    - "0xabcdefabcdefabcdefabcdefabcdefabcdefabcd"

- rule: Sanctioned Address Interaction
  desc: Interaction with sanctioned address
  tags: ["compliance", "sanctions", "security"]
  condition: >
    tx.from in (sanctioned_addresses) or 
    tx.to in (sanctioned_addresses)
  output: >
    Sanctioned address interaction: from=%tx.from, to=%tx.to, value=%tx.value_eth ETH (tx: %tx.hash)
  priority: CRITICAL
  enabled: true
What it does: Detects transactions where either the sender or recipient is a sanctioned address (e.g., OFAC SDN list). Monitors both incoming and outgoing transactions. Why these fields:
  • tx.from in (sanctioned_addresses) - Checks if sender is sanctioned
  • tx.to in (sanctioned_addresses) - Checks if recipient is sanctioned
  • Uses or to catch both directions of interaction
What to expect: Alerts for any transaction involving sanctioned addresses, which is critical for compliance monitoring. False positives: Low false positive rate for address matching - if an address is sanctioned and appears in a transaction, you’ll get an alert. However, false positives can occur if your sanctions list contains addresses that are no longer sanctioned, were incorrectly added, or if legitimate transactions involve sanctioned addresses for non-prohibited purposes. You must maintain an accurate, up-to-date sanctions list.

​
Operational Monitoring

​
Zero Value Transaction with High Gas

Detect contract interactions (zero value) that consume significant gas, which may indicate complex operations or potential attacks. 
- rule: Zero Value with High Gas
  desc: Detects zero-value transactions with high gas (complex contract interactions)
  tags: ["monitoring", "gas", "contract-interaction"]
  condition: >
    tx.value == 0 and
    tx.gas_used > 1000000
  output: >
    Zero value transaction with high gas: %tx.gas_used gas used in tx %tx.hash (to: %tx.to)
  priority: NOTICE
  enabled: true
What it does: Identifies contract interactions (zero native token value) that consume more than 1 million gas, indicating complex operations. Why these fields:
  • tx.value == 0 - Ensures it’s a contract interaction, not a transfer
  • tx.gas_used > 1000000 - High gas threshold indicates complex operations
  • Requires receipt data (so analysis.transaction.fetch_receipt must be enabled)
What to expect: Alerts for complex contract interactions, which could be legitimate (complex DeFi operations) or suspicious (potential attacks, spam). This is useful for operational awareness. False positives: Medium to high false positive rate - many legitimate DeFi operations consume high gas. This rule is better for operational monitoring than security detection. Consider using it with aggregation to reduce alert frequency.

​
High Gas Price Transaction

Detect transactions with abnormally high gas prices, which may indicate time-sensitive operations or MEV activity. 
- rule: High Gas Price Transaction
  desc: Detects transactions with very high gas prices
  tags: ["monitoring", "gas", "mev"]
  condition: >
    tx.gas_price > 500 gwei
  output: >
    High gas price transaction: %tx.gas_price_gwei gwei in tx %tx.hash (from: %tx.from)
  priority: NOTICE
  enabled: true
What it does: Monitors transactions with gas prices exceeding 500 gwei, which is significantly above normal market rates. Why these fields:
  • tx.gas_price > 500 gwei - Direct comparison of gas price (converted from wei to gwei for readability)
  • Gas price is available in the transaction data
What to expect: Alerts for transactions paying premium gas prices, which could indicate urgent operations, MEV activity, or time-sensitive attacks. False positives: Medium false positive rate - legitimate users sometimes pay high gas prices during network congestion or for urgent transactions. MEV bots also regularly use high gas prices. These are correct detections but may not be security-relevant. Adjust the threshold (500 gwei) based on your chain’s typical gas prices.

​
Contract Deployment Monitoring

​
Large Contract Deployment

Monitor new contract deployments that consume significant gas, indicating complex contracts. 
- rule: Large Contract Deployment
  desc: Monitor large contract deployments
  tags: ["monitoring", "deployment"]
  condition: >
    tx.to == null and 
    tx.gas_used > 2000000 and 
    tx.status == 1
  output: >
    Large contract deployed: %tx.gas_used gas used in tx %tx.hash (from: %tx.from)
  priority: NOTICE
  enabled: true
What it does: Identifies contract deployments (transactions with null recipient) that consume more than 2 million gas, indicating large or complex contracts. Why these fields:
  • tx.to == null - Identifies contract deployments (no recipient address)
  • tx.gas_used > 2000000 - High gas threshold for large contracts
  • tx.status == 1 - Only successful deployments (failed deployments are less interesting)
What to expect: Alerts for large contract deployments, which could be legitimate protocol deployments or potentially malicious contracts. False positives: Low to medium false positive rate - large contract deployments are relatively rare. However, legitimate protocol upgrades will trigger this rule. This is useful for operational awareness rather than security detection.

​
Next Steps

Fields

Learn about transaction fields and simple conditions

Array Methods

Master .any() and .count() for complex filtering

Structure

Learn about rule structure and field order

Test Rules

Test these rules with blocklight dry-run