Mempool Explorer
Mempool Explorer™ lets you go hands-on with real-time mempool data. Watch addresses, filter and select events, and determine what data you want to build with.
This documentation describes how to use Blocknative’s Mempool Explorer. Mempool Explorer enables you to create data feeds for the addresses (wallet or contract) that you care about. Add filters and push your feed into a webhook that you can start building with.
- 1.
- 2.Create a subscription by filling out the Create Subscription card. Enter a valid Ethereum address, an ENS name, or select a quick start.
Enter an address or select a quick start
3. Select the network you want to monitor for the subscribed address
Network selector
Network select dropdown
4. Click Create and Mempool Explorer will subscribe to all transactions that involve that address. You will see events appear on the panel on the right as new transactions occur:
Sample event
Once you have a subscription created, you can rename it, add an ABI to decode
input data or delete it via the subscription menu. To display the menu, click the ellipsis in the top right corner.
Open the subscription menu
Rename the subscription
A Configuration is a set of Mempool Explorer subscriptions for a specific network. You can choose to save a configuration to an API key or load one from an API key. Note that each API key can support one subscription for each supported network. To be able to save and load configurations, you will need to log in to your Blocknative account.
- 1.Create a Blocknative account by clicking the Login button on Mempool Explorer and following the instructions. Account creation requires email confirmation to complete.
- 2.Blocknative will create a Default API key for your account that you can save your configuration to. You can create additional API keys from your account dashboard on https://explorer.blocknative.com or from the Create New API Key in the Save configuration flow.
Once you have an account, you can login to Mempool Explorer by clicking the Login button at the top right. This will activate your Configurations Sidebar to display your Configurations and any you build and save. You can also open or close the Configurations Sidebar using the hamburger menu icon at the top left of your screen.
Sample saved configurations sidebar
You can create a new configuration using the + New Configuration button at the bottom of the Sidebar:
New Configuration button
This will give you the option to either create a Blank configuration or Load an existing one from an API Key.
Once you make the desired changes to the new configuration (such as adding subscriptions or filters), you can use the Save button to save your new configuration.
Active Save button and Reset button
An "Unsaved Changes" warning may pop to remind you that you have made changes to the configuration that you may want to save. The Save button will also become Active once there are changes that can be saved, and a Reset button will appear next to it to bring the Configuration back to its original state. Note that this will remove any unsaved changes.
Unsaved changes warning which will briefly appear
Clicking Save will display the API Key Picker modal where you can select the API key of your choosing. If you have an existing configuration saved to this key, Mempool Explorer will ask if you want to overwrite the selected key to save the new configuration. You can also create a new API key conveniently from the API Key picker modal, but please refer to your Account Page for greater flexibility in managing your API keys.
Saving to an API Key with the option to Create a new one
Once a configuration is saved to your key, it will be applied to any webhooks that you have saved to that key/blockchain/network combination and will produce the same feed that you see within Mempool Explorer.
You can load a configuration by simply clicking on it from the Sidebar. If you have Unsaved Changes in your current configuration, Mempool Explorer will remind you to save it before loading a new one. For new configurations that aren't saved, you can freely switch back and forth without losing your changes. New configurations that aren't saved will have an unsaved icon next to them:
Sample configurations with Unsaved indicator
You can conveniently add a webhook to your API key from your configurations sidebar. You will get a three-dot menu option once you hover over a configuration:
Configuration options
Note that this will add the webhook to the API key associated with that configuration, which will apply to other configurations saved to that API key on different networks. Clicking the Add Webhook option will prompt the webhook creation modal and allow you to enter your webhook details to add it:
Webhook creation modal
Once you add the webhook, a success message will appear on the corner of your screen and a Webhook icon will appear next to the configuration on your Sidebar:
A configuration with an attached webhook
You can use your Mempool Explorer configuration to apply filters to Blocknative SDK. To do this, you can use the Export Configuration option in the three-dot menu next to your configuration to download the configuration files, and then use them to send a configuration to Blocknative SDK. You can read more on this feature on the SDK docs.
Export configuration modal
See how to get started with Mempool Explorer in this screencast:
Introductory Walk Through of Mempool Explorer
Add local ABI to interpret and filter transaction data in this screencast:
Custom ABIs with Mempool Explorer
Compose subscriptions for external services with webhooks in this screencast:
Compose with Webhooks in Mempool Explorer
Once a subscription has been created, Mempool Explorer will display a notification for every transaction involving that address. You may want to limit displayed notifications to transactions that fit a particular criteria - to do this you can create filters.
Click the Global Filter button to start creating a Filter that will apply to all subscriptions within a specific configuration. Global Filters will contain selectable properties that apply to all subscription events. To filter on a property that only exists on a particular contract address, use a local filter for that subscription.
You will see the filter form modal appear:
Global filter form
You can then select the properties that you would like to create a comparison for any new notifications to pass before being displayed:
Filter selection schema 🧗
The type of comparisons available depends on the parameter that is selected. The following is a complete list of the comparisons that can be made:
Used to check that a property value is not
undefined (that is to say is defined).Used to match string values and tests for an exact match.
Used to match string values that are not the value that has been inputted.
Used to select a list of possible string values, where if there is a match on any one of them then the comparison has passed.
equalsCheck that two number values are equal
Used to compare numerical values against an inputted value
Used to compare numerical values against an inputted value
Used to compare numerical values against an inputted value
Used to compare numerical values against an inputted value
Once you are happy with your filter comparison, click the "Add" button.
Blocknative transaction notifications contain a lot of data. If you would like to reduce the amount of data delivered to only key information, then you can Select the applicable information you need to see just that!
Click the Global Select button to start filling a Select Form and you will see it appear within a modal. Global Select affects all of your subscriptions within the applicable configuration.
Global select form
You can then select the properties that you would like to be included in the notification:
Selecting properties to be displayed in the event payload
Once you have settled on a property that you want to include in the notification, click the "add" button which will add it to your Select list.
By default, all properties are selected with each notification. As soon as you select any specific property/properties, the notification will start displaying only the properties selected.
You can Filter and Select globally for all of your subscriptions within a configuration or locally for each specific subscription. This allows for ease of use in how you modify displayed events.
A Global Filter or Select applies to all subscriptions within that configuration and is located at the top of your subscriptions:
Global controls at the top
A local Filter or Select applies only to the subscription they are added to and are located on the specific subscription card:
Subscription filters and selectors at the bottom of the card
A Global Filter/Select applies to all transactions/addresses watched within a configuration. Therefore a Global Filter only supports generic transaction fields.
A Local Filter/Select applies to a specific address and can include fields, such as
methodNamethat are specific to the contract at that address. Local Filters/Selects can use fields defined in the contract ABI (if supported or uploaded in the subscription field).If you are creating a subscription for a contract address, you can upload the ABI for that contract and Mempool Explorer will automatically decode the input data for any contract calls.
You can upload a
.json file of the ABI by clicking the ABI button on the subscription card:
The ABI button located on the subscription card (Neutral State)
The ABI button has four (4) total states:
- Neutral, indicating no ABI is detected.
- Green, indicating a working ABI has been detected or uploaded and contract events are being decoded successfully.
- Yellow, indicating the ABI uploaded may be incorrect for that contract address. This status is shown after 10 or more events have failed to decode successfully.
- Red, indicating the uploaded ABI is an invalid object.
Sample ABI State (Red)
If the uploaded ABI for the contract is invalid, Mempool Explorer will change the ABI indicator to Yellow and send a notification indicating the ABI provided has failed to decode the input after 10 events related to that contract address:
Sample Invalid ABI Notification
Blocknative backend infrastructure automatically decodes contract input data for common ERC20 and ERC721 tokens and other popular contracts, so there is no need to upload an ABI for these contract types. For a full list head to the API Docs.
Mempool Explorer provides a Gas Widget at the top right side of your screen that displays the latest Gas Price derived from Gas Platform's 80% confidence interval. You can enable the toggle to view the Gas Platform payload with greater detail every time it updates. You can learn more about Gas Platform here.
Sample Gas Widget
The Gas Widget defaults to EIP-1559 compatible type2 transaction gas prices. If you're looking for legacy type0 transaction gas prices, simply hover on the widget and you will get a checkbox to revert it to the legacy format.
Legacy Gas Widget format with on-hover option displayed
You can also use the link that appears under the checkbox option to download our Gas Estimator browser extension.
To quickly get a sense of the types of feeds you can build with Mempool Explorer, we’ve created a few samples for you:
Mempool Explorer supports a "Fullscreen mode" that allows your feed area to take over your browser window. This mode allows for closer monitoring of mempool events after you're done setting up your configuration. The configurations sidebar is available in Fullscreen mode for easy switching between different mempool streams you have saved. You can enter and exit Fullscreen mode using the
Fullscreen button on your feed.
Fullscreen button to the right of your feed
Fullscreen mode
Blocknative allows you to easily share the configuration feed you have created. Click on the “Share” button to copy a shortened version of the URL including all of the filters and display options you have selected.
You can also copy the event data in Mempool Explorer using the "Copy" button and easily share that with your team.
Share and Copy buttons to the right of your feed
Blocknative notifications include simulation of pending transactions for Ethereum Mainnet and Goerli Testnet.
These
pending-simulation notifications are delivered automatically unless there is a filter that restricts notification by transaction status. Filters can use pending-simulation status to include or exclude simulation of pending transactions
Filter to Include Simulated Pending Transaction Notifications
Filter to Exclude Simulated Pending Transaction Notifications
Notifications of
pending-simulation transactions appear with a slightly different background color and a badge to remind the user the transaction details are probabilistic, based on speculative execution of the transaction. See our blog post Understanding Ethereum Transaction Simulation — And Why It Matters for details on speculative execution of transactions.
Badge for Notifications of Simulated Pending Transactions
When a subscription starts to receive
pending-simulation notifications, the subscription card will update with the simulation icon to make clear that notification feed includes speculative execution of some transactions.
Subscription Card with Simulated Pending Notifications Delivered
Mempool Explorer uses our API, which has rate limits. Pending Simulation has different rate limits than other notifications. Please see Rate Limits for more details.
Mempool Explorer supports the following Ethereum and EVM compatible networks:
maingoerlixdai(Gnosis Chain)matic-main (Polygon)matic-mumbai
We're working to add support for the Bitcoin Network. If there are any other networks that you would want to see in Mempool Explorer, please feel free get in touch.
Transaction Payload Notifications | Definition |
|---|---|
status | New status of this transaction: cancel / confirmed / dropped / failed / pending / pending sim / speedup / stuck . |
monitorID | Identifier of the Blocknative node client that first detected the transaction state change. |
monitorversion | Version number of the Blocknative monitor that detected the transaction state change. |
timepending (Optional) | The number of milliseconds from initial pending detection to confirmed or failed detection. "-1" if first detection is on-chain. |
blockspending (Optional) | The number of blocks since the initial pending detection to confirmed or failed detection. |
pendingtimestamp | UTC ISO timestamp when Blocknative first detected the pending state for this transaction. |
pendingblocknumber | The chain head block number when the pending state was first detected. |
hash | Hash generated when transaction is submitted. Transaction id hash is unique for every transaction. |
from | sender address |
to | recipient address (wallet or contract generally) |
value | Amount of ETH transferred directly from "from" address (this will contain an amount of specifically ETH for all Ethereum networks main and test nets). |
gas | Maximum number of units of gas that the sender allows for this transaction. For most transactions this parameter will be set by the dapp. |
nonce | The "from" address transaction count associated with that address. |
blockhash | Block id hash for transactions that are on-chain. Field is null unless notification status is confirmed or failed. |
blocknumber | Block number for transactions that are on-chain. Field is null unless notification status is confirmed or failed. |
V | The V/R/S transaction signature can be combined into one 65-byte-long sequence: 32 bytes for r, 32 bytes for s, and one byte for v. Together these can be decoded to verify the original message, address and signature. |
R | transaction signature component (hex encoded) |
S | transaction signature component (hex encoded) |
input | Data sent to transaction. For direct value transfers from one external account to another, this field contains 0x. For contract calls, this value contains the contract method signature and params as a hex string. |
gasused | Gas units used during transaction execution. This will always be less than or equal to "gas". |
type | Denotes the gas pricing used for this transaction, 0 or 2 (0 pre or 2 post 1559 w/ gas structure and limits defined). |
maxfeepergas | user (from) set max gas ceiling in wei |
maxfeepergasgwei | user (from) set max gas ceiling in gwei |
maxpriorityfeepergas | Max priority fee per gas in wei (aka tip). |
maxpriorityfeepergasgwei | Max priority fee per gas in gwei (aka tip). |
basefeepergas | Base fee per gas of this block in wei, dictated by network conditions. |
basefeepergasgwei | Base fee per gas of this block in gwei, dictated by network conditions. |
transactionindex (Optional) | For confirmed or failed transactions, the index (order) of the transaction in the block. |
asset (Optional) | Symbol of the asset being transferred, e.g. ETH. This field is present only if transaction directly transfers Ether or is an ERC20 token transfer. |
blocktimestamp (Optional) | UTC ISO block timestamp the miner reported when collating the block this transaction was eventually mined in. The block timestamp is usually a few seconds before timeStamp, the difference being the time between the miner collating the block, and the block being mined and propagated throughout the network. |
watchedAddress (Optional) | Watched address which triggered the notification. This field is present only if the notification is triggered by watchedAddress. |
direction (Optional) | Indicates if funds are incoming or outgoing relative to the watchedAddress. This field is present only if the notification is triggered by watchedAddress. |
counterparty (Optional) | Address of recipient of funds if watchedAddress is the sender in the transaction, address of sender of funds if watchedAddress is the recipient in the transaction. This field is present only if the notification is triggered by watchedAddress. |
serverversion | Version number of the Blocknative server that delivered the notification. |
eventcode | Every payload contains an eventCode parameter in the event object which indicates the type of event. Detailed documentation for event codes can be found here. |
timestamp | UTC ISO timestamp when Blocknative first detected this transaction update. |
dispatchtimestamp | The UTC time of time of event dispatch. |
system | Blockchain of this transaction (ex. Ethereum). |
network | Network name of this transaction (ex. Mainnet or Goerli). |
contractcall | A contract call is when a specific function written into a particular smart contract is utilized or "called". This field is the top level contract call decoded. If we do not support decoding for this contract, this field will be null. |
estimatedblocksuntilconfirmed | Predicted number of blocks from pendingblocknumberuntil confirmation based on gasPrice and Gas Platform data. Field is 1 - 5 or null for estimates outside of 1 - 5. |
replacehash (Optional) | The hash of the transaction that replaced this transaction in the txpool. |
failurereason (Optional) | For failed transactions, the reason why the transaction failed. Some failures may not have a discernible reason. |
apikey | Blocknative API key associated with the notification. |
Last modified 29d ago