> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/reference/identity-suite.md).

# Identity Suite

The identity suite is ONCHAINID: the contracts that give every participant and every asset an on-chain identity, with its keys, its claims and its wallets. This section has one page per contract: every external function, who can call it, what it reverts with, and the events it emits. The pages are written from the code of the `develop` branch of the ONCHAINID repository. The concepts are in [Identity: ONCHAINID](/identity-onchainid.md).

### The contracts

| Page                                                                                      | Contract                                           | Deployed as                                                                                          |
| ----------------------------------------------------------------------------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| [Identity](/reference/identity-suite/identity.md)                                         | `Identity`, with `SmartAccount` and `KeyManager`   | One beacon proxy per identity, by the `IdentityFactory`. Every identity runs the same implementation |
| [ERC734Validator](/reference/identity-suite/erc734validator.md)                           | `ERC734Validator`                                  | Once per network. It holds the keys and the claims of every identity                                 |
| [KeyApprovalModule](/reference/identity-suite/keyapprovalmodule.md)                       | `KeyApprovalModule`                                | Once per network. It holds the execution queue of every identity that installs it                    |
| [RecoveryModule](/reference/identity-suite/recoverymodule.md)                             | `RecoveryModule`                                   | Once per network. It holds the guardians of every identity that installs it                          |
| [IdentityFactory](/reference/identity-suite/identityfactory.md)                           | `IdentityFactory`                                  | Once per network. It deploys identities and keeps the global record of wallets                       |
| [ReputationRegistry](/reference/identity-suite/reputationregistry.md)                     | `ReputationRegistry`                               | Once per network                                                                                     |
| [EASClaimIssuer](/reference/identity-suite/easclaimissuer.md)                             | `EASClaimIssuer`                                   | Once per network, per EAS deployment it reads                                                        |
| [Errors of the identity suite](/reference/identity-suite/errors-of-the-identity-suite.md) | The library `Errors` and the errors of the modules |                                                                                                      |

### How the contracts fit

* **An identity is an account.** `Identity` is an ERC-7579 smart account behind a beacon proxy. It holds tokens, executes calls and installs modules.
* **Its state lives in shared modules.** Keys and claims are stored in the `ERC734Validator`, under the address of the identity. The execution queue is in the `KeyApprovalModule`, the guardians in the `RecoveryModule`. One deployment of each module serves every identity.
* **Calls reach the modules through the identity.** An integrator calls the identity. The identity answers key reads itself and routes the claim functions, `execute` and `approve` to the module that serves them. A function that a module has and the identity does not route cannot be called on the identity.
* **The factory is the global registry.** `IdentityFactory` creates identities, records the type of each one, and records which wallet is linked to which identity. The `TREXRegistry` of every asset reads it.

### Conventions shared by every contract

* **Keys.** A key is identified by `keyHash = keccak256(signerData)`. For an address, `signerData` is its 20 bytes. For a key behind an ERC-7913 verifier, it is the verifier address followed by the public key.
* **Purposes.** `MANAGEMENT` 1, `ACTION` 2, `CLAIM_SIGNER` 3, `ENCRYPTION` 4, `CLAIM_ADDER` 5, `PROPOSER` 6. `MANAGEMENT` satisfies every purpose check.
* **Key types.** `ECDSA` 1, `RSA` 2, `WEBAUTHN` 3, `MODULE` 4, `ACCESS_MANAGER` 5.
* **Identity types.** `ASSET` 1, `INDIVIDUAL` 2, `CORPORATE` 3, `IOT` 4, `CLAIM_ISSUER` 5, `SMART_CONTRACT` 6, `PUBLIC_AUTHORITY` 7, `AI_AGENT` 8.
* **Wallets.** The factory takes a wallet as `bytes`: an ERC-7930 interoperable address in canonical form, on any chain.
* **Access control.** The functions of the factory, the reputation registry and the EAS adapter that are marked "Network governance" are restricted by the access manager of the network. The functions of an identity are gated by its own keys.
* **Errors.** Custom errors are declared in the library `Errors`, and a few in the modules themselves. They are listed in [Errors of the identity suite](/reference/identity-suite/errors-of-the-identity-suite.md).

The reading conventions of the function tables are those of the [Token Suite](/reference/token-suite.md) section.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.t-rex.network/reference/identity-suite.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
