Standards

How a permissioned token checks an identity

This is the follow-up to the ONCHAINID note. That one said what the identity and the token standard are. This one walks through how a token actually checks them, in everyday language, and spends most of its time on the step people skip: putting the wallet on the issuer’s list. chainscore.net does not run that list.

chainscore.net 12 September 2026 6 min read

Five numbered steps from deploying an identity to the token’s own check, with step 4 highlighted — The whole walk, in order. Steps 1 to 3 live on the investor’s identity. Step 4 lives on the token issuer’s list. Until that row is written, the token cannot see the identity at all. chainscore.net illustration. Function names are those in EIP-3643; nothing here is a chainscore.net capability.

What this walk is about

A permissioned token will not move to a wallet just because that wallet exists. Before any transfer is approved, the token asks a short question: is this address tied to an identity that still holds the right stamps from people we trust? If the answer is no, the transfer does not happen.

The walk below is how that answer is prepared. It is the same five steps a platform operator follows. The language is everyday on purpose. The names of the contracts are the official ones from ERC-3643, so they can be looked up later. This is a reading of the standard, not a chainscore.net feature, and not a deployment guide.

1. Give the investor an identity

First the investor needs a home for those stamps. That home is an ONCHAINID — a small smart contract on the same kind of chain as the token. Think of it as a digital identity they control, not as another wallet. One identity can point at several wallets. A wallet by itself is only an address.

The investor deploys that contract from a wallet. The contract follows two older building blocks, ERC-734 and ERC-735: one for keys, one for claims. The wallet that deployed it is written in as a management key. That key is the only one allowed to change the identity later — add a stamp, remove a stamp, or link another wallet.

At this point the identity exists, and it is empty. Nobody has stamped it. The token issuer has not heard of it. Having an ONCHAINID is not the same as being allowed to hold the token.

2. Name who may stamp that identity

Token issuers rarely do the identity check themselves. They appoint specialists — KYC and AML desks — and call them claim issuers. A claim issuer is trusted to sign a short statement such as “this identity passed a document check” or “this identity is an accredited investor.”

The issuer writes the claim issuer’s contract address into a list of its own, the Trusted Issuers Registry. Next to that address it writes which kinds of stamp that issuer is allowed to give. The standard calls those kinds claim topics. Topic 1 is a common stand-in for a KYC check; topic 2 for accredited-investor status. The numbers are chosen by the token issuer. They are not a global scoring scale.

Until this list exists, a stamp on an identity has no meaning to the token. Anyone can sign anything. The token only listens to the issuers it named.

Stakeholders of the ONCHAINID ecosystem — The token issuer names which claim issuers it trusts. Those issuers stamp identities. The identity owner still has to accept the stamp. Figure from the ONCHAINID concepts introduction. Reproduced from docs.onchainid.com.

3. Add the stamp to the identity

The real identity check still happens off the chain — documents, interviews, whatever the claim issuer requires. When that check passes, the claim issuer signs a small packet: the investor’s ONCHAINID address, the kind of stamp, and an expiry date. Private papers stay on the claim issuer’s servers. The chain only sees the signature.

Someone then calls addClaim on the investor’s ONCHAINID. That someone is usually the investor, or the platform acting with the investor’s key. The call writes the topic, the claim issuer’s identity, the signature, and an optional pointer to the off-chain file. The identity owner has to allow the stamp. A claim issuer cannot force one on.

The identity now has a stamp. The token still cannot see it. The token does not browse the chain looking for identities. It only looks up wallets that someone has put on its own list. That is the next step, and it is the one this note expands.

ONCHAINID identity with claims signed by a trusted third party; private data stays off-chain — A claim is a signed stamp, not a file of personal data. The issuer keeps the file. The chain only sees that a trusted party signed a statement, and when it expires. Figure from the ONCHAINID concepts introduction. Reproduced from docs.onchainid.com.

4. Put the wallet on the issuer’s list

This is the step that is easy to skip in your head. The investor has an identity. The identity has a stamp. It still feels as if the work is done. It is not. The token has a separate list, the Identity Registry, and until a row is written there the token treats the wallet as a stranger.

