DEV Community: Eugene Aseev

The ultimate guide to getting multiple token balances on Ethereum

Eugene Aseev — Mon, 18 Jan 2021 09:22:06 +0000

Introduction

One of the coolest things about Ethereum is its decentralized nature—all of its transactions since the genesis block can be publicly accessible by anyone. But with an average of one million transactions a day, it can be challenging to filter out the data you need fast and efficiently.

This post focuses on one particular task—retrieving token balances of an address on Ethereum.

The challenge with this task is that there is a significant difference in how ether is stored on an address and how the tokens are stored. Ether is the balance of an address, while tokens are the balance of a contract attributed to an address.

To get the ether balance of a wallet address, you need to watch the address.

To get the token balance of the same wallet address, you need to watch the list of token contract addresses you want to track. This process requires the execution of not one but multiple JSON-RPC requests consistently—it's time consuming and resource wasteful if executed individually.

At the time of writing this post, it was quite a challenge to find a good guide on how to retrieve data from the ledger in batches. Hence, I've decided to write one. Together, in this post, we will go through three different approaches on how to retrieve token balances via the ERC-20 balanceOf contract ABI function in batches from the Ethereum ledger.

GraphQL — alternative to the Ethereum JSON-RPC interface introduced in EIP 1767.
Etherplex — a JavaScript library that makes use of the multicall smart contract to aggregate function calls and executes them in batch.
web3.js BatchRequest — the web3.js batch method that aggregates the list of contract function calls and converts them into an array of JSON-RPC calls before sending it to the Ethereum node in one XMLHttpRequest.

Before you start, we assume that:

You already know how to write code — preferably JavaScript.
You have the code samples cloned and your environment set up. See the repository prepared for this post.
You already have your Ethereum node endpoint. If you don't, you can spin up your node with us on Chainstack.

Helper functions

Before we deep-dive into sample code, let's take a look at the two helper functions we will be using across the three different approaches.

In getTokens(), we dynamically fetch a list of token address, symbol, and decimals from Token Lists—a community-led initiative to improve discoverability and trust in ERC-20 token lists. You can replace tokenSource with an API endpoint of your choice or hardcode a list of tokens within this function. In our example, we will be using the CoinGecko list.

require('isomorphic-fetch');

const tokenSource = 'https://tokens.coingecko.com/uniswap/all.json';
const getTokens = () => {
  return fetch(tokenSource, {
    methods: 'GET',
    headers: { 'Content-Type': 'application/json', },
  }).then(data => data.json());
};

In convertToNumber(), we convert the hexadecimal response to a readable numeric format.

Note that we must avoid dividing tokens that have 0 balance with more than 20 decimals as this exceeds the BigNumber minimum limit and will result in an error.

const Web3 = require('web3');

const convertToNumber = (hex, decimals) => {
  const balance = Web3.utils.toBN(hex);
  let balanceDecimal = balance;
  if (decimals && (balance.toLocaleString() === '0' && decimals < 20)) {
    balanceDecimal = balance.div(Web3.utils.toBN(10 ** decimals));
  }

  return balanceDecimal.toLocaleString();
};

Constants

In the constant.js file, we store the constants we will be using for our queries. Remember to update the constants before executing the scripts.

ABI — contract ABI with only the balanceOf function. Remember to add the function calls you are planning to execute to the ABI constant.
username — your Ethereum node RPC username.
password — your Ethereum node RPC password.
rpcEndpoint — your Ethereum node RPC endpoint.
bathEndpoint — your Ethereum node RPC endpoint with authentication credentials.

const abi = [
  {
    constant: true,
    inputs: [
      {
        name: '_owner',
        type: 'address',
      },
    ],
    name: 'balanceOf',
    outputs: [
      {
        name: 'balance',
        type: 'uint256',
      },
    ],
    payable: false,
    stateMutability: 'view',
    type: 'function',
  },
];
// replace with your Ethereum node RPC username
const username = 'username';
// replace with your Ethereum node RPC password
const password = 'password';
// replace with your Ethereum node RPC endpoint
const rpcEndpoint = 'https://nd-123-456-789.p2pify.com';
// replace with your Ethereum node RPC endpoint
const bathEndpoint = `https://${username}:${password}@nd-123-456-789.p2pify.com`;
// replace with the address you want to query
const walletAddress = '0x3f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be';

