> For the complete documentation index, see [llms.txt](https://docs.coti.io/coti-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coti.io/coti-documentation/privacy-on-demand/reference-data-types.md).

# Reference: data types (it/ct/gt)

Canonical Solidity source: [`MpcCore.sol`](https://github.com/coti-io/coti-contracts/blob/main/contracts/utils/mpc/MpcCore.sol) in **`@coti-io/coti-contracts`**.

PoD uses three type families. Mixing them at the wrong boundary breaks signature validation, callback decode, or privacy guarantees. For plain-language definitions, see the [Glossary](/coti-documentation/privacy-on-demand/glossary.md).

## Why the split exists

| Family    | Role                                                                             |
| --------- | -------------------------------------------------------------------------------- |
| **`it*`** | User-submitted encrypted input plus signature material                           |
| **`ct*`** | Encrypted value stored on EVM and decrypted client-side with the account AES key |
| **`gt*`** | Private compute-domain value used on COTI                                        |

## `it*` (input payload)

Valid on EVM entrypoints and in `MpcAbiCodec` payloads.

| Type                   | Solidity shape                                     | Typical use                   |
| ---------------------- | -------------------------------------------------- | ----------------------------- |
| `itBool`               | `{ ctBool ciphertext; bytes signature; }`          | Signed encrypted bool input   |
| `itUint8` … `itUint64` | `{ ctUint* ciphertext; bytes signature; }`         | Signed encrypted scalar input |
| `itUint128`            | `{ ctUint128 ciphertext; bytes[2] signature; }`    | Signed 128-bit input          |
| `itUint256`            | `{ ctUint256 ciphertext; bytes[2][2] signature; }` | Signed 256-bit input          |
| `itString`             | `{ ctString ciphertext; bytes[] signature; }`      | Signed encrypted string       |

## `ct*` (ciphertext output)

Valid in EVM storage, callback payloads, and read APIs.

| Type                   | Solidity shape                                                  | Off-chain decrypt shape                      |
| ---------------------- | --------------------------------------------------------------- | -------------------------------------------- |
| `ctBool` … `ctUint128` | `type ctUint* is uint256`                                       | single `uint256` word (`bigint` or `0x` hex) |
| `ctUint256`            | `struct { ctUint128 ciphertextHigh; ctUint128 ciphertextLow; }` | `{ ciphertextHigh, ciphertextLow }` tuple    |
| `ctString`             | `struct { ctUint64[] value; }`                                  | array of 64-bit cells                        |

> **Note:** `ctUint128` is a user-defined value type wrapping one `uint256` word — not a struct of two limbs. Only `ctUint256` uses a two-limb struct.

## `gt*` (private compute domain)

Valid only on COTI-side contracts and executor operations. Never expose `gt*` in EVM public interfaces.

| Type                   | Solidity shape                              |
| ---------------------- | ------------------------------------------- |
| `gtBool` … `gtUint128` | `type gtUint* is uint256`                   |
| `gtUint256`            | `struct { gtUint128 high; gtUint128 low; }` |
| `gtString`             | `struct { gtUint64[] value; }`              |

## Conversion operations (`MpcCore`)

* `onBoard(ct*) → gt*` — move ciphertext into compute domain
* `offBoard(gt*) → ct*` — contract-held ciphertext
* `offBoardToUser(gt*, address) → ct*` — user-targeted decryptable ciphertext

## End-to-end boundary flow

1. Client builds `it*`.
2. EVM accepts `it*` and sends a request through the Inbox.
3. `MpcAbiCodec.reEncodeWithGt(...)` validates and converts `it*` to `gt*` argument shape.
4. COTI logic computes on `gt*`.
5. COTI returns `ct*`.
6. EVM callback stores `ct*`.
7. Client decrypts `ct*` with the account AES key.

## Critical gotcha: EVM `it*` maps to COTI `gt*`

For custom COTI-side logic:

* EVM function accepts `itUint64 amount`
* COTI function must be declared `gtUint64 amount`

Declaring COTI parameters as `it*` for methods invoked through the Inbox pipeline will not match ABI expectations.

## Required usage rules

1. EVM private inputs: `it*`
2. EVM private results: `ct*`
3. COTI private compute: `gt*`
4. Keep width consistent (`itUint64 → gtUint64 → ctUint64`)
5. Do not store plaintext sensitive values on EVM

## Frequent mistakes

* Wrong decrypt type or AES key for the stored `ct*` width
* Mismatch between frontend `DataType` and Solidity type width
* Decoding callback tuple as the wrong `ct*` type
* Skipping `requestId` correlation in callback handlers

## See also

* [TypeScript PoD SDK](/coti-documentation/privacy-on-demand/typescript-pod-sdk.md) — `DataType` enum and `CotiPodCrypto`
* [Reference: PodLib primitives](/coti-documentation/privacy-on-demand/reference-podlib-and-primitives.md)
* [Tutorial: custom privacy logic with PoD](/coti-documentation/privacy-on-demand/tutorial-custom-logic.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coti.io/coti-documentation/privacy-on-demand/reference-data-types.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.