> 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/identity-onchainid/identity-types-and-factory-gating.md). # Identity types and factory gating Every ONCHAINID is created by the `IdentityFactory` and carries a type: an individual, an organization, a Claim Issuer, an asset. The type is a trust signal that the rest of the protocol relies on, so the right to create some types is gated. This page lists the types, the policy that governs each one, and what the factory does when it creates an identity. ## Why the type matters Some types carry privilege. A `CLAIM_ISSUER` identity can have its claims accepted on other identities. An `ASSET` identity represents a token. If anyone could create an identity of any type, the type would mean nothing. Two rules make it trustworthy. * **The factory records the type, once.** The type is written at creation and has no update path. Contracts that depend on the type read it from the factory with `identityTypeOf(identity)`, never from the identity. An identity is a modular account and could answer anything about itself. The factory's record cannot be changed by the identity. * **Creation of a privileged type is gated.** Only an authorized party can create it. An address that the factory did not deploy has type zero. It is not an ONCHAINID for the purposes of the protocol: it cannot link wallets, and it cannot write claims onto other identities on its own authority. ## The eight types | Type | Value | Represents | | ------------------ | ----- | -------------------------------------------------------------------------------- | | `ASSET` | 1 | A token. The identity is bound to the token contract. | | `INDIVIDUAL` | 2 | A natural person. | | `CORPORATE` | 3 | A legal entity. | | `IOT` | 4 | A device. | | `CLAIM_ISSUER` | 5 | A party that signs claims about other identities. | | `SMART_CONTRACT` | 6 | A venue, a protocol, a vault, an escrow. The identity is bound to that contract. | | `PUBLIC_AUTHORITY` | 7 | A regulator, a court, a government issuer. | | `AI_AGENT` | 8 | An autonomous agent. | ## The policy of a type Each type is registered in the factory with a policy of three settings, and with the modules its identities are deployed with. | Setting | Meaning | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Creation role** | The role a caller must hold to create an identity of this type for another account, with `createIdentityFor`. | | **Self-deployable** | Whether an account may create an identity of this type for itself, with `createIdentity`. | | **Single binding** | Whether the identity is bound to exactly one address for its whole life. Such an identity keeps the account set at creation and can never link or revoke another. | | **Modules** | The modules installed on every identity of this type. The caller of a creation function passes no modules. | A type that is not registered cannot be created by either function. The policies and the module sets are administered by Network governance, through the AccessManager of the network. ### The reference policy | Type | Self-deployable | Created for another account by | Single binding | | ------------------ | --------------- | ------------------------------------------------------------------------------------------ | -------------- | | `ASSET` | No | The `ASSET_DEPLOYER` role, held by the `TREXFactory` and by the parties that deploy suites | Yes | | `INDIVIDUAL` | Yes | An operator that onboards participants | No | | `CORPORATE` | Yes | An operator that onboards participants | No | | `IOT` | Yes | An operator that onboards participants | No | | `CLAIM_ISSUER` | No | The Claim Issuer admin role | No | | `SMART_CONTRACT` | No | A role granted by Network governance | Yes | | `PUBLIC_AUTHORITY` | No | The public authority role | No | | `AI_AGENT` | Yes | An operator that onboards participants | No | The reasoning behind it: * **Participation is open where it is safe.** Anyone can create an `INDIVIDUAL`, `CORPORATE`, `IOT` or `AI_AGENT` identity for itself. The caller becomes the account of its own identity, so there is nothing to abuse. * **Creating for someone else is restricted.** A wallet's binding to an identity is permanent. If anyone could create an identity for any wallet, a stranger could bind a wallet to an identity its owner never asked for, and block that wallet from every other identity. Third-party onboarding is therefore reserved to operators that hold the creation role: the agents of an Issuer that onboard its investors, and Claim Issuers. * **Contract-shaped types are never self-deployed.** An `ASSET` or `SMART_CONTRACT` identity represents a contract, not the caller. The contract cannot sign, so the creation role is the only gate, and the identity is bound to that single address. * **Standing has to be granted.** A `CLAIM_ISSUER` or `PUBLIC_AUTHORITY` identity cannot be self-deployed. Its type means something because not anyone could have created it. ## Two ways to create an identity | | `createIdentity` | `createIdentityFor` | | ------------------------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Who calls** | The account the identity is for | A third party holding the creation role of the type | | **Allowed when** | The type is self-deployable | The caller holds the role | | **First linked account** | The caller | The account named in the call | | **Keys** | Chosen by the caller | For a signing type, every key must belong to the named account, and that account must end up as the only `MANAGEMENT` key | The last row is what makes third-party onboarding safe. The account signs nothing, so an operator can onboard an investor's wallet without asking for a signature. In exchange, the factory guarantees that the new identity is managed by the wallet it was created for and by nobody else. The party that paid for the deployment holds no key on it. The owner adds more keys afterward. Single-binding types represent a contract that cannot sign. They skip this check and rely on the creation role. ### Who creates the identity of an investor Both ways are used for `INDIVIDUAL` and `CORPORATE` identities. * **The participant creates its own identity**, from its wallet. * **An operator creates it for the participant.** An agent that onboards investors for an Issuer, or a Claim Issuer about to issue a claim, meets a wallet that has no linked identity. It creates the identity for that wallet. The wallet is the first `MANAGEMENT` key and the first linked account, and the operator keeps no key. ## What creation does ```mermaid sequenceDiagram participant C as Caller participant F as IdentityFactory participant ID as New ONCHAINID participant V as ERC734Validator C->>F: createIdentity or createIdentityFor F->>F: type is registered, caller is allowed F->>ID: deploy at the deterministic address ID->>ID: set type, install the modules of the type ID->>V: register the keys F->>V: at least one MANAGEMENT key that can sign F->>F: record the type F->>F: make the identity resolve to itself F->>F: link the first account F-->>C: IdentityDeployed ``` 1. **Check the policy.** The type is registered. For `createIdentity`, it is self-deployable. For `createIdentityFor`, the caller holds the creation role. 2. **Derive the address.** The address is computed from the identity type, the salt, the first account and the keys. The modules are not part of it, so a change in the module set of a type does not move the addresses of future identities. 3. **Deploy and initialize.** The identity is deployed as a beacon proxy through CREATE3. Its type, its modules and its keys are set in the same step. 4. **Check the result.** The identity has at least one `MANAGEMENT` key that can sign. The factory reads this from the key registry directly. 5. **Record the type.** From this point `identityTypeOf` answers for the identity. 6. **Resolve the identity to itself.** The factory registers the identity's own address so that `getIdentity` and `getIdentityIncludingRevoked` return the identity for it, with the status `Active`. The identity can hold tokens without any wallet. 7. **Link the first account.** The caller, or the named account, becomes the first wallet linked to the identity. A creation needs a non-empty salt and at least one key. The same inputs produce the same address on every EVM chain where the factory sits at the same address, so a participant has one identity address across chains. ## Where the type is used | Reader | What it does with the type | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `TREXRegistry` | Selects the claim topics an identity must satisfy. An Issuer can require one set of topics from an `INDIVIDUAL` and another from a `CORPORATE`. | | `ReputationRegistry` | Applies a default reputation score per type to identities created by the factory. | | `ERC734Validator` | Lets an identity add its claims to other identities without a key grant only if its type is `CLAIM_ISSUER`, and its reputation is sufficient. | | `IdentityFactory` | Applies single binding when linking and revoking wallets. | | `TREXFactory` | Creates the `ASSET` identity of each token it deploys, bound to the token's address and managed by the token suite's AccessManager. | ## The identity of a token A token has an ONCHAINID of its own, of type `ASSET`. It is where claims about the asset itself are attached, and it is what links the token to the identity layer. * It is created by the `TREXFactory` when the token suite is deployed, through `createIdentityFor`. The factory holds the `ASSET_DEPLOYER` role for that purpose. The Issuers and tokenization providers that deploy suites hold the same role: it also gates the deployment itself. Creating an asset identity apart from a token deployment takes the same role, and is uncommon. * Its single linked account is the token contract. `getIdentity` for the token's address returns this identity. * Its `MANAGEMENT` key is the AccessManager of the token suite, so the Issuer governs the token's identity through the same roles as the token. ## The identity of a venue contract A contract through which an asset is traded or used, such as the DINO contracts, has an ONCHAINID of type `SMART_CONTRACT`, bound to that contract. The identity carries the claims the asset requires, like the identity of any participant. What the venue needs depends on what it does with the tokens. | The venue | It needs to be | | ------------------------------------------------------------------ | -------------------------------- | | Moves tokens for holders with `transferFrom`, without holding them | An accepted spender of the asset | | Holds tokens in escrow | An eligible holder of the asset | See [Identity-based control and spender compliance](/token-and-register/identity-based-control-and-spender-compliance.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 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/identity-onchainid/identity-types-and-factory-gating.md?ask=&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.