> For the complete documentation index, see [llms.txt](https://docs.selcier.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.selcier.xyz/fundamentals/verified-holders.md). # Verified holders Selcier ties wallets to verified identities through signed claims that expire, and keeps personal data off the chain entirely. Only wallets tied to a verified identity can hold a Selcier Share Token. That tie is built from on-chain identities and the signed claims trusted verifiers attach to them. Reading the chain tells you that a wallet passed verification and at what level, but not whose wallet it is. ## Building blocks | Component | What it does | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Identity** | Stands for a single person or entity as an address, which may be a dedicated identity contract or a stable identifier assigned by Selcier. Several wallets can belong to one identity. | | **Claim** | An attestation signed by a verifier and attached to an identity. It has a topic, a value and an expiry. | | **Verifier** | Issues claims as an identity provider. Its signing key earns trust topic by topic. | | `IdentityRegistry` | A per-company contract holding the wallet-to-identity map and the claims on each identity. It also answers whether a wallet counts as verified. | | `TrustedVerifiers` | A per-company list of the verifier keys allowed to sign each claim topic. | The `SelcierFactory` deploys both contracts for every company. A default verifier set comes from Selcier, and each company may extend or trim that set for its own registry. ## What a claim can attest | Topic | Consumed by | Usual issuer | Value | | ------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------ | ----------------------------------------------- | | `IDENTITY_VERIFIED` | All transfers | Provider of identity verification | Empty data, effectively `true` until its expiry | | `INVESTOR_ELIGIBLE` | `EligibilityModule` | Provider of eligibility verification | Tier of eligibility, with an expiry | | `REGION` | `RegionModule` | Provider of identity verification | Country code in ISO 3166 alpha-2 form | | `EMPLOYEE_OF` | The employee exemption in `EligibilityModule`, and seller eligibility in a Liquidity Window | The company | `companyId` of the employer | | `SCREENED` | All transfers | Provider of screening | Timestamp of the latest screening | | `VENUE` | Pool and venue contracts, covered in [Gated AMM pools](/markets-and-capital/gated-pools.md) | Selcier, once the company approves | Address of the share token | ## How claims are stored and submitted A claim is filed under its identity and topic, and the registry records three things about it: the verifier's address, an expiry timestamp and the value. There are two ways in. A verifier can call `addClaim` itself, or it can sign off-chain and leave submission to anyone holding the signature, which is normally Selcier's relayer. Those signatures follow EIP-712: * **Domain:** name `Selcier`, version `1`. * **Type:** `Claim(address identity,bytes32 topic,bytes32 dataHash,uint64 expiry,bytes32 companyId,address registry)`, which ties the signature to the registry of a single company. * **Replay:** a signature works one time only, so nobody can bring back a claim that was revoked. Verifiers also repeat their screening on a schedule. When an identity fails, its claim is revoked by the verifier, and sending or receiving tokens stays impossible until verification succeeds again. ## Identity checks during a transfer Each party has to clear two tests at the token's `IdentityRegistry`: the wallet needs an identity behind it, and a trusted verifier must have given that identity `IDENTITY_VERIFIED` and `SCREENED` claims that are still good. | Situation | Outcome | | ------------------------------------------------------------------------------ | ------------------------------------------------- | | The wallet has no identity behind it | `SENDER_NOT_VERIFIED` or `RECIPIENT_NOT_VERIFIED` | | A required claim is missing or was revoked | The matching `_NOT_VERIFIED` code | | A required claim has lapsed, or its verifier has since left `TrustedVerifiers` | `CLAIM_EXPIRED` | `status(wallet)` gives the same verdict as a single value: `NOT_VERIFIED`, `CLAIM_EXPIRED` or `VERIFIED`. When identity is settled, the [Rule Engine](/fundamentals/compliance-modules.md) moves on to whichever further claims its modules read, `REGION` and `INVESTOR_ELIGIBLE` being two examples. Minting consults the same registry, which rules out minting to an unverified wallet. Burning does not consult it, which guarantees the registrar can always redeem shares. Agents are exempt on their own side of a transfer, and that group consists of the company's `LiquidityWindow` plus any contract with a `VENUE` claim for the token. ## Data kept away from the chain Robinhood Chain never receives personal data. All the registry keeps is topics, verifier addresses, expiries and values that reveal nothing personal by themselves: a country code, a tier, a timestamp. The verifier retains all the rest: names, contact details, documents, claim evidence. Selcier's access-controlled systems come into it only where a company needs them. Identities are open to the company and its registrar but closed to the public. [Data visibility](/fundamentals/data-visibility.md) sets out the complete division. ## One identity, several wallets Several wallets suit an investor who splits tokens between self-custody and an institutional custody account, and also someone who prefers a separate wallet on each device. | Wallet type | How the link is made | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Embedded | Investors and employees without a wallet receive one during onboarding in [Portfolio](/the-platform/holder-portfolio.md), and the link to their identity is automatic. | | External | Any EVM wallet qualifies. Its holder proves control by signing a message, after which the `OPERATOR` registers the address. | | Custodial | Addresses at a qualified custodian, BitGo for example, suit institutional holders. | Holder caps count identities and not wallets, so adding a wallet costs no extra holder slot. ## Events and notifications | What happened | On-chain event | | -------------------------------------- | ----------------------------------------------- | | A wallet was linked | `IdentityRegistered(wallet, identity)` | | A wallet was unlinked | `IdentityRemoved(wallet)` | | A verifier attached or renewed a claim | `ClaimAdded(identity, topic, verifier, expiry)` | | A claim was revoked | `ClaimRevoked(identity, topic)` | Two API notifications sit alongside those events. `holder.verified` fires when the identity of an invited holder becomes valid. `holder.claim_expiring` fires before a claim runs out, which gives a company or integrator time to ask the holder for a renewal. [Event delivery](/build-on-selcier/event-delivery.md) has the details. {% hint style="warning" %} Expiry is not a freeze. The balance stays where it is and distributions continue, but no tokens can go in or out of the wallet until the holder renews the claim. {% endhint %} ## When a wallet is lost The holder re-verifies and asks for recovery. Their tokens then travel to a fresh wallet on the same identity, by way of the delayed procedure set out in [Tokenized share classes](/fundamentals/tokenized-share-classes.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.selcier.xyz/fundamentals/verified-holders.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.