JSON-RPC API
In order for a software application to interact with the Xphere blockchain - either by reading blockchain data or sending transactions to the network - it must connect to an Xphere node.
For this purpose, every Xphere client implements a JSON-RPC specification, so there is a uniform set of methods that applications can rely on regardless of the specific node or client implementation.
JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. It defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments. It uses JSON (RFC 4627) as data format.
Client implementations
Xphere clients each may utilize different programming languages when implementing the JSON-RPC specification. See individual client documentation for further details related to specific programming languages. We recommend checking the documentation of each client for the latest API support information.
An internal API is also used for inter-client communication within a node - that is, it enables the consensus client and execution client to swap data. This is called the 'Engine API' and the specs are available on GitHub.
Execution client spec
Read the full JSON-RPC API spec on GitHub. This API is documented on the Execution API webpage and includes an Inspector to try out all the available methods.
Conventions
Hex value encoding
Two key data types get passed over JSON: unformatted byte arrays and quantities. Both are passed with a hex encoding but with different requirements for formatting.
Quantities
When encoding quantities (integers, numbers): encode as hex, prefix with "0x", the most compact representation (slight exception: zero should be represented as "0x0").
Here are some examples:
- 0x41 (65 in decimal)
- 0x400 (1024 in decimal)
- WRONG: 0x (should always have at least one digit - zero is "0x0")
- WRONG: 0x0400 (no leading zeroes allowed)
- WRONG: ff (must be prefixed 0x)
Unformatted data
When encoding unformatted data (byte arrays, account addresses, hashes, bytecode arrays): encode as hex, prefix with "0x", two hex digits per byte.
Here are some examples:
- 0x41 (size 1, "A")
- 0x004200 (size 3, "0B0")
- 0x (size 0, "")
- WRONG: 0xf0f0f (must be even number of digits)
- WRONG: 004200 (must be prefixed 0x)
The default block parameter
The following methods have an extra default block parameter:
When requests are made that act on the state of Xphere, the last default block parameter determines the height of the block.
The following options are possible for the defaultBlock parameter:
HEX String- an integer block numberString "earliest"for the earliest/genesis blockString "latest"- for the latest proposed blockString "safe"- for the latest safe head blockString "finalized"- for the latest finalized blockString "pending"- for the pending state/transactions
Examples
On this page we provide examples of how to use individual JSON_RPC API endpoints using the command line tool, curl. These individual endpoint examples are found below in the Curl examples section. Further down the page, we also provide an end-to-end example for compiling and deploying a smart contract using a Geth node, the JSON_RPC API and curl.
Curl examples
Examples of using the JSON_RPC API by making curl requests to an Xphere node are provided below. Each example includes a description of the specific endpoint, its parameters, return type, and a worked example of how it should be used.
The curl requests might return an error message relating to the content type. This is because the --data option sets the content type to application/x-www-form-urlencoded. If your node does complain about this, manually set the header by placing -H "Content-Type: application/json" at the start of the call. The examples also do not include the URL/IP & port combination which must be the last argument given to curl (e.g. 127.0.0.1:8545). A complete curl request including these additional data takes the following form:
curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545
Gossip, State, History
A handful of core JSON-RPC methods require data from the Xphere network, and fall neatly into three main categories: Gossip, State, and History. Use the links in these sections to jump to each method, or use the table of contents to explore the whole list of methods.
Gossip Methods
These methods track the head of the chain. This is how transactions make their way around the network, find their way into blocks, and how clients find out about new blocks.
State Methods
Methods that report the current state of all the data stored. The "state" is like one big shared piece of RAM, and includes account balances, contract data, and gas estimations.
History Methods
Fetches historical records of every block back to genesis. This is like one large append-only file, and includes all block headers, block bodies, uncle blocks, and transaction receipts.
- eth_getBlockTransactionCountByHash
- eth_getBlockTransactionCountByNumber
- eth_getUncleCountByBlockHash
- eth_getUncleCountByBlockNumber
- eth_getBlockByHash
- eth_getBlockByNumber
- eth_getTransactionByHash
- eth_getTransactionByBlockHashAndIndex
- eth_getTransactionByBlockNumberAndIndex
- eth_getTransactionReceipt
- eth_getUncleByBlockHashAndIndex
- eth_getUncleByBlockNumberAndIndex
JSON-RPC API Playground
You can use the playground tool to discover and try out the API methods. It also shows you which methods and networks are supported by various node providers.
JSON-RPC API Methods
web3_clientVersion
Returns the current client version.
Parameters
None
Returns
String - The current client version
Example
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}'
// Result
{
"id":67,
"jsonrpc":"2.0",
"result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1"
}
web3_sha3
Returns Keccak-256 (not the standardized SHA3-256) of the given data.
Parameters
DATA- The data to convert into a SHA3 hash
params: ["0x68656c6c6f20776f726c64"]
Returns
DATA - The SHA3 result of the given string.
Example
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}'
// Result
{
"id":64,
"jsonrpc": "2.0",
"result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad"
}
net_version
Returns the current network id.
Parameters
None
Returns
String - The current network id.
The full list of current network IDs is available at chainlist.org. Some common ones are:
1: Xphere Mainnet5: Goerli testnet11155111: Sepolia testnet
Example
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}'
// Result
{
"id":67,
"jsonrpc": "2.0",
"result": "3"
}
net_listening
Returns true if client is actively listening for network connections.
Parameters
None
Returns
Boolean - true when listening, otherwise false.
Example
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'
// Result
{
"id":67,
"jsonrpc":"2.0",
"result":true
}
net_peerCount
Returns number of peers currently connected to the client.
Parameters
None
Returns
QUANTITY - integer of the number of connected peers.
Example
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}'
// Result
{
"id":74,
"jsonrpc": "2.0",
"result": "0x2" // 2
}
eth_protocolVersion
Returns the current Xphere protocol version. Note that this method is not available in Geth.
Parameters
None
Returns
String - The current Xphere protocol version
Example
// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}'
// Result
{
"id":67,
"jsonrpc": "2.0",
"result": "54"
}
eth_syncing
Returns an object with data about the sync status or false.
Parameters
None
Returns
The precise return data varies between client implementations. All clients return False when the node is not syncing, and all clients return the following fields.
Object|Boolean, An object with sync status data or FALSE, when not syncing:
startingBlock:QUANTITY- The block at which the import started (will only be reset, after the sync reached his head)currentBlock:QUANTITY- The current block, same as eth_blockNumberhighestBlock:QUANTITY- The estimated highest block
However, the individual clients may also provide additional data. For example Geth returns the following:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"currentBlock": "0x3cf522",
"healedBytecodeBytes": "0x0",
"healedBytecodes": "0x0",
"healedTrienodes": "0x0",
"healingBytecode": "0x0",
"healingTrienodes": "0x0",
"highestBlock": "0x3e0e41",
"startingBlock": "0x3cbed5",
"syncedAccountBytes": "0x0",
"syncedAccounts": "0x0",
"syncedBytecodeBytes": "0x0",
"syncedBytecodes": "0x0",
"syncedStorage": "0x0",
"syncedStorageBytes": "0x0"
}
}