module.exports = {
  abi,
  bathEndpoint,
  password,
  rpcEndpoint,
  username,
  walletAddress,
};

GraphQL

GraphQL is a query language designed to provide flexibility, giving client control over the format of the data anyone wants. This solves one of the most common issues people face when reading data from the Ethereum ledger—underfetching and overfetching data. This can impact your day-to-day operation, especially for users querying data from multiple contracts and different block height. GraphQL API is available on all dedicated Ethereum nodes on Chainstack.

Let us take a look at the example below on how we go about retrieving CoinGeсko list token balances using GraphQL.

require('isomorphic-fetch');
const ethers = require('ethers');
const { abi, bathEndpoint, walletAddress } = require('./constant.js');
const { convertToNumber, getTokens } = require('./utils');

const convertIndexToAlphetString = number => number
  .toString()
  .split('')
  .map(numberChar => String.fromCharCode(65 + parseInt(numberChar)))
  .join('');

const queryTemplate = (index, { address }, callData) => `
  ${convertIndexToAlphetString(index)}: call(data: { to: "${address}", data: "${callData}" }) { data }`;

const retrieveTokenBalanceViaGraphQL = (tokens) => {
  const ethersInterface = new ethers.utils.Interface(abi);
  const callData = ethersInterface
    .functions.balanceOf.encode([walletAddress]);
  const query = tokens.map((token, index) => {
    return queryTemplate(index, token, callData);
  }).join('\n');

  return fetch(`${bathEndpoint}/graphql`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ query: `{ block { ${query} } }` }),
  })
    .then(data => data.json());
};

const main = async () => {
  const { tokens } = await getTokens();

  const tokenBalances = await retrieveTokenBalanceViaGraphQL(tokens)
    .then(({ data: { block: balances } })  => {
      const output = {};

      Object.entries(balances).map(([, { data: hex }], index) => {
        const { name, decimals, symbol } = tokens[index];

        output[name] = `${convertToNumber(hex, decimals)} ${symbol}`;
      });

      return output;
    });

  console.log(tokenBalances);
};

main();

Here we dynamically generate the query from the list of tokens before sending it to our GraphQL API endpoint. This approach took an average of 2289ms out of 10 runs.

Pros of GraphQL

Streamlines complex processes

Depending on the use case, you can easily combine queries on different contract function calls, different contract addresses for different wallet addresses at different block heights into one GraphQL query.

For example:

query {
  ChainLinkToken11404479: block(number: 11404479) {
    call(data: { to: "0x514910771AF9Ca656af840dff83E8264EcF986CA", data: "0x70a082310000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be" }) {
      data
    }
  }

  ChainLinkTokenLatest: block {
    call(data: { to: "0x514910771AF9Ca656af840dff83E8264EcF986CA", data: "0x70a082310000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be" }) {
      data
    }
  }

  DaiStablecoin11404470: block(number: 11404470) {
    call(data: { to: "0x6B175474E89094C44Da98b954EedeAC495271d0F", data: "0x70a0823100000000000000000000000046340b20830761efd32832a74d7169b29feb9758" }) {
      data
    }
  }
}

Will yield:


{
  "data": {
    "ChainLinkToken11404479": {
      "call": {
        "data": "0x00000000000000000000000000000000000000000003a53a9199924822b36355"
      }
    },
    "ChainLinkTokenLatest": {
      "call": {
        "data": "0x00000000000000000000000000000000000000000003a571b23d1cfe6e4e6355"
      }
    },
    "DaiStablecoin11404470": {
      "call": {
        "data": "0x0000000000000000000000000000000000000000000024e132e65f0c1c62ddeb"
      }
    }
  }
}

