Infura Ethereum Documentation (1.0.0)

Infura Support: support@infura.io

Securing Your Credentials

Authenticating using a Project ID

Infura's Ethereum APIs require a valid Project ID to be included with your request traffic. This identifier should be appended to the request URL.

curl https://<network>.infura.io/v3/YOUR-PROJECT-ID

Authenticating using a Project ID and Project Secret

As additional protection for your request traffic, you should use HTTP Basic Authentication to access our API when you are able to ensure the confidentiality of the Project Secret:

curl --user :YOUR-PROJECT-SECRET \
  https://<network>.infura.io/v3/YOUR-PROJECT-ID

Note that the user field of the request is left blank and the project id is passed in the URL.

Require a Project Secret

By default, the Project Secret is optional. If you know you will only be interacting with Infura APIs from a secure environment (e.g. your backend web application), you can toggle the Private Secret Required setting in your Project's configuration page under the Security section.

Authenticating using a Project ID and a JWT

You can give a client a JWT that it can use to interact with your Ethereum project ID, with specific restrictions specified in the JWT.

To authenticate with a JWT, include it in the Authorization header as a bearer token.

curl -H "Authorization: Bearer YOUR-JWT" \
  https://<network>.infura.io/v3/YOUR_PROOJECT_ID

See the section "Securing with JWTs" in Project Security for more details about generating and using JWTs.

Require a JWT

By default, requests are not required to include a JWT. However, if you want to require that all requests using your project ID include a JWT, you can toggle the JWT Required setting in your Project's configuration page under the Security section.

Choose a Network

Use one of these endpoints as your Ethereum client provider..

NOTE: Be sure to replace YOUR-PROJECT-ID with a Project ID from your Infura Dashboard.

Network Description URL
Mainnet JSON-RPC over HTTPS https://mainnet.infura.io/v3/YOUR-PROJECT-ID
Mainnet JSON-RPC over WebSocket wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID
Ropsten JSON-RPC over HTTPS https://ropsten.infura.io/v3/YOUR-PROJECT-ID
Ropsten JSON-RPC over WebSocket wss://ropsten.infura.io/ws/v3/YOUR-PROJECT-ID
Rinkeby JSON-RPC over HTTPS https://rinkeby.infura.io/v3/YOUR-PROJECT-ID
Rinkeby JSON-RPC over WebSocket wss://rinkeby.infura.io/ws/v3/YOUR-PROJECT-ID
Kovan JSON-RPC over HTTPS https://kovan.infura.io/v3/YOUR-PROJECT-ID
Kovan JSON-RPC over WebSocket wss://kovan.infura.io/ws/v3/YOUR-PROJECT-ID
Görli JSON-RPC over HTTPS https://goerli.infura.io/v3/YOUR-PROJECT-ID
Görli JSON-RPC over WebSocket wss://goerli.infura.io/ws/v3/YOUR-PROJECT-ID

Make Requests

JSON-RPC Methods

Below is a quick command line example using curl:

# Be sure to replace YOUR-PROJECT-ID with a Project ID from your Infura dashboard
$ curl -X POST \
-H "Content-Type: application/json" \
--data '{"jsonrpc": "2.0", "id": 1, "method": "eth_blockNumber", "params": []}' \
"https://mainnet.infura.io/v3/YOUR-PROJECT-ID"

The result should look something like this:

$ {"jsonrpc": "2.0","result": "0x657abc", "id":1}

NOTE: "0x657abc" will be replaced with the block number of the most recent block on that network

Read more about JSON-RPC

It's important to note that JSON-RPC requests are transport agnostic, the same requests can be made over HTTPS, Websockets, or other message passing environments. For example, the same request could be made with WebSocket:

# Be sure to replace YOUR-PROJECT-ID with a Project ID from your Infura dashboard
$ wscat -c wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID
> {"jsonrpc": "2.0", "id": 1, "method": "eth_blockNumber", "params": []}
< {"jsonrpc":"2.0","id":1,"result":"0x657abc"}

Subscriptions and Filters

Note that the newer, experimental Ethereum "pub/sub" subscription support is only supported over "stateful" transports such as WebSocket. Subscription requests cannot be made over HTTPS.

Read more about RPC PUB SUB

Project Security

There are several project-specific security settings you can use to have more control over how your Project ID is used:

  • Project secret required - require requests to include a project secret
  • Rate limiting
    • Per second requests rate limiting - limit the requests per second used by the project
    • Per day total requests - limit the total daily requests used by the project
  • JWT
    • JWT required - require requests to include a JWT
    • JWT public keys - public keys used to validate JWTs sent with requests
  • Allowlists - set limits on the types of requests that are allowed

Authentication

There are two settings you can use to require requests to include particular types of authentication.

Project secret required lets you require every request to include a Project Secret, while JWT required lets you require every request to include a JWT.

Request Rate Limiting

You can set rate limits on your project to better control its usage relative to other projects in your account, and to limit costs in case your Project ID is leaked.

Per second requests rate limiting allows you to set the maximum number of requests per second (decimal value, e.g., 1.2). If at any point, your rate exceeds the value set for your project, requests will be rejected. Once enough time has passed that the rate has decreased below the limit again, you will be able to make requests again.

Per day total requests allows you to set a limit on the total number of requests per day (integer value, e.g., 20000). Once your projects hits this limit, all requests will be rejected until the next day (00:00 UTC).

Securing With Allowlists

If you are sending API requests from a web browser or other client-side application which does not have the ability to secure your Project Secret, allowlisting can be used to prevent a third party from using your Project ID on another website.

Understanding Allowlist Behavior

  • If a project has no allowlists enabled, any request will be accepted.
  • As soon as any allowlist entries are added, all requests must pass each allowlist type.
  • A maximum of 30 allowlist entries per type are allowed per project.
  • Each allowlist type is "AND"ed together
  • Multiple entries of the same type are "OR"ed.

Example

Scenario: Alice allowlisted the User-Agent of her mobile application and the Origin where her web app is hosted.

User-Agent Allowlist entry: com.example.aliceapp

Origin Allowlist Entry: aliceapp.example.com