A useful picture is a passport and a guest list. The ONCHAINID is the passport. The stamps are the visas. The Identity Registry is the guest list for one building — this token. You can hold a valid passport and still not be on tonight’s list. The door does not open.

The row is written by a function called registerIdentity. The standard is strict about who may call it: only an agent of the Identity Registry. That is almost always the token issuer, or a platform operator the issuer has appointed. The investor cannot add themselves. There is no self-service button on the identity contract that writes this row.

Three things go in. The first is the everyday wallet that will send or receive the token — the address you would paste into a transfer. The second is the ONCHAINID contract, the identity that wallet belongs to. The third is a country code: a number from the ISO-3166 list of countries, stored as a small integer. The United Kingdom is 826. The United States is 840. The number is not guessed from the wallet, and it is not a risk score. It is written down so later rules — a cap on holders from one country, a ban on another — have something to read.

Those three fields do not sit inside the token itself. They are written into a separate contract called the Identity Registry Storage. Think of it as the filing cabinet. The Identity Registry is the clerk who is allowed to open it. The cabinet can be shared: several tokens can keep their own clerks, each with their own trusted issuers and required stamps, and still look up the same investors. That is why the storage is split out. One KYC pass can cover more than one token from the same group, without copying the list.

When the row is written, the registry emits an IdentityRegistered event. That is the on-chain receipt. From then on three simple questions have answers. contains: is this wallet on the list at all? identity: which ONCHAINID does it map to? investorCountry: which country was written down? If the investor later moves, or replaces the identity contract, an agent calls updateCountry or updateIdentity. If they must be taken off the list, the agent calls deleteIdentity. A platform onboarding many people at once can use batchRegisterIdentity and write many rows in one go.

Skip this step and the rest of the walk does not matter. When a transfer asks the registry about the wallet, the lookup comes back empty. The standard’s own check, isVerified, returns false. The transfer is refused. The stamps on the identity are still there. The token never reached them.

Three fields — wallet, ONCHAINID and country — flowing into Identity Registry Storage — This is the row that step 4 writes. Three fields, one filing cabinet. The investor cannot write it. An agent of the Identity Registry can. chainscore.net illustration. Function names are those in EIP-3643; nothing here is a chainscore.net capability.

Why this list is not the chainscore.net directory

The 28-entity directory answers a different question: which houses offer which crypto-asset services, and under which licence type. It has 51 service rows. It does not map wallets to identities, and it does not store a country code for an investor. registerIdentity is not a directory field, and it is not inferred from a tokenization or DLT row.

A house in the Tokenization & DLT bucket may well run an ERC-3643 stack of its own. That stack is theirs. chainscore.net does not call registerIdentity, does not act as an agent of anyone’s Identity Registry, and does not issue claims. Verified by chainscore.net means a label is documented in the label book. It is not KYC, and it is not the standard’s isVerified check.

5. The token checks by itself

Once the row exists, a transfer does not need a person to re-check the file. The token calls isVerified on the Identity Registry and passes the wallet from the transfer — the receiver, in the usual case. The function takes the wallet, not the identity contract. That is easy to get backwards.

The clerk then opens the cabinet. If there is no row, the answer is no and the walk stops. If there is a row, the clerk reads the ONCHAINID and asks it for the stamps the token requires. Each stamp has to be the right kind, signed by an issuer on the trusted list, and not expired. Only then does isVerified return yes.

A yes still is not the whole transfer. The standard has a second door, canTransfer, which asks about the token’s own rules — a cap on the number of holders, a cap per country, a maximum holding. Identity gets you through the first door. The second door is the offering’s own policy.

chainscore.net screens wallet history on public chains. It does not implement ERC-3643, does not run an Identity Registry, and does not decide whether a permissioned transfer may settle. If a screen meets a permissioned book, the finding is not_observable — out of sight, permissioned ledger — not a claim that the investor was, or was not, on the issuer’s list.

A transfer looks a wallet up in storage, then reads the identity stamps; a missing row stops the check — When a transfer starts, the token asks the list about the wallet. No row means the check stops. A row is not yet a yes — the stamps still have to hold. chainscore.net illustration. Function names are those in EIP-3643; nothing here is a chainscore.net capability.