Through GraphQL alias, we can efficiently aggregate multiple RPC calls for different data into one GraphQL query and let Geth and GraphQL do the heavy lifting behind the scenes.

Not reliant on dependencies

There are no additional libraries required to use GraphQL. This means that your code will be more stable and less vulnerable to security loopholes or outdated dependencies.

Cons of GraphQL

Function calls must be encoded

Executing function calls through GraphQL works the same way as a normal RPC call, which means function calls must be encoded manually and passed onto the query. This might make the code confusing to read.

GraphQL alias has strict format requirements

According to the GraphQL specification, names must strictly follow the following regex pattern: /[_A-Za-z][_0-9A-Za-z]*/.

This makes it difficult to use symbols or contract names as the alias since some contract names or symbols do not match this regex pattern. In the example above, we work around this constraint via the convertIndexToAlphetString() function which generates a unique alphabetical identifier based on the index of the token in the list, which, in turn, we later map to the token list using the same index.

Etherplex

Etherplex is a library that consolidates the list of the ethers.js contract function calls into one JSON-RPC call on the multicall smart contract aggregate function, which iterates and executes the list of contract function calls.

Below is the implementation of the aggregate function.

function aggregate(Call[] memory calls) public returns (uint256 blockNumber, bytes[] memory returnData) {
  blockNumber = block.number;
  returnData = new bytes[](calls.length);

  for(uint256 i = 0; i < calls.length; i++) {
    (bool success, bytes memory ret) = calls[i].target.call(calls[i].callData);
    require(success);

    returnData[i] = ret;
  }
}

Let us look at the example below on how we go about retrieving CoinGecko token list balances using Etherplex.

const { ethers } = require('ethers');
const { batch, contract } = require('@pooltogether/etherplex');
const { abi, username, password, rpcEndpoint, walletAddress } = require('./constant.js');
const { convertToNumber, getTokens } = require('./utils');

const provider = new ethers.providers.JsonRpcProvider({
  url: rpcEndpoint,
  user: username,
  password: password,
});

const generateContractFunctionList = tokens =>
  tokens.map(({ address: tokenAddress, symbol }) =>
    contract(symbol, abi, tokenAddress).balanceOf(walletAddress),
  );

const main = async () => {
  const { tokens } = await getTokens();
  const start = new Date().getTime();
  const args = generateContractFunctionList(tokens);
  const tokenBalances = await batch.apply(null, [provider, ...args])
    .then(balances => {
      const output = {};

      Object.entries(balances).map(([symbol, { balanceOf }], index) => {
        const balance = convertToNumber(balanceOf[0]._hex, tokens[index].decimals);

        output[tokens[index].name] = `${balance} ${symbol}`;
      });

      return output;
    });

  console.log(tokenBalances);
};

main();

Here we dynamically generate the list of balanceOf function calls from the list of tokens before passing it to Ethereplex's batch function. This approach took an average of 3815ms out of 10 runs.

Pros of Etherplex

Cons of Etherplex

Reliant on Etherplex library

At the time of this post, Etherplex has not integrated support for the ethers.js blockTag functionality, which allows the user to run a query on different blocks. If this is a requirement for you, I suggest you consider:

Contributing to the Etherplex library.
Implementing your own wrapper using the multicall smart contract.
Using other approaches described in this post.

Unstable

The multicall smart contract can sometimes be unavailable and the process will fall back to using the native JSON-RPC approach. For larger queries, this will result in a timeout error: Error: execution aborted (timeout = 5s).

web3.js BatchRequest

The web3.js BatchRequest method aggregates the list of contract function calls and converts them into an array of JSON-RPC calls before sending it to the Ethereum node in one XMLHttpRequest. The Ethereum node will process these JSON-RPC requests asynchronously before sending them back to the client.

Let us look at the example below on how we go about retrieving CoinGecko token list balances using the BatchRequest method.

const Web3 = require('web3');
const { convertToNumber, getTokens } = require('./utils');
const { abi, bathEndpoint, walletAddress } = require('./constant.js');

