eth_getLogs - Berachain

The eth_getLogs method is an Berachain JSON-RPC method that allows developers to query logs generated by the Berachain network, specifically event logs emitted by smart contracts. These logs are an essential part of the Berachain ecosystem as they provide a way for developers to monitor contract events and track contract state changes.

This method is particularly useful when building decentralized applications (dApps) that rely on events emitted by smart contracts, as it enables developers to retrieve logs based on specific filter criteria. By using eth_getLogs, developers can efficiently track and react to events happening on the Berachain blockchain.

Body Params
integer
Defaults to 1
string
Defaults to 2.0
string
Defaults to eth_getLogs
params
array of objects
length between 1 and 1
params
string

Using blockHash is equivalent to fromBlock = toBlock = the block number with hash blockHash. If blockHash is present in the filter criteria, then neither fromBlock nor toBlock are allowed.

address
array of strings
Defaults to 0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907

Contract address or a list of addresses from which logs should originate.

address
string
Defaults to 0x429d3b

String - Either the hex value of a block number OR block tags:

  1. block number (in hex) OR
  2. block tag (one of the following): * pending (Not available on Ethereum) - A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. * latest - The most recent block in the canonical chain observed by the client, this block may be re-orged out of the canonical chain even under healthy/normal conditions. * safe - The most recent crypto-economically secure block, cannot be re-orged outside of manual intervention driven by community coordination. Intuitively, this block is “unlikely” to be re-orged. * finalized - The most recent crypto-economically secure block, that has been accepted by >2/3 of validators. Cannot be re-orged outside of manual intervention driven by community coordination. Intuitively, this block is very unlikely to be re-orged. * earliest - The lowest numbered block the client has available. Intuitively, you can think of this as the first block created.
string
Defaults to latest

String - Either the hex value of a block number OR block tags:

  1. block number (in hex) OR
  2. block tag (one of the following): * pending (Not available on Ethereum) - A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. * latest - The most recent block in the canonical chain observed by the client, this block may be re-orged out of the canonical chain even under healthy/normal conditions. * safe - The most recent crypto-economically secure block, cannot be re-orged outside of manual intervention driven by community coordination. Intuitively, this block is “unlikely” to be re-orged. * finalized - The most recent crypto-economically secure block, that has been accepted by >2/3 of validators. Cannot be re-orged outside of manual intervention driven by community coordination. Intuitively, this block is very unlikely to be re-orged. * earliest - The lowest numbered block the client has available. Intuitively, you can think of this as the first block created.
topics
array of strings
Defaults to 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef,0x00000000000000000000000000b46c2526e227482e2ebb8f4c69e4674d262e75,0x00000000000000000000000054a2d42a40f51259dedd1978f6c118a0f0eff078

Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.

topics
Response

Language
Credentials
Header
URL
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json