Result: Both Alice's mobile app AND her website are allowed to use the same Project ID. If Alice created a new website under aliceawesomeapp.example.com, she would need to add this new Origin to the allowlist to allow the Project ID to function on the new site. Alternatively, she could set a single Origin in the allowlist entry to use a wildcard subdomain pattern such as *.example.com which would allow all requests matching the pattern yet reject requests from origins not matching *.example.com.

User-Agents

If you are distributing a product which embeds an API key and you have the ability to set a custom User-Agent (e.g. an Electron app, iOS or Android app), we recommend adding the known User-Agent to your allowlist.

When a User-Agent is added to the allowlist, any API requests which originate from other platforms will be rejected.

Matching Behavior

The User-Agent allowlist utilizes partial string matching. If the allowlisted string is present in the request's full User-Agent, it is registered as a match.

Example

Allowlist entry: com.example.dapp

Request's User-Agent: com.example.dapp/v1.2.1 (Linux; Android 7.0; SM-G930V Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.125 Mobile Safari/537.36

Result: Request is allowed and all other user-agent requests are rejected

HTTP Origin

To prevent a third party from using your Project ID on their website, you can allowlist approved HTTP Origins from where it can be used.

If you are deploying your application to mydapp.example.com, adding mydapp.example.com to your HTTP Origin allowlist will ensure any traffic that does not include Origin: mydapp.example.com in the HTTP request will be rejected.

Matching Behavior

HTTP Origin matching supports wildcard subdomain patterns similarly to TLS certificates, where the left-most sub-domain may be a replaced with the special * wildcard to match any such subdomain. The * matches a single sub-domain, and can only appear as the left-most portion of an entry.

The URL schema is optional, and can be either http://, https:// or any other schema you want to limit. If the schema is included in the allow list entry, then the Origin must have the same schema. Furthermore, an entry with only a schema will limit requests to Origins of that schema.

Example

Allowlist entry: https://*.example.com

Request's Origin Header: https://myapp.example.com

Result: The request above is is allowed, as both the schema and domain name match. Any requests from origins not matching https://*.example.com are rejected. This would include http://myapp.example.com (non-matching schema), https://myapp.somewhereelse.net (base domain does not match) or https://subdomain.myapp.example.com (wildcard can only match one level of sub-domains).

Ethereum Addresses

If you know your application will only be querying data from specific smart contracts or address sources, add those addresses to your Ethereum Address Allowlist.

When an address is added to the allowlist, any API requests which query addresses not in the allowlist are rejected.

Allowlist Compatible Request Methods

The following RPC methods take an Ethereum address parameter and thus are compatible with this type of allowlisting.

  • eth_call
  • eth_estimateGas
  • eth_getLogs
  • eth_getBalance
  • eth_getCode
  • eth_getStorageAt
  • eth_getTransactionCount

Example

Allowlist entry: 0xfe05a3e72235c9f92fd9f2282f41a8154d6d342b

Request:

curl -H 'Content-Type: application/json' \
      -X POST \
      -d '{"id":1, "jsonrpc": "2.0", "method": "eth_getBalance","params":["0xfe05a3e72235c9f92fd9f2282f41a8154d6d342b", "latest"]}' \
      https://mainnet.infura.io/v3/YOUR-PROJECT-ID

Result: Request is allowed. Any compatible request methods which include only non-allowlisted addresses as a parameter will be rejected.

Method

You can restrict requests using your Project ID to specific Ethereum methods. If the list is not empty, then any method calls not specified in the list will be rejected.

For example, if you had a project that analyzed data in a contract using only the functions provided by the contract, you could include eth_call in the method allowlist.

Example

Allowlist entry: eth_call

Request:

curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xc94770007dda54cF92009BFF0dE90c06F603a09f", "latest"],"id":1}'

Result: Request is rejected, because the method is not eth_call.

Best Practices

Protecting a client-side credential can be simple or complex depending on the scenario. Use the allowlist features that best fit your application. The list of items below are recommendations we'd like to make to help you make informed decisions for your application.

  • Whenever you are making API requests and can ensure the PROJECT_SECRET will not be exposed publicly, include it in your requests.
  • Don't just use the User-Agent or Origin allowlist, use both whenever possible.
  • Don't reuse Project IDs across projects.
  • Create a new Project ID for each application. This allows you to allowlist the contract addresses relevant to that application.
  • Never expose your PROJECT_SECRET in client-side code such as Javascript imported into a webpage or iOS or Android apps. Use the other options for securing public Project IDs instead.

Securing With JWTs

Sometimes, a project may have more complex security requirements, where it needs to be able to authorize other parties to use its Project ID, but with specific limitations.

Using JSON Web Tokens (JWTs) can provide a project with more flexibility in allowing users and other third parties to use its Project ID.

Example usage

A user authenticates with a service, for example, by logging in on a mobile device, and receives a JWT signed by the service. Then, each request to Infura with the application's Project ID includes the JWT, which is verified to make sure it was signed by the service, and is rejected if invalid. If the project settings require a JWT, then the operators of the service can be sure that only users who have authenticated with the service and received a JWT can use their Project ID.

In addition, the JWT can include allowlists that constrain the types of requests that can be made by the bearer of the token. For example, in a system with proxy contracts, the user can be restricted to sending requests to their own proxy.

Setting up your project to use JWTs

In order to use JWTs with your project, you first need to generate a public/private key pair. Infura supports the algorithms RS256 and ES256. Be sure to keep your private key private!

Example: generating an RSA key pair

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Example: generating an EC (256) key pair

openssl ecparam -name prime256v1 -genkey -noout -out private.pem
openssl ec -in private.pem -pubout -out public.pem

Once you have generated your keys, upload your public key in the Security section of your project's settings. Each project has separate settings, so if you want to use a key for multiple projects, you need to upload it separately for each one. You can upload up to three keys for each project, to allow for key rotation.