const web3 = new Web3(new Web3.providers.HttpProvider(bathEndpoint));

const generateContractFunctionList = ({ tokens, blockNumber }) => {
  const batch = new web3.BatchRequest();

  tokens.map(async ({ address: tokenAddress, symbol, decimals }) => {
    const contract = new web3.eth.Contract(abi);
    contract.options.address = tokenAddress;

    batch.add(
      contract.methods.balanceOf(walletAddress).call.request({}, blockNumber),
    );
  });

  return batch;
};

const main = async () => {
  const { tokens } = await getTokens();

  const batch = generateContractFunctionList({ tokens });
  const tokenBalances = {};
  const { response } = await batch.execute();
  response.forEach(({ _hex }, index) => {
    const { name, decimals, symbol } = tokens[index];

    tokenBalances[name] = `${convertToNumber(_hex, decimals)} ${symbol}`;
  });

  console.log(tokenBalances);
};

main();

Here we add the list of balanceOf contract function calls from the list of tokens before calling the batch.execute function. Note that the performance for the batch command may vary depending on the RPC endpoint provider you're using—sendAsync vs send function. This approach took an average of 3042ms out of 10 runs.

Pros of web3.js BatchRequest

More human-readable code

Unlike GraphQL, the BatchRequest method works on top of web3.js, which allows us to use the contract's ABI function names instead of encoding them, which makes the code more human-readable.

Cons of web3.js BatchRequest

The library is still in development

Currently the web3.js v2.0.0 library is still in development and it's very likely to contain breaking changes in the future.

Summary

In this post, we investigated three different approaches you can take to read data from the Ethereum ledger. In our example scenario, GraphQL had the best average performance of 2289ms as compared to the Etherplex library and the web3.js BatchRequest method.

Below are the performance metrics we took:

GraphQL outperforms the other two approaches by close to 1 second.

I personally suggest using GraphQL, not mainly because of its performance but also for its stability and flexibility.

I hope this post inspires you to try using GraphQL for your use case. The GraphQL feature is supported on all our full and archive dedicated Ethereum nodes—sign up with us and unlock unlimited possibility on direct and efficient queries to the ledger.

Join our community of innovators

To learn more about Chainstack, visit our Knowledge Center or join our Gitter Lobby.
Sign up for a free Developer account, or explore the options offered by Growth or Business plans here.
Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.

Have you already explored what you can achieve with Chainstack? Get started for free today.

Eth2 and your DApps: What you need to know

Eugene Aseev — Tue, 29 Dec 2020 06:14:32 +0000

Do I as a DApp developer need to change my DApps and my DApp building routine and/or architecture?

No. Your DApps are safe for at least a couple of years.

A longer explanation

The complete Ethereum 2.0—officially referred to as Eth2—implementation and mainnet is rolled out in phases:

Phase 0 — launched on December 1, 2020 with the Beacon Chain.
Phase 1 — tentative for 2021 with the introduction of shard chains.
Phase 1.5 — tentative for 2021 or 2022 with the docking of Eth1 to Eth2.
Phase 2 — no defined plans.

Each of the phases introduces changes to Eth2 and how it interacts with Eth1 where your DApps are.

Let's have a look at each of the phases and if they can potentially make you change the way you work with your DApps.

Will anything change for me after Phase 0 is initiated?

No.

A longer explanation

On December 1, 2020, the Beacon Chain launched and marked the official start of Phase 0.

Whereas the Beacon Chain is the foundational component of Eth2, it's not the full Eth2 implementation.

With the launch of Phase 1, the Beacon Chain will start validating shard chains. Until then, the Beacon Chain is a network of stakers validating blocks on the chain.

The Beacon Chain itself cannot handle Ethereum accounts and smart contracts. Accounts and smart contracts can only be done on shard chains, and even that won't be immediately available in Phase 1.

The Beacon Chain consists of Beacon nodes and Validator clients.

To just keep an up-to-date copy of blocks on the Beacon Chain, you need a Beacon node.

