On-Chain Identity

Evidence stays with the verifier. The ledger records only the result: a topic, an issuer, and an expiry date when one is set.

One identity serves every asset in the deployment; each asset applies its own rule to the same record.

Eligibility is read live at transfer time. Untrusting an issuer or revoking a verification takes effect on the next check, with no cleanup transaction. An expiry date is recorded, but it affects transfers only when the asset enables claim-expiry checking.

Why reusable identity mattersCopy Anchor Link

An On-Chain Identity lets a subject's verification serve every asset willing to accept it, so a wallet already cleared for one instrument does not repeat the same check for the next. The record belongs to the subject, not to one asset, and holds verification results instead of documents. An asset reuses an identity's claims whenever its own topic and issuer requirements accept them.

A typical tokenization programme runs identity screening in a system separate from the ledger it is meant to protect. Asset Lifecycle makes the wider point directly: issuance sits in one system, screening in a second, custody in a third, trading in a fourth, and settlement and reporting in a fifth. Every boundary between them is a reconciliation, a point where an instrument's ledger state and its legal record can drift apart. An On-Chain Identity closes that boundary for eligibility specifically. Verification lives on the same ledger the asset transfers on, so there is one record instead of two that must be kept in agreement.

This removes repeated onboarding: a second asset reads the same entries instead of collecting a fresh copy that ages on its own schedule. Issuers renew or replace claims when verification requirements or expiry dates require it.

Your verification providers keep their work. The platform does not decide who counts as an accredited investor or whether a screening result is acceptable; your compliance function and the issuers you appoint decide that. What the platform adds is the part a provider cannot do alone. It puts the result where the asset itself reads it at the moment of transfer, so the asset enforces eligibility instead of trusting a surrounding system to remember it.

Reuse has a boundary worth writing into a contract. A verification counts inside the registry the asset consults. Assets in the same deployment share it; another institution's deployment makes its own trust decisions and inherits none of yours.

Reviewing and changing verificationsCopy Anchor Link

Day to day, an On-Chain Identity is one page per subject in the console. It shows the identity's address, which of the subject's wallets the registry holds and under which country, and every verification against it with its topic, its issuer, and its state.

Two jobs make a holder eligible, and they run independently. One is registration: binding the holder's wallet to their identity in the asset's registry, together with the country the rules will read. The other is verification: getting the topics the asset requires signed onto that identity. A wallet must be registered and satisfy the asset's required verification topics. An asset with no topic expression still requires registration and a wallet that is not marked lost.

Know-your-customer work runs through a versioned profile. The holder fills in a version and submits it; a reviewer approves it, rejects it, or asks for changes, and every version keeps its own history. Approval gates the on-chain step: issue the verification only once a version is approved, never before.

Issuing a verification means choosing its topic and, where the topic has one, an expiry date. Investor topics record a plain pass; know-your-customer records a value tied to the approved profile, detailed under The integration contract below. The platform rejects the write when the issuing identity is not trusted for that topic, so no one attests outside their mandate.

Revocation works by topic in the same way, and the revoked entry stays on the record with its state visible. The next transfer that reads the identity is the one that fails, with no batch window or day-end cut-off in between.

A connected verification provider automates both directions, and it needs no presence on the ledger of its own: the platform provisions an issuer identity and signing key for each provider it connects. An approved verdict issues the matching verification and a rejected verdict revokes it, while a verdict still under review lands in the record without touching the ledger. A monitoring alert revokes only when its severity reaches the threshold you set for that provider and topic.

Losing a wallet is the case to rehearse before it happens. Recovery gives the holder a replacement wallet and a fresh identity, moves their balances across token by token, and marks the lost wallet so that nothing can be transferred into it again. The registry records which wallet replaced which, so an auditor can follow one subject across the change. Verifications do not travel with the balances: each issuer re-issues onto the new identity, so plan that step into the runbook rather than discovering it mid-recovery.

Where identity and eligibility meetCopy Anchor Link

An On-Chain Identity is a separate contract for one subject, with verifications stored as signed entries. The application does not decide eligibility. When an asset tests a recipient, the ledger combines independently administered registry, topic, identity, and issuer state, so a rejected transfer has a specific control cause.

Those four are the registry binding the wallet to an identity, the catalogue of topics that exist, the entries on the identity, and the record of which issuers the registry trusts for which topic. The platform seeds that catalogue when a deployment is created, and an operator adds whatever else the institution needs. The asset's rule is an expression over topics, joined by and, or, and not, to a ceiling of 32 elements. An asset with no expression still needs a registered wallet that is not marked lost. The check resolves its conditions in order, and the first one that fails ends it: the transfer reverts, and nothing moves.