You will need to enter a human-readable name to identify the key, and the text from the key file. It should be a PEM-encoded file (e.g. generated by OpenSSL). It will usually look something like:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr7VlNytvNFt9wVkjJ8vG
L4F0+id4kS1CpG7UMh1kghrLg9KMb8gauy7Bxk6PRz5Ckv1FnG4FL+Z3Cdzwd6c8
jJlzJxbRTYvNi3elqAyItE3tRl6CatRur49t9nGepgFOrwmPP5We52G5O0BsW6Mx
w/neqQH+Y/bXqs0PG/0ZbpTyr044Lh+p9grSuPIogIGIY5JM4AI+fpdH6hVnA7od
PkinkWhQqAW+F8jngwZK+JCFS1GAeobTZVbvsiHZQGuP/T7hqE8z5Q8HYO4ymnkI
MPH6zSKhSxsQRs/kWU5lXqY67ORC3DIMA+I/AJujLuoqC+YaMP0fO81XjrwXPf2j
4wIDAQAB
-----END PUBLIC KEY-----

When you save it, it will be displayed with a fingerprint that you can use to identify the key, and a key ID that will be used to select the key when verifying JWTs. You will need to use this when creating JWTs.

Optionally, you can specify that every request using the Project ID must include a JWT by selecting the checkbox "JWT Required" in your project's security settings.

Creating JWTs

In order for your JWT to pass validation, it must:

  • use a supported algorithm (RS256 or ES256)
  • include the key ID of a public key associated with the project in the kid field of the header
  • not be expired
  • validate with the public key associated with the kid in the header
  • specify infura.io in the aud field
  • have properly formatted allowlists (if present)

Allowlists correspond to the existing allowlists, and can be set with the following keys:

  • addresses
  • origins
  • user_agents
  • methods

Note that allowlists from the JWT will always override any set in the project settings, for that request.

Examples

Minimal JWT

Header

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "bdbd8dabcb8d49f3ae9732c14c9940ea"
}

Body

{
  "exp": 1617736153,
  "aud": "infura.io"
}

This JWT has no allowlists, and allows any kind of request.

JWT with allowlists

Header

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "bdbd8dabcb8d49f3ae9732c14c9940ea"
}

Body

{
  "exp": 1617736153,
  "aud": "infura.io",
  "user_agents": ["mydapp v1"],
  "methods": ["eth_call"]
}

This JWT allows eth_call requests from the user-agent mydapp v1, to any Ethereum address, and from any HTTP Origin.

Websockets

Infura's WebSocket endpoint provides support for Pub/Sub API as well as JSON-RPC filter support. Additionally, the regular Ethereum JSON-RPC API is also supported over a WebSocket connection and documented in the 'EXAMPLE' portion for each 'Ethereum JSON-RPC' call.

All examples in this reference section uses wscat, but will work with any tool that supports the WebSocket protocol.

Some tools you can use for making these requests

Websocket authentication by Project ID

Websocket subscription requests should include your PROJECT_ID in the WebSocket API url.

wscat -c wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID

Websocket authentication by Project ID and Project Secret

Subscriptions initiated from a secure environment can include the Project Secret as shown below:

wscat -c wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID --auth ":YOUR-PROJECT-SECRET"

EXAMPLE

The following is an example showing a connection to the WebSocket endpoint and using subscriptions through web3.js 1.0.

NOTE: web3.js 1.0.0-beta.34 has an open issue with request headers (https://github.com/ethereum/web3.js/issues/1559); use version 1.0.0-beta.36 or newer or revert to version 1.0.0-beta.33 to avoid this issue.

const Web3 = require("web3");

let web3 = new Web3(
  // Replace YOUR-PROJECT-ID with a Project ID from your Infura Dashboard
  new Web3.providers.WebsocketProvider("wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID")
);

const instance = new web3.eth.Contract(<abi>, <address>);

instance.getPastEvents(
    "SomeEvent",
    { fromBlock: "latest", toBlock: "latest" },
    (errors, events) => {
        if (!errors) {
            // process events
        }
    }
);

FAQ

What is the Infura WebSocket endpoint URL?

There is an endpoint for each supported network (Mainnet, Ropsten, Rinkeby, Kovan, Görli); see the Getting started guide for details.

Is batch support available?

Yes

Is compression enabled?

Yes

What is the max payload size?

128MB

Why does my WebSocket connection disconnect after a while?

Idle connections that exceed beyond an hour will get disconnected. Adding 'pings' to your WebSocket connection will prevent the connection from going idle. Any unrecognized requests will trigger the server to close the connection with an error message.

Non-empty 'Sec-WebSocket-Protocol' header error?

web3.js 1.0.0-beta.34 has an open issue with request headers https://github.com/ethereum/web3.js/issues/1559. Please revert/downgrade to 1.0.0-beta.33.

Why is includeTransactions option not working for eth_subscribe?

Though the includeTransactions option is included in the Ethereum Pub/Sub API documentation, currently it is not returning the expected results. For more information: https://github.com/ethereum/go-ethereum/issues/15804.

Archive Data

What is an archive node?

An archive node is a simplified way of identifying an Ethereum full node running in archive mode. Ethereum full-nodes need to store block data such as headers and block contents indefinitely but they do not need to persist the generated World State from each block verification for all blocks. The full node only needs to keep the block specific state around long enough to be able to recalculate in the event of a blockchain reorg (by default this is 128 blocks in most implementations).

A full-node running without archive mode will prune generated state to conserve disk space. This helps with the sync time of a node and greatly reduces storage and computation cost. Because of the way account and contract storage works in Ethereum, this means that only an archive node can serve API request for certain RPC methods older than 128 blocks.

Do I need archive data?

The Ethereum JSON-RPC and Websocket API includes several methods which might require access to an archive node. These methods include an extra parameter for specifying a block number for the request.

If you are interested in inspecting historical data (data outside of the most recent 128 blocks) for any of the methods listed below, your request requires access to archive data.

  • eth_getBalance
  • eth_getCode
  • eth_getTransactionCount
  • eth_getStorageAt
  • eth_call

Rate Limits

Infura accounts will be subject to rate limits after exceeding their daily request limit. We will also rate limit projects that send too many JSONRPC requests during a short time window. These rate limits are in place to ensure the reliability of our service for everyone using it.

How do I know if I'm being rate limited?

If you are rate limited, your JSONRPC responses will have HTTP Status code 429 and contain a JSONRPC error response like so:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32005,
    "message": "project ID request rate exceeded",
    "data": {
      "see": "https://infura.io/docs/ethereum/jsonrpc/ratelimits",
      "current_rps": 13.333,
      "allowed_rps": 10.0,
      "backoff_seconds": 30.0
    }
  }
}

