Identity and eligibility
How reusable identities, trusted claims, and transfer rules work together.
Wallets and identities
A wallet is the address an investor uses to hold tokens and submit transactions. An ONCHAINID is an identity contract that holds keys and claims. A suite's identity registry associates the investor's wallet with that identity.
These serve different purposes: the wallet participates in transactions, while the identity supplies attestations that a suite can evaluate. Registering a wallet is one step in eligibility, not an automatic approval for every asset.
Claims and trust
A claim is an attestation from a claim issuer about a particular topic. For example, a claim may attest that an investor has completed an identity check. The claim issuer is the party making that attestation; it is not necessarily the issuer of the asset token.
Each suite defines two things:
- Required topics: the kinds of claim an investor must have.
- Trusted issuers: the claim issuers accepted for those topics.
A claim can exist on an identity without being accepted by a particular token. Trust determines whether it counts; it does not make the claim private or invisible on-chain.
Reuse does not mean universal access
Suppose an investor uses the same identity for two assets. Both suites can accept a platform-issued claim if their trust settings allow it. A claim from an asset-specific issuer may count for one suite and be ignored by the other.
Reusing the identity avoids treating each asset as an entirely separate identity record. Each suite still evaluates its own requirements, and its wallet registration and transfer rules still apply.
Identity eligibility and transfer permission
Issuer admission is an additional step: the issuer registers the wallet and identity in its suite. The platform verification path prepares reusable claims, but it does not automatically register the investor into every asset.
Issuers may also attest to investors they have verified themselves. Those attestations use the issuer's own claim authority and are accepted only where trusted. This path does not imply that the platform performed the underlying verification or ongoing screening.
There are two separate questions:
| Question | What is evaluated |
|---|---|
| Does the identity meet this suite's requirements? | Wallet registration and valid claims from issuers trusted for the required topics |
| Is this particular transfer permitted? | Applicable compliance rules and token conditions, such as pauses, freezes, and available balance |
Passing the first check does not guarantee the second. An investor can satisfy the required identity checks while a proposed transfer fails a geographic restriction or an operational control.
These checks enforce the rules configured in the contracts. They do not establish complete legal compliance or independently verify all facts about an investor or asset.
Ordinary transfer flow
- Token state: ordinary transfers must be unpaused; the sender and recipient must be unfrozen, and enough unfrozen balance must be available.
- Recipient identity: the recipient must be registered and have valid claims from accepted issuers for every required topic.
- Compliance: configured modules evaluate the proposed transfer, including applicable jurisdiction and holding limits.
- Outcome: if every check passes, balances and compliance accounting update atomically. Any failed check reverts the transfer.
This flow describes ordinary transfers. Privileged token operations use their own checks; the platform preflight may impose additional account restrictions.
Jurisdiction in REAL
REAL models jurisdiction as a claim so that its acceptance follows the suite's trust settings. The jurisdiction compliance module reads a trusted, valid claim and checks its country value against the suite's configured geographic rules.
The underlying identity storage also has a country field. That field is distinct from the trusted claim used by REAL's jurisdiction module; changing the field alone is not the same as changing the accepted jurisdiction claim.
In the platform suite configuration, the issuer's trusted jurisdiction claim takes priority where present and valid; the platform claim provides the fallback. A different suite does not accept that issuer's claim merely because it shares the investor's identity.
Custom claims
An issuer can define organization-specific topics and issue claims through the platform's signing service. Some topics represent a yes-or-no attestation; others carry a typed value.
Requiring a custom topic checks for an accepted, valid claim. Storing a value in that claim does not automatically create a transfer rule that evaluates the value. Value-based enforcement needs a corresponding compliance module, as with jurisdiction.
Required topics and signing-key changes
The standard suite starts with KYC, AML, SANCTIONS_CLEARED, and JURISDICTION requirements. The platform treats this default set as a non-removable baseline in issuer-facing topic management. Adding another required topic can immediately make existing holders who lack it ineligible to receive tokens.
The reviewed claim-validation path does not provide automatic on-chain expiry. Revocation, trusted-issuer configuration, and signing-key validity determine acceptance. Before retiring a claim-signing key, the responsible operator must reissue affected claims with their original verified meaning; otherwise existing claims can become invalid.
An issuer's own accepted claims can satisfy its suite without the investor taking the platform-provider verification route for that suite. This does not confer platform-wide verification or eligibility for other issuers.
Eligibility can change
Eligibility is evaluated against current claims and configuration. Revocation, loss of claim validity, changes to trusted issuers, or changes to required topics can affect the result. Transfer permission can also change when compliance rules or token controls change.
A failed eligibility check does not automatically remove tokens already held. Transfers and authorized asset-management operations remain governed by their respective contract rules.
When a transfer is refused, first distinguish an identity problem from a transfer restriction. Check registration and accepted claims, then the applicable rules and token state. A platform's preliminary check can explain a likely refusal; the executed transaction determines the on-chain outcome.