Skip to main content
To verify an asset evidence from Track API, we have 3 ways to interact with the Blockchain network. As an example, we will use the asset from the following image: asset For all verification methods, the assetHash, timestamp, and networkId fields will be used. Additionally, for methods 2 and 3, the smartContract field will also be used. All of them are highlighted in red in the image.

​
Method 1: Interact with the TrustOS API

This is the simplest and most direct method once the integration with TrustOS is done, and the one we recommend for most cases. Essentially, you need to call the following endpoint of the Cert API: For more detailed information on how to make this call, you can refer to the technical documentation of the endpoint.

​
Method 2: Interacting with the corresponding block explorer

This method depends on the existence of a block explorer that allows the query of the Blockchain where the evidence has been registered. To do this, you need the address of the Smart Contract where the evidence has been registered (field smartContract) and use the block explorer corresponding to the network that appears in the networkId field. In this link the Smart Contract is shown in the block explorer. Next, you need to access the contract tab and check the available functions. The function to call is getEvidence and the parameters to pass are the assetHash and the timestamp of the evidence you want to verify. Finally, run the function with the Query button and it will show the result, which matches the hash field of the evidence. Etherscan AssetRepo read functions

​
Method 3: Directly querying the Blockchain

In Blockchain networks, all information is pseudopublic since anyone can read it. To interact directly with the Blockchain, we will use what is known as the JSON-RPC API. This is a communication protocol that facilitates interaction with Blockchain networks based on the Ethereum client. To make this protocol work, you need the so-called JSON-RPC-ENDPOINT. This is the “gateway” to interact with the Blockchain and is nothing more than an open connection to a node running the Ethereum-based Blockchain client that we need. Thanks to this communication method, you can query information such as the Ethereum client implemented by the desired Blockchain, or even the networkId of the Blockchain. An example of a call for the latter would be: 
curl -X POST '<JSON-RPC-ENDPOINT>' \
	--data '{
		"jsonrpc":"2.0",
		"method":"net_version",
		"params":[],
		"id":67
}'
If we use a Polygon’s JSON-RPC-ENDPOINT, the response will be 137. 
{
	"jsonrpc":"2.0",
	"id":67,
	"result":"137"
}
Now, for the specific case of verifying an evidence registered using Track API, the call that needs to be made is called eth_call, which executes a call to the Blockchain without creating a transaction. Since it is a read method, there will be no gas cost or network fees involved. The call would look like this: 
curl -X POST '<JSON-RPC-ENDPOINT>' \
	-H "Content-Type: application/json" \
	--data '{
		"jsonrpc": "2.0", 
		"method": "eth_call", 
		"params": [
			{
				"to": "<SMART_CONTRACT>", 
				"data": "<INFO>"
			},
			"latest"
		], 
		"id": 1
}'
The fields to fill in are as follows:
  • JSON-RPC-ENDPOINT
  • SMART_CONTRACT: Address of the Smart Contract where the evidence has been registered (field smartContract).
  • INFO: Hash of the function signature and the encoded parameters assetHash and timestamp.
To encode the parameters, you can use the following online tool, taking into account that the function of the Smart Contract to be called is: 
function getEvidence (string memory assetHash, uint256 timestamp) 
	public view returns (string memory)
encoder configuration encoded parameters Once all the parameters are correctly encoded, the call looks like this: 
curl -X POST '<JSON-RPC-ENDPOINT>' \
	-H "Content-Type: application/json" \
	--data '{
		"jsonrpc": "2.0",
		"method": "eth_call", 
		"params": [
			{
				"to": "0x552A9C294DaC07bbcbfa5E8D3e16152f6a71E03f",
				"data": "0xf74328fe00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000066b0bbe2000000000000000000000000000000000000000000000000000000000000004032343366616437633232336630613338353965383038626133323561323563623866386462326365346136333638663835343766366665393961663539313137"
			},
			"latest"
		], 
		"id": 1
}'
The response to this call, if done correctly, can be in 2 ways.
  • Evidence not found 
    {
	"jsonrpc": "2.0",
	"id": 1,
	"error": {
		"code": -32000,
		"message": "Execution reverted",
		"data": "0x09cea733"
	}
}
    The hexadecimal value 0x09cea733 corresponds to the error returned by the Smart Contract when the evidence is not found. The parameters entered do not match the records stored in the Blockchain.
  • Evidence found 
    {
	"jsonrpc": "2.0",
	"id": 1,
	"result": "0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000004039653037656564623861646566303465643037653462363436646166393061396632323962333963336532656566383433663263323166643232653233393530"
}
    The result, encoded, is the hash associated with that assetHash at that specific timestamp. To decode it, you can use the following online tool. decoder configuration decoded parameters As you can see, the decoded parameter matches the hash of the evidence, ensuring the immutability of the information.
⌘I