To be a validator on the Beacon Chain, you need both a Beacon node, a validator client, and an Eth1 node. The Beacon node connects to the Eth1 node to monitor the Eth2 staking deposit address on Eth1 for new validators on the Beacon Chain.

The Eth1 mainnet itself is completely "unaware" of the existence of Eth2 in the form of Beacon Chain.

Architecturally, your existing DApps or your DApp building routine won't see changes during Phase 0.

Will anything change for me after Phase 1 is initiated?

No.

A longer explanation

At some point in 2021, Eth2 will see the introduction of shard chains—the proof-of-stake chains running in parallel and coordinated by the Beacon Chain.

The Beacon Chain will be assigning validators to the shard chains and will also keep the shards up-to-date with each other.

The shard chains will first be introduced as version 1. In version 1, the shards will not be capable of executing smart contracts; they will only store the data necessary to execute smart contracts—for example, time stamps, oracle data, byte information required to interact with other shards.

Version 2—when or if introduced—will see the execution of smart contracts on the shards.

Architecturally, your existing DApps or your DApp building routine won't see changes during Phase 1.

Will anything change for me after Phase 1.5 is initiated?

No, but your DApps will start responding faster, since this is when Eth2 will presumably be locked to 12 second blocks.

You won't have to change in your smart contracts, but the centralized parts of your DApps—e.g., a web app—will be fetching a quicker response to your users.

A longer explanation

In 2021 or 2022, the Eth1 mainnet will switch from the current proof-of-work to the proof-of-stake consensus algorithm and will be "docked" into Eth2. The process of docking, in this case, means that the Eth1 mainnet will become one of the shards of Eth2 coordinated by the Beacon Chain.

Architecturally, your existing DApps or your DApp building routine won't see changes during Phase 1.5.

Will anything change for me after Phase 2 is initiated?

Yes, but what exactly will change is uncertain at this point.

A longer explanation

As of today, Phase 2 is not clearly defined, however this is when you might see the most changes affecting you as a DApp developer as it may have the introduction of a new Ethereum Virtual Machine.

Your existing DApps and your DApp building routine will see significant changes during Phase 2. However, at this point, there is no defined strategy on how you can be prepared for the changes other than staying up-to-date with the Eth2 developments and being a Chainstack user.

With Chainstack, you will be prepared for Phase 2 with as little effort from you as possible---the infrastructure migration will be as seamless as viable, you will be notified of the necessary changes on your end well in advance and be supported by our extensive documentation.

Run an Eth1 node for your Eth2 client today

Run a reliable dedicated Eth1 node that you can link to your Beacon node.

Get early access to Eth2 nodes

Join our community of innovators

To learn more about Chainstack, visit our Knowledge Center or join our Gitter Lobby.
Sign up for a free Developer account, or explore the options offered by Growth or Business plans.
Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.

Have you already explored what you can achieve with Chainstack? Get started for free today.

Exploring the methods of looking into Ethereum’s transaction pool

Eugene Aseev — Thu, 24 Dec 2020 03:23:59 +0000

Introduction

The mempool of the Ethereum mainnet—called transaction pool or txpool—is the dynamic in-memory area where pending transactions reside before they are included in a block and thus become static.

The notion of a global txpool is a bit abstract as there is no single defined pool for all pending transactions. Instead, each node on the Ethereum mainnet has its own pool of transactions and, combined, they all form the global pool.

The thousands of pending transactions that enter the global pool by being broadcast on the network and before being included in a block are an always changing data set that's holding millions of dollars at any given second.

There's a lot that one can do here—and many do and make this txpool business a highly competitive market.

A few examples, listed in the order of inconspicuous to contentious:

