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.
Holds claims	Signed attestations about the identity, issued by Claim Issuers. See Claims: issuance, validity, revocation.
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.
Has a type	Individual, corporate, Claim Issuer, asset and others, recorded at creation. See Identity types and factory gating.

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

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.

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.

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.