ONCHAINID
- Name: ONCHAINID
- URL: https://docs.erc3643.org/erc-3643/smart-contracts-library/onchain-identities
- Category: onchain identity contract / compliance-claims infrastructure / trusted-issuer credential layer
- Tags: ethereum-ecosystem
- Summary: ONCHAINID is the identity-and-claims sublayer inside the ERC-3643 / T-REX regulated-token stack, not a neutral standalone identity primitive. It gives each participant a contract with ERC-734-style key management and ERC-735-style claim storage, but transfer eligibility still depends on issuer allowlists, claim-topic registries, and token-side policy. Portability helps; it does not remove the surrounding compliance lattice.
- What it does:
- Creates a unique onchain identity contract for each participant, with claims and keys bound to a stable contract address
- Extends ERC-734 and ERC-735 so identities can manage keys, approve/execute actions, and add/remove/query claims
- Lets trusted claim issuers attach signed claims to an identity while keeping sensitive personal data offchain and only anchoring signatures / hashes onchain
- Uses deterministic deployment through IdFactory plus CREATE2 so the same wallet can deploy the same ONCHAINID address across EVM chains
- Works with Identity Registry, Claim Topics Registry, and Trusted Issuers Registry contracts to determine whether a wallet is eligible to hold or receive an ERC-3643 token
- Can function directly as a wallet and the docs explicitly note possible ERC-4337 compatibility via an account-abstraction-style
userOperationpath
- Key claims:
- The official docs describe ONCHAINID as a blockchain-based identity management system that creates a unique, globally accessible identity for each participant and stores identities on public chains
- The docs say ONCHAINID complies with ERC-734 and ERC-735, which is the clearest sign that its core primitive is a programmable identity contract with both key-management and claim-management surfaces
- The docs stress that private data remains offchain with claim issuers while only signatures of that data are kept onchain, showing the system is really a verification rail for credential pointers rather than an onchain PII store
- The deployment docs say deterministic CREATE2 deployment lets the same user deploy the same ONCHAINID address across chains, which matters because claim signatures tied to the identity address can then be reused cross-chain without re-signing
- The Identity Registry docs say transfer verification fetches the recipient’s ONCHAINID, compares its claims against the Claim Topics Registry and Trusted Issuers Registry, verifies signatures, and only then returns
true, which makes ONCHAINID one component of a broader compliance-control stack rather than the sole policy engine - The Trusted Issuers Registry interface shows an explicit admin surface for adding/removing trusted issuers and restricting which claim topics each issuer may attest, which means practical trust still concentrates in issuer allowlists and registry operators even though the identity object itself is portable
- Whitepaper: No standalone ONCHAINID whitepaper surfaced in this pass. The clearest current primary materials were the ERC-3643 docs pages for ONCHAINID, the Identity Registry, the Claim Topics Registry, and the Trusted Issuers Registry; see
../whitepapers/onchainid-primary-sources-2026-05-08.md. - Sources:
- https://docs.erc3643.org/erc-3643/smart-contracts-library/onchain-identities
- https://docs.erc3643.org/erc-3643/smart-contracts-library/onchain-identities/onchainid-interface
- https://docs.erc3643.org/erc-3643/smart-contracts-library/onchain-identities/identity-registry
- https://docs.erc3643.org/erc-3643/smart-contracts-library/onchain-identities/claim-topics-registry
- https://docs.erc3643.org/erc-3643/smart-contracts-library/onchain-identities/trusted-issuers-registry/trusted-issuers-registry-interface
Internal linkages
- Best read upward to erc-3643 and tokeny.
- That keeps this note inside the actual regulated-token stack instead of letting it float as a generic identity primitive or blur the standard layer back into a preserved company alias.
Control surface
-
Practical authority sits with identity-owner keys, trusted claim issuers, claim-topic registries, and identity-registry operators.
-
Treat ONCHAINID as credential plumbing inside a regulated-token stack, not as broad self-sovereign identity infrastructure.
-
Last reviewed: 2026-06-05 UTC