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.

​
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.logs.any(event_name == "Transfer" and to == "0x0000000000000000000000000000000000000000000000000000000000000000")
  output: >
    Token burn detected: %tx.logs.count(event_name == "Transfer" and to == "0x0000000000000000000000000000000000000000000000000000000000000000") transfers to zero address in tx %tx.hash (contract=%tx.logs.matched.contract from=%tx.logs.matched.from amount=%tx.logs.matched.amount)
  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.logs.any(event_name == "Transfer" and to == "...") - Checks if any Transfer event in the transaction goes to the zero address
  • Uses the padded zero address format (66 characters with 0x prefix) as required by EVM
  • The event_name == "Transfer" filter ensures we only check Transfer events, and the automatic parsing provides the to field
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.logs.any(event_name == "Approval" and amount == "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff")
  output: >
    Unlimited approval detected in tx %tx.hash: spender %tx.logs.matched.spender can access all tokens from owner %tx.logs.matched.owner (contract=%tx.logs.matched.contract)
  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.logs.any(event_name == "Approval" and amount == "...") - Checks if any Approval event in the transaction uses the max uint256 value
  • The hex value 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff is the max uint256 value
  • The event_name == "Approval" filter ensures we only check Approval events, and the automatic parsing provides the amount field
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.

​
Function and Event Category Detection

​
Any Transfer Function Call

Detect when any transfer-related function is called (transfer, transferFrom, safeTransferFrom, etc.). 
- rule: Transfer Function Call
  desc: Detects any transfer function call
  tags: ["function", "transfer", "monitoring"]
  condition: tx.function_category == "Transfer"
  output: >
    Transfer function called: %tx.function_name (selector=%tx.function_selector from=%tx.from to=%tx.to tx=%tx.hash)
  priority: NOTICE
  enabled: true
What it does: Detects when any function in the Transfer category is called, including transfer, transferFrom, safeTransferFrom, etc. This is broader than detecting a specific function. Why these fields:
  • tx.function_category == "Transfer" - Detects any transfer-related function call
  • Uses category instead of specific function name for broader coverage
What to expect: Alerts for all transfer function calls, regardless of the specific variant. Useful for monitoring all token transfer activity. False positives: Low false positive rate - only triggers for actual transfer function calls. However, this will generate many alerts for legitimate transfers, so consider combining with other conditions (e.g., high value, specific addresses) to reduce noise.

​
Any Swap Function Call

Detect when any swap-related function is called (all Uniswap variants). 
- rule: Swap Function Call
  desc: Detects any swap function call
  tags: ["defi", "swap", "dex"]
  condition: tx.function_category == "Swap"
  output: >
    Swap function called: %tx.function_name (selector=%tx.function_selector from=%tx.from tx=%tx.hash)
  priority: NOTICE
  enabled: true
What it does: Detects when any swap function is called, including all Uniswap V2 and V3 swap variants. Why these fields:
  • tx.function_category == "Swap" - Detects any swap-related function call
  • Automatically includes all swap variants (swapExactETHForTokens, exactInputSingle, etc.)
What to expect: Alerts for all DEX swap operations, useful for monitoring trading activity. False positives: Low false positive rate - only triggers for actual swap function calls. However, this will generate many alerts for legitimate swaps.

​
Any Transfer Event (Category)

Detect when any Transfer category event is emitted. 
- rule: Transfer Event (Category)
  desc: Detects any Transfer category event
  tags: ["events", "transfer", "monitoring"]
  condition: tx.logs.any(event_category == "Transfer")
  output: >
    Transfer event detected: %tx.logs.matched.event_name (category=%tx.logs.matched.event_category contract=%tx.logs.matched.contract from=%tx.logs.matched.from to=%tx.logs.matched.to tx=%tx.hash)
  priority: NOTICE
  enabled: true
What it does: Detects when any Transfer category event is emitted. Currently includes Transfer events, but will automatically include new transfer-related events as they’re added to the database. Why these fields:
  • tx.logs.any(event_category == "Transfer") - Detects any Transfer category event
  • Uses category for broader detection that automatically includes new event variants
What to expect: Alerts for all Transfer events, useful for comprehensive transfer monitoring. False positives: Low false positive rate - only triggers for actual Transfer events.

​
Any Approval Event (Category)

Detect when any Approval category event is emitted (includes both Approval and ApprovalForAll). 
- rule: Approval Event (Category)
  desc: Detects any Approval category event
  tags: ["events", "approval", "security"]
  condition: tx.logs.any(event_category == "Approval")
  output: >
    Approval event detected: %tx.logs.matched.event_name (category=%tx.logs.matched.event_category contract=%tx.logs.matched.contract owner=%tx.logs.matched.owner spender=%tx.logs.matched.spender tx=%tx.hash)
  priority: WARNING
  enabled: true
What it does: Detects when any Approval category event is emitted, including both Approval and ApprovalForAll events. Why these fields:
  • tx.logs.any(event_category == "Approval") - Detects any Approval category event
  • Automatically includes both Approval and ApprovalForAll without needing separate conditions
What to expect: Alerts for all approval-related events, useful for comprehensive approval monitoring. False positives: Medium false positive rate - legitimate approvals will trigger this rule. Consider combining with other conditions (e.g., unlimited approvals, known malicious spenders) to reduce false positives.

​
Any Swap Event (Category)

Detect when any Swap category event is emitted (Uniswap V2/V3 swaps). 
- rule: Swap Event (Category)
  desc: Detects any Swap category event
  tags: ["events", "swap", "defi"]
  condition: tx.logs.any(event_category == "Swap")
  output: >
    Swap event detected: %tx.logs.matched.event_name (category=%tx.logs.matched.event_category contract=%tx.logs.matched.address tx=%tx.hash)
  priority: NOTICE
  enabled: true
What it does: Detects when any Swap category event is emitted, including Uniswap V2 and V3 swap events. Why these fields:
  • tx.logs.any(event_category == "Swap") - Detects any Swap category event
  • Automatically includes both Uniswap V2 and V3 swap events without needing separate conditions
What to expect: Alerts for all DEX swap events, useful for monitoring trading activity and DeFi interactions. False positives: Low false positive rate - only triggers for actual Swap events. However, this will generate many alerts for legitimate swaps.
Note on Function vs Event Categories: Function categories (tx.function_category) and event categories (tx.logs.any(event_category == ...)) are designed to be consistent where possible. However, not all function categories have corresponding event categories because:
  • Functions represent what was called (e.g., swapExactETHForTokens, deposit, mint)
  • Events represent what was emitted (e.g., Swap, Transfer, Approval)
Some function categories like Liquidity, Lending, FlashLoan, Multicall, Mint, Burn, and Claim don’t have direct event equivalents because these operations often emit standard events like Transfer or protocol-specific events that vary by implementation.Current Event Categories: Transfer, Approval, Swap Current Function Categories: Transfer, Approval, Swap, Liquidity, Lending, FlashLoan, Multicall, Mint, Burn, Claim

​
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