Yield farming — you can watch the transactions movement between DeFi applications to be one of the first to detect the yield farming profitability changes.
Liquidity providing — you detect the potential liquidity movements in and out of DeFi applications and act on the changes.
Arbitrage — you can detect the movement of transactions that will affect token prices at different DEXes and make your arbitrage trades based on that.
Front running — you can automatically grab the existing pending transactions, simulate them to identify the potential profit if the transaction is executed, copy the transaction and swap the existing address with your own, and submit it with a higher miner fee so that your transaction gets executed on-chain before the one you are copying.
Doing a MEV — MEV stands for Miner Extractable Value, and it's based on that miners are theoretically free to include any transactions in the blocks and/or reorder them. This is a variation of the front running where instead of submitting your transaction with a higher fee to the same pool you picked it from, you get it directly into a block through a miner and bypass the pool.

To run any of the described scenarios, you need access to the Ethereum txpool, and you need the methods to retrieve the transactions from the txpool. While Chainstack has you covered with fast dedicated nodes for the former, this article focuses on all the ways you can look into the txpool.

Retrieving pending transactions with Geth

Since pending transactions are your targets in the txpool space, we are now going to make this a structured effort and focus on answering the following questions while accompanying the answers with practical examples:

How do I retrieve pending transactions?
Why do I view global or local pending transactions?
Can I view global pending transactions without txpool namespace?

There are a few ways to retrieve pending transactions.

Filters
Subscriptions
Txpool API
GraphQL API

Before we start, lets clarify a few things:

Global pending transactions refer to pending transactions that are happening globally, which includes your newly created local pending transactions.
Local pending transactions refer strictly to the transactions that you created on your local node. Note that you need 'personal' namespace enabled for Geth to send local transactions.
Pending transactions refer to transactions that are pending due to various reasons, like extremely low gas, out of order nonce, etc.
Chainstack is using Geth (Go Ethereum) client.

Filters

When we create a filter on Geth, Geth will return a unique filter_id. Do note that this filter_id will only live for 5 minutes from the last query on that specific filter. If you query this filter after 5 minutes, the filter will not exist anymore.

Creating a pending transaction filter and retrieving data from it

cURL

Create filter

Request body:

'{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}'

Response body:

{ "id":73, "jsonrpc": "2.0", "result": "0xb337f6e2f833ecffc6e9315ba06cd03d" }

Web3.js

Filter for pending transactions is not supported anymore. Please use Subscriptions.

Web3.py

Create filter

pending_transaction_filter= web3.eth.filter('pending')

Access filter

print(pending_transaction_filter.get_new_entries())

Common sources of confusion on filters

Web3.py and the pending argument

Why does web3.py have their input arguments as pending instead of a dictionary which contains the usual filter parameters like fromBlock, toBlock, address, topics.

This is because Web3 does the mapping internally. If we look at the web3.py source code, when web3.py receives a string pending, it will be mapped to eth_newPendingTransactionFilter, and when web3.py receives a dictionary, it is mapped to eth_newFilter.

To add to this, web3.py has get_new_entries as well as get_all_entries for filters but get_all_entries does not work in our case. This is because eth_newPendingTransactionFilter does not have get_all_entries available for it.

From latest block to pending block filter

Why doesn't the following filter give me real-time pending transactions?

web3.eth.filter({'fromBlock': 'latest', 'toBlock': 'pending'})

A filter only returns new_entries() when the state has changed. This specific filter state changes only when there is a new latest block or pending block. Thus, you will only receive changes when there is a new latest block or pending block, i.e. (eth.getBlock('latest') / pending).

The getPendingTransactions filter

Why is the following giving me a different or empty result?

web3.eth.getPendingTransactions().then(console.log)

This function is mapped to eth.pendingTransactions which is a function to check local pending transactions and does not give you global transactions.

Based on the Geth source code, only pendingTransactions that has its from field matching with your personal account will be shown.

Subscriptions

Subscriptions is real-time streaming of data from server to client through WebSocket. You will need a constantly active connection to stream such events. You cannot use curl for this and have to use a WebSocket client like websocat if you want to access it via command line. Once executed, a stream of pending transaction IDs will start flowing in.

For other supported subscriptions, check the Geth documentation: Supported Subscriptions.

Creating a subscription

Websocat

Connect to node

websocat wss://username:password@ws-nd-123-456-789.p2pify.com

Create subscription

