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

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.