The "data" section contains 3 fields about your rate limit:

  • current_rps: The current rate per second determined by Infura
  • allowed_rps: The current allowed rate which you should stay under.
  • backoff_seconds: The suggested amount of time to wait before sending more requests.

Note that allowed_rps can and will change based on overall network conditions, so the current value should be used.

What should I do if rate limited?

The easiest solution is to pause JSONRPC activity for the amount of time returned in "backoff_seconds".

If you are consistently being rate limited consider some of these work-arounds:

  • Make sure you are using a Project ID in your URL. Requests without a Project ID will be severely rate-limited or even outright blocked.
  • Cache Ethereum data locally. Barring exceptionally rare deep reorganizations of the chain, blocks more than a couple blocks below the head of the chain can be cached indefinitely. Ask for the data once then keep it locally.
  • Limit RPCs at DApp startup. Likewise, limit the number of RPCs your DApp calls immediately at startup. Only request data as the user accesses that portion of the DApp, and cache anything from older blocks for next time.
  • Don't poll Infura in a tight loop. New blocks come roughly every 15 seconds, so requesting new data at a faster rate usually doesn't make sense. Consider using eth_subscribe to be notified when new blocks are available.

What factors does Infura use to determine rate limits?

Rate limiting will be applied account wide after the accounts daily request limit is exceeded.

For rate limiting designed to protect our service in the event of an attack, we use a combination of:

  • Source IP address
  • JSONRPC Method
  • Project ID

Our system constantly adjusts these types of rate limits based on overall usage and possible abuse. Typically only very aggressive usage should ever experience rate limits. Customers running into any rate limits are encouraged to contact us; we'll work with you to determine how best to avoid being rate limited in the future.

Error codes

If an Ethereum RPC method encounters an error, the error member included on the response object MUST be an object containing a code member and descriptive message member. The following list contains all possible error codes and associated messages:

Code Message Meaning Category
-32700 Parse error Invalid JSON standard
-32600 Invalid request JSON is not a valid request object standard
-32601 Method not found Method does not exist standard
-32602 Invalid params Invalid method parameters standard
-32603 Internal error Internal JSON-RPC error standard
-32000 Invalid input Missing or invalid parameters non-standard
-32001 Resource not found Requested resource not found non-standard
-32002 Resource unavailable Requested resource not available non-standard
-32003 Transaction rejected Transaction creation failed non-standard
-32004 Method not supported Method is not implemented non-standard
-32005 Limit exceeded Request exceeds defined limit non-standard
-32006 JSON-RPC version not supported Version of JSON-RPC protocol is not supported non-standard

Example error response:

{
    "id": 1337
    "jsonrpc": "2.0",
    "error": {
        "code": -32003,
        "message": "Transaction rejected"
    }
}

Value encoding

Specific types of values passed to and returned from Ethereum RPC methods require special encoding:

Quantity

  • A Quantity value MUST be hex-encoded.
  • A Quantity value MUST be "0x"-prefixed.
  • A Quantity value MUST be expressed using the fewest possible hex digits per byte.
  • A Quantity value MUST express zero as "0x0".

Examples Quantity values:

Value Valid Reason
0x invalid empty not a valid quantity
0x0 valid interpreted as a quantity of zero
0x00 invalid leading zeroes not allowed
0x41 valid interpreted as a quantity of 65
0x400 valid interpreted as a quantity of 1024
0x0400 invalid leading zeroes not allowed
ff invalid values must be prefixed

Block Identifier

The RPC methods below take a default block identifier as a parameter.

  • eth_getBalance
  • eth_getStorageAt
  • eth_getTransactionCount
  • eth_getCode
  • eth_call
  • eth_getProof

Since there is no way to clearly distinguish between a Data parameter and a Quantity parameter, EIP-1898 provides a format to specify a block either using the block hash or block number. The block identifier is a JSON object with the following fields:

Property Type Description
[blockNumber] {Quantity} The block in the canonical chain with this number
OR [blockHash] {Data} The block uniquely identified by this hash. The blockNumber and blockHash properties are mutually exclusive; exactly one of them must be set.
requireCanonical {boolean} (optional) Whether or not to throw an error if the block is not in the canonical chain as described below. Only allowed in conjunction with the blockHash tag. Defaults to false.

