Summary: ONCHAINID is best understood as the identity-and-claims sub-layer inside the ERC-3643 / T-REX regulated-token stack, not as a neutral standalone identity primitive. Its official docs describe a per-participant identity contract that mixes ERC-734 key-management and execution rights with ERC-735 claim storage, while leaving sensitive evidence offchain and letting token-specific registries decide which claim topics and which issuers count. The reusable mechanism insight is that ONCHAINID makes identity portable only inside a surrounding policy lattice: identity owners, trusted claim issuers, claim-topic registries, and token operators each control part of the compliance path.
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 userOperation path
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.