Clique Manifest

The Clique Manifest details the metadata for each task including I/O schemas, proof types, and optional [code]or[tasks] sections.

The manifest itself is written in TOML. If you are not familiar with it, you can review this cheatsheet in 5 minutes.

Phantom and Non-Phantom task

The primary distinction between these two types lies in whether the task is dispatched to an executor.

Phantom tasks do not involve execution logic; instead, they focus on transforming arguments that explain how values are passed between tasks. Only Schema is considered a phantom task for now.

Here is an example manifest of a phantom task:

spec-version = "1"
name = "yourOrganization_customRequest"
type = "Schema"

proof-type = ["TEE"]

[types.Transformation]
from = { type = "string", description = "json pointer to field in response" }
soltype = { type = "string", description = "solidity type" }

[input]
url = { type = "string", description = "Request url" }
encoding = { type = "Transformation[]", description = "encoding format" }

[output]
response = { ref = "$tasks.clique_httpsRequest.response" }

[[tasks]]
name = "clique_httpsRequest"
proof-preference = "TEE"
[tasks.input]
url = "$input.url"
encoding = "$input.encoding"

Non-Phantom tasks include Dynamic and BuiltIn tasks. BuiltIntasks are maintained by Clique and are currently restricted for other developers. Dynamic tasks, on the other hand, can be built by anyone with the correpsponding evm or wasm bytecode sent to executors in the Clique Network for computation and proof generation. Each Dynamictask must contain a [code] section.

Value Types

In version 1 of the TOML manifest, the following types are supported:

• bool

• string

• bytes

• address

• float

• i8, i16, i32, i64, i128, i256

• u8, u16, u32, u64, u128, u256

• {type}[]

  • The array type, for example, an array of string, is denoted asstring[].

• custom type

Custom Type

In addition to the basic types, you can add a [types] section to define custom types, specifying the structure of your custom types within it. Currently, custom types only support the use of basic types and do not allow for nested custom types.

For instance, if you wish to add a custom type named Transformation with two fields of type string, you would do the following:

[types.Transformation]
from = { type = "string", description = "json pointer to field in response" }
soltype = { type = "string", description = "solidity type" }

Then, you can incorporate your custom type in the [Input] or [Output] sections of your manifest:

[input]
field1 = { type = "Transformation", description = "single custom type" }
field2 = { type = "Transformation[]", description = "an array of the custom type" }

Type Mapping

Here is the mapping correspondence between our clique value types and JSON types, Solidity types, as well as Rust types:

Clique types	Json types	Solidity types	Rust types
bool	bool	bool	bool
string	string	string	String
bytes	hex string with 0x prefix	bytes	Vec<u8>
address	hex string with 0x prefix	address	clique_types::value::Address
{type}[]	array	array	Vec<type>
float	number	Not Supported	f64
i8	number	int8	i8
i16	number	int16	i16
i32	number	int32	i32
i64	number	int64	i64
i128	decimal string	int128	i128
i256	decimal string	int256	clique_types::value::Int256
u8	number	uint8	u8
u16	number	uint16	u16
u32	number	uint32	u32
u64	number	uint64	u64
u128	decimal string	uint128	u128
u256	decimal string	uint256	clique_types::value::Uint256
custom type	object	struct	struct

Built-In variables

$input

• The task input object

$tasks

• The output of each dependency task. You can reference a task output by its id.

Manifest Structure

name

• Type: string

• Unique identifier for each task in the Clique Network, The recommended format is {yourNamespace}_{taskName}.

spec-version

• Type: "1"

• This refers to the spec version of this manifest file, which should be fixed as "1" for now.

type

• Type: "Schema" | "Dynamic" | "BuiltIn"

• This refers to the task type. See the Phantom and Non-Phantom section for details. TheBuiltIn task format is only used by Clique right now to publish official tasks, so you should specify Dynamic here.

proof-type

• Type: array

• This refers to the supported proof type for this task. Currently, only the "TEE" proof type is supported.

input

• Type: table

• This describes the required arguments for this particular task. input will be validated before the task is actually dispatched to an executor.

input.{field}.type

• Type: string

• This refers to the value type of this field.

input.{filed}.description

• Type: string

• Field description. Optional.

output

• Type: object

• The data structure returned by this task.

output.{filed}.type

• Value type. Required if it's a non-phantom task.

output.{field}.description

• Field description. Optional.

output.{field}.ref

• Type: reference string

• Reference to other field. Required for Schema task. If the ref is specified, refrain from setting the type as the ref inherently determines the type.

tasks

• Type: array

• Dependencies. Required for Schema task.

[[tasks.id]]

• Type: string

• The unique id of its dependencies. Use [[tasks.name]] by default if it's empty.

[[tasks.name]]

• Type: string

• Name of dependent task.

[[tasks.proof-perference]]

• Type: "TEE"

• This refers to the preferred proof type for the task, which must be one of the proof types supported by the task.

[[tasks.input]]

• Type: table

• Transformation of input or output from others to required parameters.

[code.type]

• Type: "EVM" | "WASM"

• Specify the type of bytecode.

[code.data]

• Type: string

• This current supports two types of values depending on the VM that's used

  • evm: Hex-encoded bytecode for evm

  • wasm: Hex-encoded bytecode for WAT or WASM

[code.abi]

• Type: string

• This is the ABI of the entry point function. Currently it's EVM only.

types

• Type: table

• This refers to the custom types.

types.{custom-type-name}.{field}.type

• Type: string

• This refers to the value type of this field.

types.{custom-type-name}.{field}.description

• Type: string

• Field description. Optional.

Examples

Here is an exmaple of Dynamic EVM task:

spec-version = "1"
name = "yourOrganization_dynamicTask"
type = "Dynamic"

proof-type = ["TEE"]

[types.MyCustomType]
price = { type = "u64", description = "product price" }
name = { type = "string", description = "product name" }

[input]
boolInput = { type = "bool", description = "bool" }
stringInput = { type = "string", description = "string" }
bytesInput = { type = "bytes", description = "bytes" }
addressInput = { type = "address", description = "address" }
floatInput = { type = "float", description = "float number" }
i8NumberInput = { type = "i8", description = "description is optional" }
u8NumberInput = { type = "u8" }
i16NumberInput = { type = "i16" }
u16NumberInput = { type = "u16" }
i32NumberInput = { type = "i32" }
u32NumberInput = { type = "u32" }
i64NumberInput = { type = "i64" }
u64NumberInput = { type = "u64" }
i128NumberInput = { type = "i128" }
u128NumberInput = { type = "u128" }
i256NumberInput = { type = "i256" }
u256NumberInput = { type = "u256" }
arrayInput = { type = "i64[]", description = "i64 array" }
strArrayInput = { type = "string[]", description = "string array" }
customArrayInput = { type = "MyCustomType[]", description = "custom type array" }
customInput = { type = "MyCustomType", description = "single custom type" }

[output]
numberOutput = { type = "i256", description = "i256 number" }

[code]
type = "EVM"
data = "6080604052348015600f57600..."
abi = '[{"type":"function","name":"evaluate","inputs":...,"outputs":..., ...}]'

Here is an exmaple of Dynamic WASM task:

https://github.com/CliqueOfficial/template-wasm

WASM does not support address, i256 or u256.