If the block is not found, the callee SHOULD raise a JSON-RPC error (the recommended error code is -32001: Resource not found. If the tag is blockHash and requireCanonical is true, the callee SHOULD additionally raise a JSON-RPC error if the block is not in the canonical chain (the recommended error code is -32000: Invalid input and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). The block-not-found check SHOULD take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical.

Data

  • A Data value MUST be hex-encoded.
  • A Data value MUST be "0x"-prefixed.
  • A Data value MUST be expressed using two hex digits per byte.

Examples Data values:

Value Valid Reason
0x valid interpreted as empty data
0x0 invalid each byte must be represented using two hex digits
0x00 valid interpreted as a single zero byte
0x41 true interpreted as a data value of 65
0x004200 true interpreted as a data value of 16896
0xf0f0f false bytes require two hex digits
004200 false values must be prefixed

Authentication

basicAuth

Security Scheme Type HTTP
HTTP Authorization Scheme basic

Transactions

Infura Transactions (ITX) is a simplified way to send Ethereum transactions. ITX handles all edge cases for transaction delivery and takes care of getting transactions mined while removing the need for developers to deal with the complexities around gas management.

Note

This is an early release available for testing on the Rinkeby network and will roll out to a small group of beta testers before the official public rollout at the start of 2021. If you’d like to be considered for early ITX access, submit your request here.

Overview

There are three high-level steps you need to take when integrating ITX in your project:

  1. On-chain deposit. You generate a private key and deposit some ETH with Infura’s on-chain deposit contract. This action credits your ITX gas tank with the corresponding amount of ETH. You will use your private key any time you authorize spending from your ITX gas tank (i.e. when relaying a transaction).

  2. Send a relay request. You send a transaction relay request to your usual Infura endpoint using the relay_sendTransaction RPC call. ITX will first check if you have sufficient balance, then lock a portion of your funds and relay the transaction on your behalf to the Ethereum network.

  3. Transaction mined & balance deducted. As soon as the transaction is mined and becomes part of the blockchain, the cost of the transaction which includes the network fee (gas price * gas used) + the ITX fee, will be subtracted from your gas tank balance. You can check your new balance using the relay_getBalance RPC call.

Developing with ITX

The ITX API is implemented as a JSON-RPC extension of the standard Ethereum client interface, and the deposit system is managed by an on-chain Ethereum contract. This means you can work with ITX using your favourite programming language and web3 framework.

The code snippets in this walkthrough are written in Javascript using the ethers.js library, but you're by no means limited to these programming choices.

You can find a full collection of scripts that showcase an end-to-end interaction with ITX in this Github repository.

Setup the ITX provider

All ITX-specific JSONRPC methods can be accessed via the ethers.js built-in InfuraProvider class, using your dedicated Infura URL.

const { ethers } = require('ethers')

const itx = new ethers.providers.InfuraProvider(
  'rinkeby',
  'YOUR_INFURA_PROJECT_ID'
)

Create a signer account

This is as simple as generating an Ethereum-compatible private key you have exclusive control over. You will use the private key for authenticating your ITX transaction requests, and its corresponding public address for identifying your ITX gas tank.

const signer = new ethers.Wallet('YOUR-PRIVATE-KEY', itx)

Check your ITX gas tank

Let's check if your signing account has any gas tank balance registered with ITX. You can do this by calling the relay_getBalance method:

async function getBalance() {
  balance = await itx.send('relay_getBalance', [signer.address])
  console.log(`Your current ITX balance is ${balance}`)
}

Full script to read your ITX balance here.

Make a deposit

async function deposit(signer) {
  const tx = await signer.sendTransaction({
    // This is the ITX PaymentDeposit contract address for Rinkeby
    to: '0x015C7C7A7D65bbdb117C573007219107BD7486f9',
    // Choose how much ether you want to deposit in the ITX gas tank
    value: ethers.utils.parseUnits('0.1', 'ether')
  })

  // Waiting for the transaction to be mined
  await tx.wait()
}

Full script to make an ITX deposit here.

Signing a relay request

The format of an ITX relay request is:

{
  "to": "<target contract address>",
  "data": "<encoded contract call>",
  "gas": "<upper limit for gas spent>"
}

The relay hash value of this request is given by the following formula, where (to + data + gas + chainId) represents the RLP encoded concatenation of the corresponding request fields:

keccak256("\x19Ethereum Signed Message:\n" + len((to + data + gas + chainId)) + (to + data + gas + chainId)))

Every ITX relay request needs to be individually authenticated by signing the relay hash value using your private key:

async function signRequest(tx) {
  const relayTransactionHash = ethers.utils.keccak256(
    ethers.utils.defaultAbiCoder.encode(
      ['address', 'bytes', 'uint', 'uint'],
      [tx.to, tx.data, tx.gas, 4] // Rinkeby chainId is 4
    )
  )
  return await signer.signMessage(ethers.utils.arrayify(relayTransactionHash))
}

Call a contract method

Now that you're able to generate signatures that authenticate your relay requests, you're ready to call the relay_sendTransaction method and instruct ITX to relay your requests to the Ethereum network..

relay_sendTransaction requires two parameters:

  • The relay request object
  • Your signature
async function callContract() {
  const iface = new ethers.utils.Interface(['function echo(string message)'])
  const data = iface.encodeFunctionData('echo', ['Hello world!'])
  const tx = {
    to: '0x35A2624888e207e4B3434E9a9E250bF6Ee68FeA3',
    data: data,
    gas: '100000'
  }
  const signature = await signRequest(tx)
  const relayTransactionHash = await itx.send('relay_sendTransaction', [
    tx,
    signature
  ])
  console.log(`ITX relay hash: ${relayTransactionHash}`)
  return relayTransactionHash
}

Check if relay request is mined

Unlike eth_sendRawTransaction, the relay request returns a relayTransactionHash and not a single Ethereum transaction hash. The ITX service is responsible for taking your relay request, packing it into an Ethereum transaction, and then gradually increasing the fee until the transaction is mined. The Ethereum Transaction hash is changed every time the fee is bumped and the previous hash is no longer reliable for tracking its status.

We provide a new RPC call relay_getTransactionStatus that returns the list of Ethereum Transaction hashes broadcasted for the supplied relayTransactionHash. You can then check client-side whether any of the transaction hashes were mined.

const wait = (milliseconds) => {
  return new Promise((resolve) => setTimeout(resolve, milliseconds))
}

async function waitTransaction(relayTransactionHash) {
  let mined = false

  while (!mined) {
    const statusResponse = await itx.send('relay_getTransactionStatus', [
      relayTransactionHash
    ])

    for (let i = 0; i < statusResponse.length; i++) {
      const hashes = statusResponse[i]
      const receipt = await itx.getTransactionReceipt(hashes['ethTxHash'])
      if (receipt && receipt.confirmations && receipt.confirmations > 1) {
        mined = true
        return receipt
      }
    }
    await wait(1000)
  }
}

And that is it! You have just sent a relay request via the ITX service. A full code sample is available in our demo repository.

Limitations

ITX supports any type of transaction that doesn't carry Ether (i.e. whose value field is set to 0). You can use it for deploying your own contracts or calling arbitrary contract methods, and you can also use it for enabling your users to interact with your Dapp, even if they don't hold any Ether.

Important

The from address of the final transaction will always be set to an internal ITX wallet address (chosen by the ITX system), whereas the final to and data fields are chosen by you and defined in the original transaction request (as parameters to your relay_sendTransaction call).

