Use this file to discover all available pages before exploring further.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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, SwapCurrent Function Categories:Transfer, Approval, Swap, Liquidity, Lending, FlashLoan, Multicall, Mint, Burn, Claim
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.
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.
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.
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.
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.
