eth_getLogs | Aurora

Aurora API method that returns an array of all logs that match a given filter object. Logs are records of smart contract-generated events on the network and contain valuable information about transactions and smart contract interactions.

👍

Get you own node endpoint today

Start for free and get your app to production levels immediately. No credit card required.

You can sign up with your GitHub, X, Google, or Microsoft account.

Some common use cases for eth_getLogs include monitoring smart contract events, tracking token transfers, and analyzing blockchain data.

Parameters

• object — the filter parameters:
  • fromBlock — (optional, default: latest) integer that specifies the starting block number from which the logs should be fetched.
  • toBlock — (optional, default: latest) integer that specifies the ending block number until which the logs should be fetched.
  • address — (optional) the contract address from which the logs should be fetched. It can be a single address or an array of addresses.
  • topics — (optional) an array of DATA topics. The event topics for which the logs should be fetched. It can be a single topic or an array of topics.
  • blockhash — (optional) the hash of the specific block. Limits logs to a specific block with a 32-byte hash value. It takes precedence over fromBlock and toBlock.

📘

Possible tags for fromBlock and toBlock

• latest — the most recent block in the blockchain and the current state of the blockchain at the most recent block.
• safe — the block that received justification from the beacon chain. Although this block could be involved in a chain reorganization, it would necessitate either a coordinated attack by the majority of validators or an instance of severe propagation latency.
• finalized — the block accepted as canonical by more than 2/3 of the validators. A chain reorganization is extremely unlikely, and it would require at least 1/3 of the staked ETH to be burned.
• earliest — the earliest available or genesis block.
• pending — the pending state and transactions block. The current state of transactions that have been broadcast to the network but have not yet been included in a block.

See the default block parameter and How The Merge Impacts Ethereum’s Application Layer.

Response

• array — an array of log objects that match the specified filter or an empty array if there have been no new events since the last poll:
  • address — the contract address from which the event originated
  • topics — an array of 32-byte data fields containing indexed event parameters
  • data — the non-indexed data that was emitted along with the event
  • blocknumber — the block number in which the event was included. null if it is pending.
  • transactionhash — the hash of the transaction that triggered the event. null if pending.
  • transactionindex — the integer index of the transaction within the block's list of transactions. null if it is pending.
  • blockhash — the hash of the block in which the event was included. null if it is pending.
  • logindex — the integer identifying the event index within the block's list of events. null if pending.
  • removed — the boolean value indicating if the event was removed from the blockchain due to a chain reorganization. True if the log was removed. False if it is a valid log.

eth_getLogs code examples

The following examples retrieve the logs of the Transfer event from the WETH token smart contract on Aurora.

const { Web3 } = require("web3");
const NODE_URL = "CHAINSTACK_NODE_URL";
const web3 = new Web3(NODE_URL);

async function getLogs() {
  const latestBlock = await web3.eth.getBlockNumber();

  const filter = {
    fromBlock: latestBlock - 100n,
    toBlock: 'latest',
    address: '0xC9BdeEd33CD01541e1eeD10f90519d2C06Fe3feB',
    topics: ['0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef']
  };
  const logs = await web3.eth.getPastLogs(filter);
  console.log(logs);
}

getLogs();

const ethers = require('ethers');
const NODE_URL = "CHAINSTACK_NODE_URL";
const provider = new ethers.JsonRpcProvider(NODE_URL);

const getLogs = async () => {
    const latestBlock = await provider.getBlockNumber();
    const filter = {
      fromBlock: latestBlock - 10,
      toBlock: 'latest',
      address: '0xC9BdeEd33CD01541e1eeD10f90519d2C06Fe3feB',
      topics: ['0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef']
    };
    const logs = await provider.getLogs(filter);
    console.log(logs);
  };
  
getLogs();

from web3 import Web3  
node_url = "CHAINSTACK_NODE_URL" 
web3 = Web3(Web3.HTTPProvider(node_url))

latest_block = web3.eth.block_number

filter = {
    'fromBlock': latest_block - 10,
    'toBlock': 'latest',
    'address': '0xC9BdeEd33CD01541e1eeD10f90519d2C06Fe3feB',
    'topics': ['0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef']
}

logs = web3.eth.get_logs(filter)
print(logs)

📘

Read Tracking some Bored Apes: The Ethereum event logs tutorial to learn more about the eth_getLogs method.

Block range limitations

While eth_getLogs is a powerful tool, it's crucial to understand its limitations, particularly when working with different EVM-compatible chains, as these networks often have different constraints. The eth_getLogs method allows you to select a range of blocks from which to get events and is important for exercising proper management.

In general, eth_getLogs is a very resource-intensive method, and although Chainstack does not pose any arbitrary limitation, some blockchain clients do, and a very large block range can impact your node's performance.

We recommend to keep the block range limit of 10,000 blocks for eth_getLogs on Aurora to maintain a good balance between node and application performance.

📘

These figures mean that the difference between the fromBlock and toBlock parameters should not exceed the given block range when querying logs.

These limitations are particularly important when working with popular smart contracts on busy blockchains, as they can return a large amount of data, read Understanding eth_getLogs limitations to learn more about eth_getLogs limits.

Use case

One use case for eth_getLogs is to retrieve the transfer events for a specific Token ID from an ERC-721 smart contract. ERC-721 is a token standard for non-fungible tokens (NFTs), and each token transfer is recorded as an event on the blockchain. By retrieving these events, developers can track the movement of NFTs and build applications that interact with them.

Try the eth_getLogs RPC method yourself