While this approach makes it possible for ITX wallets to pay the gas for executing the transaction, you need to pay close attention to the use of msg.sender in the contracts you're interacting with. For every managed transaction, the contracts will see the method call as originating from one of the ITX wallets. The best practice for working around this challenge is to encode a meta transaction in the data field of your initial request.

Meta transactions

In many (if not most) situations, you will need to authenticate your actions with a smart contract. This is necessary if you wish to transfer an ERC20 token or to vote in a DAO. Most smart contracts authenticate the caller using msg.sender which is the immediate caller of the smart contract. More often than not, an Ethereum Transaction is the direct caller of the smart contract and the msg.sender is computed as the from address of the transaction.

This is problematic for third party relayers like ITX as the default Ethereum authentication mechanism (i.e., the built-in transaction signature) is now used by ITX to pay the transaction gas and the from address of the final transaction is not under your direct control. To solve this problem, the community have worked on the concept of a meta-transaction which requires the user to send a signed message to a smart contract before an action is executed.

Meta transaction compatibility with ITX You can use ITX as a building block to implement any meta transaction flow. Your choice of on-chain authentication architecture will determine the to and data fields in your ITX transaction, but it will not impact how you interact with ITX.

At this point ITX is fully agnostic of the to and data parameters it receives from you, so it will relay your transactions regardless of the meta transaction flow you decide to use.

Emerging meta transaction flows can be broken into two solutions:

  • Modify target contract. The smart contract verifies a signed message from the user before executing the command.
  • Wallet contracts. The user has a wallet contract that has possession of their assets. All user actions are sent via the wallet contract.

There are several solutions for modifying the target contract such as EIP-2612's permit(), EIP3009's transferWithAuthorisation() or EIP2771's Forwarder contract..

Generally speaking, the standards focus on how to replace msg.sender with an ecrecover that verifies the user's signed message. If the user only needs to interact with your smart contract, then it is a simple solution. However, if the user needs to interact with ERC20 tokens that are not meta-transaction compatible, then you may run into limitations still.

The wallet contract approach verifies the user's signature before executing their desired action. It is compatible with most smart contracts as the immediate caller of a target contract is the wallet contract and not the Ethereum transaction. Thus, the msg.sender of the target contract is the wallet contract address. There are also other benefits to wallet contracts such as batching two or more transactions together. However it does require a setup phase as the user must transfer assets to their wallet contract. You can pick any wallet contract implementation to work with ITX.


We hope Infura Transactions will help you build more powerful and accessible products. However, it is alpha software and we would appreciate any thoughts about it (good or bad).

relay_sendTransaction

Sends a transaction relay request.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "relay_sendTransaction"
required
Array of objects or strings

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "relay_sendTransaction",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "0xff6c3dcf0d4ccc58ab1b0caf2a69812508749cf82eb9b09391cdf7cfbb7cf81e"
}

relay_getTransactionStatus

Retrieves the status of a relayed transaction.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "relay_getTransactionStatus"
params
required
Array of strings <= 1 items

A single-element array comprised of the relay transaction hash

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "relay_getTransactionStatus",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": [
    ]
}

relay_getBalance

Retrieves the ITX balance (gas tank) of a signing address that has previously deposited ether with the ITX contract.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "relay_getBalance"
params
required
Array of strings <= 1 items

A single-element array comprised of the signer public Ethereum address

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "relay_getBalance",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "89154701859431608"
}

Pub/Sub Methods

eth_subscribe

Creates a new subscription over particular events. The node will return a subscription id. For each event that matches the subscription a notification with relevant data is sent together with the subscription id.

  • newHeads- Subscribing to this, fires a notification each time a new header is appended to the chain, including chain reorganizations. In case of a chain reorganization the subscription will emit all new headers for the new chain. Therefore the subscription can emit multiple headers on the same height.
  • logs - Returns logs that are included in new imported blocks and match the given filter criteria. In case of a chain reorganization previous sent logs that are on the old chain will be resend with the removed property set to true. Logs from transactions that ended up in the new chain are emitted. Therefore a subscription can emit logs for the same transaction multiple times.
    • address (optional) - either an address or an array of addresses. Only logs that are created from these addresses are returned (optional)
    • topics (optional) - only logs which match the specified topics (optional)
    • newPendingTransactions - Returns the hash for all transactions that are added to the pending state and are signed with a key that is available in the node. When a transaction that was previously part of the canonical chain isn't part of the new canonical chain after a reogranization its again emitted.
    • syncing - Indicates when the node starts or stops synchronizing. The result can either be a boolean indicating that the synchronization has started (true), finished (false) or an object with various progress indicators. NOT SUPPORTED ON KOVAN!
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_subscribe"
required
Array of strings or objects non-empty

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_subscribe",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "params": {
    }
}

eth_unsubscribe

Subscriptions are cancelled with a regular RPC call with eth_unsubscribe as method and the subscription id as first parameter. It returns a bool indicating if the subscription was cancelled successful.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_unsubscribe"
params
required
Array of strings non-empty

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_unsubscribe",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}

JSON-RPC Methods

parity_nextNonce

Returns next available nonce for transaction from given account. Includes pending block and transaction queue.

NOTE: this method is only supported on the kovan network through our HTTPS and WebSocket endpoints.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "parity_nextNonce"
params
required
Array of strings non-empty

a string representing the address (20 bytes) to check for transaction

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "parity_nextNonce",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

web3_clientVersion

Returns the version of the current client

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "web3_clientVersion"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "web3_clientVersion",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

web3_sha3

Hashes data using the Keccak-256 algorithm

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "web3_sha3"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "web3_sha3",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

net_listening

Determines if this client is listening for new network connections

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "net_listening"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "net_listening",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}

net_peerCount

Returns the number of peers currently connected to this client

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "net_peerCount"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "net_peerCount",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

net_version

Returns the chain ID associated with the current network

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "net_version"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "net_version",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_accounts

Returns a list of addresses owned by this client

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_accounts"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_accounts",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": [
    ]
}

eth_blockNumber

Returns the number of the most recent block seen by this client

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_blockNumber"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_blockNumber",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_call

Executes a new message call immediately without creating a transaction on the block chain.

Method Limitations

