> 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/an-identity-that-is-also-an-account.md).
# An identity that is also an account
An ONCHAINID is the on-chain identity of a participant: an investor, an issuer, a Claim Issuer, a venue, a token. It holds the keys its owner controls and the claims that trusted parties have attested about it. It is also an ERC-7579 smart account, so it holds assets, executes calls and validates signatures. A participant does not only own an identity and point wallets at it. A participant acts through it.
## What an ONCHAINID is
| It | How |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Holds keys** | Signers registered with purposes: manage the identity, act for it, sign claims. See [Keys, purposes and signers](/identity-onchainid/keys-purposes-and-signers.md). |
| **Holds claims** | Signed attestations about the identity, issued by Claim Issuers. See [Claims: issuance, validity, revocation](/identity-onchainid/claims-issuance-validity-revocation.md). |
| **Holds assets** | The identity is an account with an address. Tokens sent to that address belong to the identity. |
| **Acts** | It executes calls to other contracts, on the instruction of its keys, and it signs as itself. |
| **Links wallets** | Other addresses, on any chain, are bound to it and resolve to it. See [Wallet linking and the global identity registry](/identity-onchainid/wallet-linking-and-the-global-identity-registry.md). |
| **Has a type** | Individual, corporate, Claim Issuer, asset and others, recorded at creation. See [Identity types and factory gating](/identity-onchainid/identity-types-and-factory-gating.md). |
In ONCHAINID 2.x the identity was a container: a contract that stored keys and claims for other contracts to read. It is now an account in the full sense, with its behavior assembled from installable modules.
## How it is built
```mermaid
flowchart TB
F["IdentityFactory
deploys identities, records their type,
links wallets"] -->|"creates"| ID
subgraph ID["One ONCHAINID, a beacon proxy"]
direction TB
I["Identity
type, version, one-shot setup"]
SA["SmartAccount
ERC-7579 account: modules and execution"]
KM["KeyManager
ERC-734 entry points"]
I --- SA
SA --- KM
end
subgraph MOD["Modules, one deployment shared by all identities"]
V["ERC734Validator
key registry, claim registry,
user-operation validation"]
K["KeyApprovalModule
execute and approve queue"]
R["RecoveryModule
guardians"]
end
KM -->|"keys"| V
SA -->|"claims"| V
SA -->|"execute, approve"| K
SA -.->|"optional"| R
```
The account is built in three layers. Each has one job.
| Layer | Job |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Identity` | The contract that is deployed. It records the identity type and runs a single setup step when the proxy is created. |
| `SmartAccount` | The ERC-7579 modular account. It installs and removes modules, which requires a `MANAGEMENT` key, and it authorizes every call the account dispatches. |
| `KeyManager` | The ERC-734 entry points: `addKey`, `removeKey`, and the key getters. It stores nothing itself. |
Around the account, modules provide the rest. A module is deployed once and serves every identity that installs it, with separate state per identity.
| Module | Role |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ERC734Validator` | Holds the key registry and the claim registry of each identity. Validates user operations: it checks the signature, checks that the signer is a registered key, and checks that the key's purpose allows the call. |
| `KeyApprovalModule` | The ERC-734 `execute` and `approve` queue: a key proposes a call, and it runs at once or waits for an approver, depending on the key's purpose. |
| `RecoveryModule` | Social recovery by guardians. Installed by an owner who wants it. See [Account abstraction and recovery](/identity-onchainid/account-abstraction-and-recovery.md). |
The modules an identity starts with are not chosen by whoever creates it. They are registered per identity type in the `IdentityFactory`, so every identity of a type runs the same, known code.
### Keys at account level, claims as a module
The two founding standards of ONCHAINID sit at different levels, deliberately.
* **Keys are intrinsic to the account.** They define who controls it. The key registry is fixed in the implementation of the identity and cannot be uninstalled or rerouted. The key getters are functions of the account itself, so a read of key state is always answered by the registry.
* **Claims are a capability added to the account.** The claim functions are served by a module, through the account's fallback handler. The claim machinery can evolve, be audited and be reasoned about separately from the logic that guards the account.
Credentials are kept off the control path. Validating a signature or authorizing a call never depends on a claim.
## How an identity acts
An identity acts when one of its keys tells it to. There are two ways to do that.
```mermaid
flowchart LR
S1["Any registered signer:
passkey, EOA, contract wallet"] -->|"signed user operation"| EP["ERC-4337 EntryPoint"]
EP --> ID["ONCHAINID"]
S2["A key that is an address:
EOA or contract"] -->|"direct call"| ID
ID -->|"call"| T["Target contract"]
```
| Path | Who can use it | How it is authorized |
| ----------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **User operation** (ERC-4337) | Any registered signer, whatever its signature scheme | The `ERC734Validator` verifies the signature and the purpose of the key for the target of the call. A paymaster can sponsor the operation, so the owner needs no gas token. |
| **Direct call** (ERC-734) | A key that is an address: an externally owned account or a contract | The key calls `execute(to, value, data)` on the identity. The call runs at once if the key's purpose allows it, and waits for `approve` otherwise. Management functions such as `addKey` and `installModule` are called directly by a `MANAGEMENT` key. |
Both paths apply the same rule: calls to the identity itself, to the `IdentityFactory` and to the key registry need a `MANAGEMENT` key, and calls to any other contract need an `ACTION` key. The account executes single calls and batches. It does not delegate-call.
## Holding tokens
An ONCHAINID has an address and holds tokens at that address like any account. For a T-REX token, the identity is then the holder itself:
* The `IdentityFactory` resolves an identity to itself, so the register attributes the position to the identity without any wallet in between.
* Eligibility is evaluated on the identity's own claims.
* The identity moves the tokens it holds by calling `Token.transfer`, through a user operation or a direct call by an `ACTION` key.
Holding in the identity and holding in linked wallets are not exclusive. A participant can keep a position in its ONCHAINID, keep other positions in wallets linked to it, and move tokens between them without any change of ownership. For tokens that sit in a linked wallet, the identity orders the transfer with `Token.identityTransfer(from, to, amount)`, without an allowance.
## Signing as the identity
An identity validates signatures made in its name, following ERC-1271. A signature is accepted when it comes from a key that holds `ACTION` or `MANAGEMENT` on the identity. Keys that only sign claims, propose or encrypt cannot sign as the identity.
Each identity has its own ERC-712 signing domain, bound to its address. A signature produced for one identity cannot be replayed against another, even though all identities share the same modules.
## Deployment and address
An identity is a beacon proxy, deployed by the `IdentityFactory` through CREATE3.
* **One setup step.** The type, the keys and the modules are applied when the proxy is created. The factory never holds a key on the identity, not even for a moment.
* **A deterministic address.** The address depends on the identity type, a salt, the first account and the keys. The same inputs give the same address on every EVM chain where the factory sits at the same address. An identity is therefore the same address wherever it is deployed.
* **At least one manager.** Creation fails unless the identity ends up with a `MANAGEMENT` key that can sign.
## Upgrades
All identities follow one beacon, owned by the `IdentityFactory`. Upgrading the beacon changes the implementation of every identity at once. The upgrade is gated by a dedicated role with an execution delay, so it is scheduled and visible before it takes effect. The factory refuses a new implementation that does not name the same factory and the same key registry, that is not locked against initialization, or that does not report the expected version.
> **Trust statement.** The holder of the beacon upgrade role can change the code behind every identity. An Identity Owner controls its keys, its claims and its wallets. It does not control the implementation.
The ERC-712 domain of an identity does not change across upgrades. Stored claims are verified against it, and changing it would invalidate every claim signature at once.
## What an ONCHAINID is not
* **Not a profile.** It holds keys and signed claims. It holds no personal data.
* **Not issued by the Issuer of an asset.** One identity serves every asset its owner is eligible for. No issuer owns it.
* **Not tied to one wallet.** Wallets are linked to it and can be revoked. The identity persists.
---
# 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/an-identity-that-is-also-an-account.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.