An entry is never taken at face value. For each required topic the registry collects the entries recorded under it, checks their issuer against the trusted list for that topic, then asks that issuer's own contract whether the entry is still valid. An issuer is itself an identity on the same ledger, so the registry names that identity rather than a signing key, and the keys the issuer signs with live on it. Revocation lives with the issuer too, keyed to the signature, so a revoked entry stays visible while failing that last question.

Binding runs on consent and it is permanent. Creating an identity for a wallet takes that wallet's own call, or an authorization it signed, and no later operation unbinds the two.

Each asset pins the registries it consults at creation, and trust reaches no further. A registry inherits from a parent, and from its parent's parent, to a depth of three, which is how a platform-wide directory reaches the deployments beneath it. Inheritance adds rather than overrides: a registry's trusted issuers are its own plus the ones above it, so a deployment extends the platform list and cannot quietly trim it. An issuer trusted in one deployment is a stranger to another, even on the same chain, and a flawless signature from that stranger still fails. The entries themselves are shared; the trust decision is not, so one asset may count a verification that the asset beside it ignores.

The token's core identity check evaluates the recipient. Compliance modules can impose additional sender rules. A burn has no recipient, so the recipient identity check does not run. A custodian's forced transfer still runs the identity check in full, topic expression included; a recipient it would reject stays unreachable even through a forced transfer. What a forced transfer skips is the compliance module layer beside it, the added rules such as screening or transfer restrictions that a normal transfer must also clear.

The integration contractCopy Anchor Link

For an integrator, an On-Chain Identity is one address, and the identity endpoints create and register it, issue or revoke verifications on it, and read the record. The API calls these entries claims, while the console calls them verifications. One issuer and topic pair has at most one current entry.

Issuing is a ledger write, so it follows the platform's asynchronous mutation contract. Wait for it to settle inside the window you ask for, or take the accepted response and follow its status link. Acceptance means the platform durably recorded your instruction; the outcome is the request's own Settlement VerdictA Settlement Verdict lets you report success only when an operation actually happened, not from acceptance alone, across four recorded end states.Read the concept. That is the recorded end state the platform reports once the write resolves.

An issue names the target identity, the topic, and a payload typed for that topic; the topic fixes the payload's shape, and the issuer never types it. Investor topics take a fixed pass value with an optional expiry. The topics an asset's own identity holds, such as base price or collateral, take structured fields that pricing and minting read. Know-your-customer is the topic to plan around, because its value must equal the hash of the subject's approved profile version. Issue it after approval, never before.

Three reads answer three different questions. Reading an identity returns its address, its registration state, and the entries on it, each marked with whether the consulted registry trusts the issuer that signed it. A registration-status read collapses onboarding into one value to branch on.

An eligibility read returns allowed, needs-action, or blocked, plus a reason for each failing rule drawn from the platform's error catalog, so an integration can tell a holder exactly what to fix.

Read an eligibility verdict as a diagnosis, never as a reservation. It describes the moment it ran, and the asset repeats the real check inside the transfer. A clear read followed by a revocation still ends in a reverted transfer.

Controls and evidenceCopy Anchor Link

For a control function, an On-Chain Identity is a preventive control with a readable history. It records that a verification was made, by which issuer, for what, and when it stopped counting, while the material behind that verification stays in the systems that already hold it.

What reaches the ledger is deliberately thin: a topic, the issuing identity, a signature, and a value, with know-your-customer's value described under The integration contract above. That is why approval gates the on-chain step rather than merely preceding it: the entry ties to an exact reviewed version without publishing a word of its contents. Identity documents, review notes, and provider payloads stay off the ledger under your existing retention rules.

Express eligibility positively and withdraw it, rather than writing a rule against a negative state. A rule reading "verified and not sanctioned" looks careful and is not: the absence of a sanctions entry evaluates as false before the negation turns it into true, so a wallet no one ever screened passes.

Screening results still belong in the record as evidence. The enforcement step is revoking the eligibility verification the rule requires.

The evidence trail sits on the ledger. Issues, changes, removals, and revocations each land as a timestamped event tagged with their topic and their issuing identity, so a holder's eligibility history reconstructs without reference to application logs. Registration and country sit in the registry beside it, along with the lost-wallet marker.

The platform verifies nobody; it records the verdicts your appointed issuers sign. Untrusting an issuer or revoking a verification stops it counting on the next check. An expiry date alone does not change the identity registry's verification result. On assets with claim-expiry checking enabled, a recipient needs a live claim on each required topic; an expired sender can still transfer out. In v3.1.24, claim-expiry checking is unavailable, so an expired claim alone does not block a transfer. Keep the record current and enable the check on each asset that must refuse expired claims.

Frequently asked questionsCopy Anchor Link