ONCHAINID and ERC-3643 · chainscore.net

ONCHAINID identity with claims signed by a trusted third party; private data stays off-chain — An identity has no value by itself. Credit comes from claims — self-attested or signed by a bank, transfer agent, marketplace or auditor. The issuer stores private data off-chain and publishes only a signature on-chain. Figure from the ONCHAINID concepts introduction. Reproduced from docs.onchainid.com.

What ONCHAINID is

ONCHAINID is a set of smart contracts, based on ERC-734 and ERC-735, plus the applications around them. An identity represents a person, a company, a programme or an object on an EVM chain. The contracts in production sit on Ethereum and Polygon; the same pattern can be deployed on any EVM network. Once deployed, the identity cannot be hidden or deleted, and no service can revoke the owner’s keys to it.

A bare identity is not a credential. What matters are the claims attached to it. A claim issuer that the owner has allowed — a bank, a national e-ID, a digital-asset marketplace, a transfer agent, an auditor — signs a statement such as “this identity passed an ID-card and selfie check.” Sensitive data stays on the issuer’s servers. The chain only sees a signature that the check happened. Anyone who needs the file itself still needs the owner’s consent.

That is the difference the documentation draws with a plain wallet. A wallet address is a technical pseudonym; it can be swapped, lost or multiplied, and a whitelist kept off-chain leaves no evidence on the ledger. An ONCHAINID is a contract the holder controls: they link one or more wallets, keep certified information in one place, and prove eligibility to a permissioned protocol without publishing the underlying file.

ERC-3643 — permissioned tokens on that identity

ONCHAINID was designed as part of T-REX, the protocol now standardised as ERC-3643. ERC-3643 is a permissioned token: a transfer settles only when the sender and the receiver hold identities that carry the claims the issuer requires, and when the issuer’s compliance rules — jurisdiction, investor class, holder caps — also pass. The token contract does not perform KYC. It reads the identity registry and the claim topics the issuer configured.

The issuer is the trusted entity for that token’s holders. Accredited claim issuers attach qualifying statements — a KYC provider stating the investor may hold the security, a marketplace stating the investor was admitted. The owner still decides whether the claim is added. That is an issuer / transfer-agent control, not a wallet-history screen.

Stakeholders of the ONCHAINID ecosystem — The issuer of a permissioned token acts as a trusted entity for its holders. Claim issuers (a KYC desk, a marketplace) attach qualifying statements. The identity owner still consents before a claim is added. Figure from the ONCHAINID concepts introduction. Reproduced from docs.onchainid.com.

Applications

The documentation names three production uses: security tokens, payment ecosystems and loyalty programmes. The same identity can also act as a login, or as a place to aggregate certifications the holder later shows to a custodian, a DeFi protocol or an authority.

What the contract can answer is “may this identity receive this token, given the claims the issuer trusts?” What it cannot answer is where the funds in the linked wallets came from, which hops they took, or whether a public indexer can even see the book. Those are screening questions. Tokeny lists analytics vendors alongside T-REX for that reason; the standard does not replace them.

Various use cases of ONCHAINID — The same identity can carry claims for security-token eligibility, payment ecosystems, loyalty programmes and login — the owner decides who may read the private side. Figure from the ONCHAINID concepts introduction. Reproduced from docs.onchainid.com.

Where this meets the chainscore.net directory

The relationship is real, and it is limited. The directory’s Tokenization & DLT bucket lists houses that originate or service tokenized instruments — Sygnum’s Tokenization Engine under Swiss DLT law, BNY’s Tokenization Infrastructure (LiquidityDirect mirrors onto GS DAP), Goldman Sachs DAP, J.P. Morgan Tokenized Capital (MONY on public Ethereum) and Citi Token Services. Signup glossary needles for that bucket are tokenization, DLT and permissioned blockchain. None of those rows is an ERC-3643 deployment that chainscore.net operates.

A screen can follow a public-chain leg when one exists. MONY tokens issued on Ethereum are in indexer scope. Permissioned books are not. GS DAP, Citi Token Services, Sygnum DLT and HSBC Orion are named on every report as unindexed ledgers. A visibility stop reads as not_observable — out of sight, permissioned ledger — not as a clean end of trail, and not as a claim that the investor was eligible under ERC-3643.

chainscore.net does not issue ONCHAINID claims. It is not a claim issuer, a transfer agent or a T-REX identity registry. Holistix composes a cross-chain screen; it does not implement ERC-3643. Verified by chainscore.net means the label is documented in the label book. It is not KYC, accreditation or an ONCHAINID claim. If a cited public registry is later read as a coverage gate, it would be not_observable, clear or triggered — never scored as if chainscore.net had performed the identity check.