To prevent abusive of the API, the gas parameter to eth_estimateGas and eth_call are capped at 10x (1000%) the current block gas limit. You can recreate this behavior in your local test environment (ganache, besu, geth, or other client) via the rpc.gascap command-line option.

Body

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

On Mainnet, Rinkeby, Ropsten and Goerli, if this call causes the EVM to execute a REVERT operation, an error response of the following form is returned, with the revert reason pre-decoded as a string:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": 3,
    "message": "execution reverted: Dai/insufficient-balance",
    "data": "0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000184461692f696e73756666696369656e742d62616c616e63650000000000000000"
  }
}

On Kovan, the actual revert reason is instead returned encoded as part of the data field in the response.

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32015,
    "data": "Reverted 0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000204f776e61626c653a2063616c6c6572206973206e6f7420746865206f776e6572",
    "message": "VM execution error."
  }
}
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_call"
required
Array of objects or (string or strings or BlockIdentifier (object)) 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_call",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_coinbase

Returns the coinbase address for this client

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_coinbase"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_coinbase",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_estimateGas

Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. Note that the estimate may be significantly more than the amount of gas actually used by the transaction, for a variety of reasons including EVM mechanics and node performance.

Method Limitations

To prevent abusive of the API, the gas parameter to eth_estimateGas and eth_call are capped at 10x (1000%) the current block gas limit. You can recreate this behavior in your local test environment (ganache, besu, geth, or other client) via the rpc.gascap command-line option.

Response

On Mainnet, Rinkeby, Ropsten and Goerli, if this call causes the EVM to execute a REVERT operation, an error response of the following form is returned, with the revert reason pre-decoded as a string (not yet supported on Kovan):

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": 3,
    "message": "execution reverted: Dai/insufficient-balance",
    "data": "0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000184461692f696e73756666696369656e742d62616c616e63650000000000000000"
  }
}
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_estimateGas"
required
Array of objects or (string or strings) 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_estimateGas",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_gasPrice

Returns the current price of gas expressed in wei

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_gasPrice"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_gasPrice",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getBalance

Returns the balance of an address in wei

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getBalance"
required
Array of strings or (string or strings or BlockIdentifier (object)) 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getBalance",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getBlockByHash

Returns information about a block specified by hash

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getBlockByHash"
required
Array of strings or booleans 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getBlockByHash",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getBlockByNumber

Returns information about a block specified by number

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getBlockByNumber"
required
Array of (string or strings) or booleans 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getBlockByNumber",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getBlockTransactionCountByHash

Returns the number of transactions in a block specified by block hash

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getBlockTransactionCountByHash"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getBlockTransactionCountByHash",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getBlockTransactionCountByNumber

Returns the number of transactions in a block specified by block number

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getBlockTransactionCountByNumber"
required
Array of (string or strings) 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getBlockTransactionCountByNumber",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getCode

Returns the contract code stored at a given address

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getCode"
required
Array of strings or (string or strings or BlockIdentifier (object)) 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getCode",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getLogs

Returns an array of all logs matching a given filter object.

Limitations

To prevent queries from consuming too many resources, eth_getLogs requests are currently limited by two constraints:

  • A max of 10,000 results can be returned by a single query

  • Query duration must not exceed 10 seconds

If a query returns too many results or exceeds the max query duration, one of the following errors is returned:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32005,
    "message": "query returned more than 10000 results"
  }
}
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32005,
    "message": "query timeout exceeded"
  }
}

If this happens:

  • Limit your query to a smaller number of blocks using fromBlock and toBlock.
  • If querying for commonly used topics, consider limiting to a single Smart Contract address as well.
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getLogs"
required
Array of objects 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getLogs",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": [
    ]
}

eth_getStorageAt

Returns the value from a storage position at a given address.

Body

Calculating the correct position depends on the storage to retrieve. Consider the following contract deployed at 0x295a70b2de5e3953354a6a8344e616ed314d7251 by address 0x391694e7e0b0cce554cb130d723a9d27458f9298,

contract Storage {
    uint pos0;
    mapping(address => uint) pos1;

    function Storage() {
        pos0 = 1234;
        pos1[msg.sender] = 5678;
    }
}

Retrieving the value of pos0 is straight forward:

curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "0x65a8db"], "id": 1}'
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x00000000000000000000000000000000000000000000000000000000000004d2"
}

Retrieving an element of the map is harder. The position of an element in the map is calculated with:

keccak(LeftPad32(key, 0), LeftPad32(map position, 0))

This means to retrieve the storage on pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] we need to calculate the position with:

keccak(
  decodeHex(
    '000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298' +
      '0000000000000000000000000000000000000000000000000000000000000001'
  )
)

The geth console which comes with the web3 library can be used to make the calculation:

> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
undefined
> web3.sha3(key, {"encoding": "hex"})
"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"

Now to fetch the storage:

curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "0x65a8db"], "id": 1}'
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x000000000000000000000000000000000000000000000000000000000000162e"
}
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getStorageAt"
required
Array of strings or strings or (string or strings or BlockIdentifier (object)) 3 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getStorageAt",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getTransactionByBlockHashAndIndex

Returns information about a transaction specified by block hash and transaction index

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getTransactionByBlockHashAndIndex"
required
Array of strings or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getTransactionByBlockHashAndIndex",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getTransactionByBlockNumberAndIndex

Returns information about a transaction specified by block number and transaction index

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getTransactionByBlockNumberAndIndex"
required
Array of (string or strings) or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getTransactionByBlockNumberAndIndex",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getTransactionByHash

Returns information about a transaction specified by hash

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getTransactionByHash"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getTransactionByHash",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getTransactionCount

Returns the number of transactions sent from an address

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getTransactionCount"
required
Array of strings or (string or strings or BlockIdentifier (object)) 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getTransactionCount",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getTransactionReceipt

Returns the receipt of a transaction by transaction hash. Note that the receipt is not available for pending transactions.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getTransactionReceipt"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getTransactionReceipt",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getUncleByBlockHashAndIndex

Returns information about an uncle specified by block hash and uncle index position

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getUncleByBlockHashAndIndex"
required
Array of strings or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getUncleByBlockHashAndIndex",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getUncleByBlockNumberAndIndex

