Decoding Kernel Responses in Solidity

Prerequisites

• Supported OpenAPI Specifications

---

This page explains how to decode responses from kernel(s) in your Solidity smart contract. The decoding part of Solidity plays a crucial role in both your smart contract and Token Authority. Following the methods presented on this page will allow your smart contract and/or Token Authority to see the responses from kernels.

It is worth mentioning that the decoding section can be used for both TA and registered smart contracts.

---

On-Chain Kernel Responses

Decoding on-chain is fairly simple.

Let's use kernel 337 as an example.

As we can see from the figure above, the Function Return Type of this on-chain kernel is uint256.

The decoding part of Solidity is shown in the example snippet below.

Solidity

// ...
foo = abi.decode(kernelResponses[i].result, (int256));
// ...

Off-Chain Kernel Responses

We recommend visiting the Supported OpenAPI Specifications page (click here) to understand more about how to decode off-chain kernels.

1. Variable Names Matter

The names of variables from the off-chain response matter.

Click here to read more

2. Float and Number

The number value from off-chain kernels can be decoded using int256.

The output after decoding on Solidity would give the value in 18 decimal places.

For example, a value of 12.34 from an off-chain kernel would be 12340000000000000000.

This includes the float value as well.

---

Example

The below table shows a line of code which might be helpful to decode off-chain kernel(s) responses.

Example Endpoint: https://api.mock.com/submit-passport

Method: GET

Response:

{

"name": "John"

}

This example would fall into the first case of the below table.

It is worth mentioning that the decoding part can be used in both the TA and registered smart contract.

The variable names in your smart contract do not have to match those in the kernel response.

However, aligning them can make tracking easier.

Type	Response	Solidity
number (no decimal places)	{ "number": 123 }	foo = abi.decode(kernelResponses[i].result, (int256));
float	{ "number": 123.456 }	foo = abi.decode(kernelResponses[i].result, (int256));
boolean	{ "allowed": true }	foo = abi.decode(kernelResponses[i].result, (bool));
string	{ "hello": "world" }	struct FooStruct { string fooString } // ... foo = abi.decode(kernelResponses[i].result, (FooStruct));
null	{ "hello": null }	Null values require a precise decoding method Click here to read more
array	{ "group": [123,456,789] }	foo = abi.decode(kernelResponses[i].result, (int256[]));
simple response	"hello"	Simple responses, such as in the example ,can also be decoded Click here to read more
multiple fields object	{ "allowed": true, "hello": "world" }	struct FooStruct { bool foo1 string foo2 } // ... foo = abi.decode(kernelResponses[i].result, (FooStruct));
multiple fields object 2	{ "group": [123,456,789], "hello": "world" }	struct FooStruct { int256[] foo1 string foo2 } // ... foo = abi.decode(kernelResponses[i].result, (FooStruct));
nested object	{ "alpha": { "allowed": true, "hello": "world" }, "group": [123,456,789] }	struct FooStruct { Alpha foo1 int256[] foo2 } struct Alpha { bool alp string beta } // ... foo = abi.decode(kernelResponses[i].result, (FooStruct));

---

Variable Names

What?

The decoding part of off-chain kernels will have to be sorted in alphabetical order.

Why?

The reason why variable names from off-chain kernels matter is because of when the KRNL node packs the responses from off-chain kernels all together. Even though the API response does not return with the alphabetical order, the decoding part of the Solidity smart contract still requires it to be decoded alphabetically.

How?

Let's use the mock off-chain response as in the below example.

Response

{
  "zebra": "text",
  "apple": true,
  "krnl": "text"
}

The decoding part in Solidity should be in the below snippet.

Solidity

struct Foo {
  bool apple
  string krnl
  string zebra
}
// ...

---

Null

What?

When it comes to null value responses, it is important to handle responses precisely.

Null value responses from the off-chain kernels could potentially cause the transaction to fail if the decoding part of Solidity does not handle the response properly.

Why?

The Solidity language does not offer a "null" value.

How?

A kernel ID of ABC will be used as an example of a simple off-chain kernel.

When the value is null, it will return the default value of the actual type from the OpenAPI schema.

We have to observe the response data type when it does not come back with null value.

Let's hypothetically say that kernel ABC can give us either a string value or null value.

Response 1

Response

{
  "kernelabcresponseexample": null
}

Response 2

Response

{
  "kernelabcresponseexample": "This is a simple sentence."
}

This means that the response can be either "null" or "string".

The decoding part in the Solidity smart contract would have to be string.

Decoding

Solidity

// ...
foo = abi.decode(kernelResponses[i].result, (string));
// ...

---

Simple Responses

What?

When it comes to simple responses from off-chain kernels, such as in the code snippet below, KRNL nodes can also handle and send them to the Solidity smart contract.

Fundamentally, this is a rare incident that may take place when calling a request to an API, but it does not mean that it cannot happen.

string

"hello"

boolean

true

number

123456

The code-base of the KRNL node will handle these types of responses similar to the object responses.

See below for a simpler explanation.

string

{
  "text": "hello"
}

boolean

{
  "allowed": true
}

number

{
  "text": 123456
}

How?

The decoding part of a Solidity smart contract should be straightforward.

string

foo = abi.decode(kernelResponses[i].result, (string));

boolean

foo = abi.decode(kernelResponses[i].result, (bool));

number

foo = abi.decode(kernelResponses[i].result, (int256));

The reason why the node can handle the simple responses, like in this scenario, is not because it happens automatically, but because our team has already handled this type of response.

---