Formatting RPC Call Data

When we make the requests to the contracts, we have to convert various values into different formats. For example converting the desired round ID to a uint80.

To assist in accomplishing this, there are a couple online tools that we can utilize.

Below are links to the external sites and examples on how to format the data to include in your RPC calls.

Converting Request Types to Hex

We will need to convert each of the request types to their 4 bit (eight character) hex value

To do this, simply navitgate to emn178.github.io/online-tools/keccak_256.html and copy the desired request into the top box and copy the first 8 characters in the bottom box.

We will want to append a leading 0x in front of the request data.

Example below:

Let's say we want to query getAnswer for round number 92233720368547771539.

We'd need to convert getAnswer(uint256) to the first 4 bytes of its hex value, which is b5ab58dc, and then with a leading 0x, it would be 0xb5ab58dc.

For some requests, we'll also need to include specific data in our read/write request to the contract.

In that case, we would need to convert that data to the expected format before sending.

Convert Request Data To Different Types

Maintaining the above example, we will need to include the desired round number to get the on-chain response from the Chainlink Nodes.

We can make use of the tooling available at adibas03.github.io/online-ethereum-abi-encoder-decoder/#/encode to convert our data to any of the expected types.

In this example, we will need to convert our desired round number, 92233720368547771514, to a uint256.

the uint256 equivalant of 92233720368547771514 is 000000000000000000000000000000000000000000000005000000000000347a

Formatting the Request Data

Now that we have the necessary data to include in our request, we need to combine it into a single hex value.

To accomplish this, we start with the desired call name, in this case 0xb5ab58dc .

Then we append the round ID we converted, 000000000000000000000000000000000000000000000005000000000000347a, to the end of it.

Resulting in the request data below:

0xb5ab58dc000000000000000000000000000000000000000000000005000000000000347a