For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

The contracts

Page
Contract
Deployed as

Identity, with SmartAccount and KeyManager

One beacon proxy per identity, by the IdentityFactory. Every identity runs the same implementation

ERC734Validator

Once per network. It holds the keys and the claims of every identity

KeyApprovalModule

Once per network. It holds the execution queue of every identity that installs it

RecoveryModule

Once per network. It holds the guardians of every identity that installs it

IdentityFactory

Once per network. It deploys identities and keeps the global record of wallets

ReputationRegistry

Once per network

EASClaimIssuer

Once per network, per EAS deployment it reads

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.

The reading conventions of the function tables are those of the Token Suite section.

Last updated