Identity and eligibility
How reusable identities, trusted claims, and transfer rules work together.
Wallets and identities
Investors get their identity on Get verified in the investor portal. Issuers set each suite's identity rules on the asset's Rules & roles tab in the issuer portal.
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.
The two do different jobs. The wallet takes part in transactions. The identity supplies attestations that a suite can evaluate. Registering a wallet is one step toward eligibility.
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 that makes the 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 and still not be accepted by a particular token. Trust settings decide whether the claim counts. They do not make the claim private or hide it 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.
Reuse means the investor does not need a separate identity record for each asset. Each suite still evaluates its own requirements, and its wallet registration and transfer rules still apply.
Issuer admission is a separate step: the issuer registers the wallet and identity in its suite. The platform verification (Get verified in the investor portal) prepares reusable claims. It does not register the investor in any asset.
Issuers can also issue claims for investors they have verified themselves. Those claims use the issuer's own claim authority, and a suite accepts them only if it trusts that issuer. An issuer's accepted claims can satisfy its own suite without the platform verification. They do not give platform-wide verification or eligibility for other issuers' assets. This path does not show that the platform performed the underlying verification or ongoing screening.
Identity eligibility and transfer permission
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 pass the required identity checks, and a proposed transfer can still fail a geographic restriction or an operational control.
These checks enforce the rules configured in the contracts. They do not prove full legal compliance. They do not 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 (a trial check before signing) can add more account restrictions.
Jurisdiction in Real
Real models jurisdiction as a claim, so the suite's trust settings decide which jurisdiction claims count. 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. Real's jurisdiction module does not use that field; it uses the trusted claim. Changing the field alone does not change the accepted jurisdiction claim.
The jurisdiction module applies only where the suite uses it, that is, where the issuer set a list of allowed countries. Without that module, no country rule applies. Where the module is used, the issuer's trusted jurisdiction claim takes priority if it exists and is valid. Otherwise, the platform claim applies.
Custom claims
An issuer can define organization-specific topics and issue claims through the platform's signing service. In the issuer portal, define these topics in Settings → Attestation types. Some topics represent a yes-or-no attestation; others carry a typed value.
When a suite requires a custom topic, it checks only that an accepted, valid claim exists. A value stored in that claim does not create a transfer rule that evaluates the value. To enforce rules based on the value, you need a matching compliance module, as with jurisdiction.
Required topics and signing-key changes
The standard suite starts with four required topics: KYC, AML, SANCTIONS_CLEARED, and JURISDICTION. The issuer portal does not let you remove this default set. If an issuer adds another required topic, existing holders who lack it can immediately become ineligible to receive tokens.
Claims have no automatic on-chain expiry. Three things decide acceptance: revocation, trusted-issuer configuration, and signing-key validity. Before the responsible operator retires a claim-signing key, it must reissue the affected claims with their original verified meaning. Otherwise, existing claims can become invalid.
Eligibility can change
The suite evaluates eligibility against the current claims and configuration. Revocation, loss of claim validity, changes to trusted issuers, or changes to required topics can change the result. Transfer permission can also change when compliance rules or token controls change.
A failed eligibility check does not remove tokens already held. Transfers and authorized asset-management operations still follow their own contract rules.
When a transfer is refused, first find out if the cause is an identity problem or a transfer restriction. Check registration and accepted claims first. Then check the applicable rules and token state. A platform preflight can explain a likely refusal, but it does not decide the outcome; see How transactions settle.