Request body:

{"id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}

Response body:

{"jsonrpc":"2.0","id":1,"result":"0x2d4f3eb938cdb0b6fa9052de7c4da5de"}

Incoming stream

{"jsonrpc":"2.0","method":"eth_subscription","params":{"subscription":"0x2d4f3eb938cdb0b6fa9052de7c4da5de","result":"0xee426dbaef2a432d0433d5de600347e97b6a8a855daf8765c18cf1b7efc53461"}}
...

Txpool API

Txpool is a Geth-specific API namespace that keeps pending and queued transactions in the local memory pool. Geth's default is 4096 pending and 1024 queued transactions. However, Etherescan reports a much bigger number of pending transactions. If we view Geth's txpool, we will not be able to get all of the transactions. Once the pool of 4096 is full, Geth replaces older pending values with newer pending transactions.

If you need a bigger pool to be stored on your node, the flag --txpool.globalslots can be adjusted to a higher value on Geth CLI options. Do note that the larger the number, the bigger the payload size.

If you see your txpool_status to be empty, it can mean your node has not fully synced.

The txpool namespace is only supported on Chainstack dedicated nodes.

Creating a txpool filter

cURL

Create filter

Request body:

{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}

Response body:

{ "jsonrpc": "2.0", "id": 73, "result": { "pending": {...}, "queued": {...} } }

Web3.js

TxPool Module.

Web3.py

Geth API.

GraphQL API

The biggest advantage of using GraphQL is that you can filter out the specific fields of the transaction that you want. The query in GraphQL goes through the elements within the txpool. Thus, its limitations are the same as the ones of txpool as stated above.

The following is an example which shows the information of a pending transaction.

Query example:

query {
  pending {
    transactions {
      hash
      gas
      value
      gasPrice
      nonce
      r
      s
      v
      inputData
      status
      gasUsed
      cumulativeGasUsed
      from {
        address
      }
      to {
        address
      }
    }
  }
}

GraphQL API is currently supported on Chainstack dedicated Ethereum nodes.

I hope this blog serves you well in understanding the various ways of retrieving pending transactions.

Additional resources

Join our community of innovators

To learn more about Chainstack, visit our Knowledge Center or join our Gitter Lobby.
Sign up for a free Developer account, or explore the options offered by Growth or Business plans.
Take a look at our pricing tiers using a handy calculator to estimate usage and number of nodes.

Have you already explored what you can achieve with Chainstack? Get started for free today.

DEV Community: Eugene Aseev

The ultimate guide to getting multiple token balances on Ethereum

Introduction

Helper functions

Constants

GraphQL

Pros of GraphQL

Streamlines complex processes

Not reliant on dependencies

Cons of GraphQL

Function calls must be encoded

GraphQL alias has strict format requirements

Etherplex

Pros of Etherplex

More human readable code

Cons of Etherplex

Reliant on Etherplex library

Unstable

web3.js BatchRequest

Pros of web3.js BatchRequest

More human-readable code

Cons of web3.js BatchRequest

The library is still in development

Summary

Join our community of innovators

Eth2 and your DApps: What you need to know

A longer explanation

Will anything change for me after Phase 0 is initiated?

A longer explanation

Will anything change for me after Phase 1 is initiated?

A longer explanation

Will anything change for me after Phase 1.5 is initiated?

A longer explanation

Will anything change for me after Phase 2 is initiated?

A longer explanation

Run an Eth1 node for your Eth2 client today

Get early access to Eth2 nodes

Join our community of innovators

Exploring the methods of looking into Ethereum’s transaction pool

Introduction

Retrieving pending transactions with Geth

Filters

Creating a pending transaction filter and retrieving data from it

cURL

Web3.js

Web3.py

Common sources of confusion on filters

Web3.py and the pending argument

From latest block to pending block filter

The getPendingTransactions filter

Subscriptions

Creating a subscription

Websocat

Txpool API

Creating a txpool filter

cURL

Web3.js

Web3.py

GraphQL API

Additional resources

Join our community of innovators