Returns information about an uncle specified by block number and uncle index position

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getUncleByBlockNumberAndIndex"
required
Array of (string or strings) or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getUncleByBlockNumberAndIndex",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": {
    }
}

eth_getUncleCountByBlockHash

Returns the number of uncles in a block specified by block hash

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getUncleCountByBlockHash"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getUncleCountByBlockHash",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getUncleCountByBlockNumber

Returns the number of uncles in a block specified by block number

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getUncleCountByBlockNumber"
required
Array of (string or strings) 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getUncleCountByBlockNumber",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_getWork

Returns a list containing relevant information for proof-of-work

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getWork"
params
required
Array of any

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getWork",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": [
    ]
}

eth_hashrate

Returns the number of hashes-per-second this node is mining at

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_hashrate"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_hashrate",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_mining

Determines if this client is mining new blocks

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_mining"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_mining",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}

eth_protocolVersion

Returns the current Ethereum protocol version

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_protocolVersion"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_protocolVersion",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_sendRawTransaction

Sends and already-signed transaction to the network

Response

TRANSACTION HASH - 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available

NOTE - Use eth_getTransactionReceipt to get the contract address, after the transaction was mined, when you created a contract.

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

On Mainnet, Rinkeby, Ropsten and Goerli, if this call causes the EVM to execute a REVERT operation, an error response of the following form is returned, with the revert reason pre-decoded as a string (not yet supported on Kovan):

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": 3,
    "message": "execution reverted: Dai/insufficient-balance",
    "data": "0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000184461692f696e73756666696369656e742d62616c616e63650000000000000000"
  }
}
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_sendRawTransaction"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_sendRawTransaction",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_sendTransaction

Creates, signs, and sends a new transaction to the network

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_sendTransaction"
required
Array of objects 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_sendTransaction",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_sign

Calculates an Ethereum-specific signature in the form of keccak256("\x19Ethereum Signed Message:\n" + len(message) + message))

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_sign"
required
Array of strings or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_sign",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_signTransaction

Signs a transaction that can be submitted to the network at a later time using with eth_sendRawTransaction

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_signTransaction"
required
Array of objects 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_signTransaction",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_signTypedData

Calculates an Ethereum-specific signature in the form of keccak256("\x19Ethereum Signed Message:\n" + len(message) + message))

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_signTypedData"
required
Array of strings or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_signTypedData",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_submitHashrate

Submit a mining hashrate

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_submitHashrate"
required
Array of strings or strings 2 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_submitHashrate",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}

eth_submitWork

Submit a proof-of-work solution

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_submitWork"
required
Array of strings or strings or strings 3 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_submitWork",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}

eth_syncing

eth_syncing

Returns an object with data about the sync status or false.

REQUEST

POST https://<network>.infura.io/v3/YOUR-PROJECT-ID

HEADERS

Content-Type: application/json

EXAMPLE

## JSON-RPC over HTTPS POST
## Replace YOUR-PROJECT-ID with a Project ID from your Infura Dashboard
## You can also replace mainnet with a different supported network
curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_syncing","params": [],"id":1}'

## JSON-RPC over WSS
## Replace YOUR-PROJECT-ID with a Project ID from your Infura Dashboard
## You can also replace mainnet with a different supported network
wscat -c wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID
>{"jsonrpc":"2.0","method":"eth_syncing","params": [],"id":1}

RESPONSE

RESULT FIELDS

  • SYNC STATUS - a boolean as false only when not syncing
  • SYNC BLOCKS i. startingBlock - a hexcode of the integer indicating the block at which the import started (will only be reset, after the sync reached his head) ii. currentBlock - a hexcode of the integer indicating the current block, same as eth_blockNumber iii. highestBlock - a hexcode of the integer indicating the highest block

BODY

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": false
}
Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_syncing"
params
required
Array of any 0 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_syncing",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}

Filter Methods

eth_getFilterChanges

Returns a list of all logs based on filter ID since the last log retrieval

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getFilterChanges"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getFilterChanges",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": [
    ]
}

eth_getFilterLogs

Returns a list of all logs based on filter ID

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_getFilterLogs"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_getFilterLogs",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": [
    ]
}

eth_newBlockFilter

Creates a filter in the node, to notify when a new block arrives. To check if the state has changed, call eth_getFilterChanges.

Filter IDs will be valid for up to fifteen minutes, and can polled by any connection using the same v3 project ID.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_newBlockFilter"
params
required
Array of any

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_newBlockFilter",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_newFilter

Creates a filter object, based on filter options, to notify when the state changes (logs). To check if the state has changed, call eth_getFilterChanges

A note on specifying topic filters: Topics are order-dependent. A transaction with a log with topics [A, B] will be matched by the following topic filters:

  • [] - anything"
  • [A] - A in first position (and anything after)
  • [null, B] - anything in first position AND B in second position (and anything after)
  • [A, B] - A in first position AND B in second position (and anything after)"
  • [[A, B], [A, B]] - (A OR B) in first position AND (A OR B) in second position (and anything after)

Filter IDs will be valid for up to fifteen minutes, and can polled by any connection using the same v3 project ID.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_newFilter"
required
Array of objects 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_newFilter",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_newPendingTransactionFilter

Creates a filter to listen for new pending transactions that can be used with eth_getFilterChanges

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_newPendingTransactionFilter"
params
required
Array of any

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_newPendingTransactionFilter",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": "string"
}

eth_uninstallFilter

Destroys a filter based on filter IDNote: This should only be called if a filter and its notifications are no longer needed. This will also be called automatically on a filter if its notifications are not retrieved using eth_getFilterChanges for a period of time.

Authorizations:
path Parameters
projectId
required
string
Request Body schema: application/json
id
required
number
jsonrpc
required
string
Value: "2.0"
method
required
string
Value: "eth_uninstallFilter"
required
Array of strings 1 items

Responses

Request samples

Content type
application/json
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "method": "eth_uninstallFilter",
  • "params": [
    ]
}

Response samples

Content type
application/json
Example
{
  • "id": 0,
  • "jsonrpc": "2.0",
  • "result": true
}