Home/Blockchain/Event Logs Explorer/Indexed Parameters

🔖 Indexed Parameters: Searchable Event Data

Learn why indexed parameters make blockchain queries faster

Your Progress

0 / 5 completed
1
2
3
4
5
←
Previous Section
Event Anatomy

🏷️ The Power of Indexed Parameters

Indexed parameters are the secret to efficient event filtering. They transform slow, expensive full-blockchain scans into lightning-fast queries using Bloom filters and topic indexing.

🎯 Interactive: Filter Performance Simulator

See how indexed parameters dramatically improve query speed:

No Filters

HIGH COST

Query all Transfer events (expensive)

~8 events scanned
0xAlice→0xBob
100 @ Block 1000
0xAlice→0xCharlie
50 @ Block 1001
0xBob→0xAlice
25 @ Block 1002
0xCharlie→0xBob
75 @ Block 1003
0xAlice→0xDave
200 @ Block 1004
0xDave→0xAlice
150 @ Block 1005
0xBob→0xCharlie
30 @ Block 1006
0xCharlie→0xAlice
60 @ Block 1007
Performance Analysis:

⚠️ Scans ALL events. Use indexed filters for better performance!

How Indexed Parameters Work

🌸Bloom Filters

Ethereum uses Bloom filters in block headers to quickly check if a block contains events matching specific topics—without scanning every transaction.

Block Header → Bloom Filter → "Does this block contain Transfer from 0xAlice?"
→ If YES: Scan transactions
→ If NO: Skip entire block instantly

🎯Topic Indexing

Each indexed parameter becomes a searchable topic. Nodes maintain indexes for efficient lookups.

Topic 1
from address
Topic 2
to address
Data
amount (not indexed)

⚡Query Speed Impact

No filters:
Scan millions of events
1 indexed:
~50% reduction
2 indexed:
~80% reduction
3 indexed:
~90% reduction

Best Practices for Indexed Parameters

✅
DO Index These
  • • Addresses (from, to, owner, spender)
  • • Token IDs, NFT IDs
  • • Order IDs, transaction IDs
  • • Enum values, status codes
  • • Bool flags (active, paused)
❌
DON'T Index These
  • • Large numbers rarely filtered
  • • Strings (indexed = hash only)
  • • Arrays (cannot be indexed)
  • • Structs (cannot be indexed)
  • • Data you'll never query by

Code Examples

✅ Good: Strategic Indexing

event OrderCreated(
  uint256 indexed orderId,     // ✓ Will filter by ID
  address indexed buyer,       // ✓ Will filter by buyer
  address indexed seller,      // ✓ Will filter by seller
  uint256 amount,             // Data: rarely filtered
  string metadata             // Data: cannot index strings
);

event NFTTransfer(
  address indexed from,        // ✓ Filter sender
  address indexed to,          // ✓ Filter receiver
  uint256 indexed tokenId,     // ✓ Filter specific NFT
  string tokenURI             // Data: metadata
);

❌ Bad: Wasting Indexed Slots

event OrderCreated(
  uint256 indexed timestamp,   // ✗ Rarely filter by exact timestamp
  uint256 indexed amount,      // ✗ Filter by range, not exact value
  uint256 indexed randomId,    // ✗ Never filter by random value
  address buyer,              // ✗ Should be indexed!
  address seller              // ✗ Should be indexed!
);

// Better: Index addresses, not numbers
event OrderCreated(
  address indexed buyer,
  address indexed seller,
  uint256 indexed orderId,
  uint256 amount,
  uint256 timestamp
);

💡 The 3-Index Limit

Solidity allows maximum 3 indexed parameters per event. This is an EVM limitation due to:

  • •Topic 0: Reserved for event signature hash
  • •Topics 1-3: Available for indexed parameters
  • •4 topics total: Each 32 bytes in Bloom filter
  • •Balance: More indexes = better filtering but higher gas cost