> For the complete documentation index, see [llms.txt](https://docs.useicaria.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useicaria.xyz/architecture/eligibility.md). # Eligibility registry How the venue decides who may trade, provide liquidity and make markets, without putting personal data on a chain. Nothing in a Stock Token contract restricts transfers. Robinhood applies eligibility through its own interface and at KYC'd issuance and redemption. That leaves every venue listing those tokens to enforce eligibility for itself, and where Icaria does so is the **protocol boundary**: each swap, each deposit, each RFQ settlement and each share transfer gets checked. ## Roles | Role | Who | Status | | --------- | ------------------------------------------------------------------------------------------------------------------ | ------ | | `TRADER` | KYC'd individuals and entities in jurisdictions that are not restricted, matching the Stock Token eligibility list | Live | | `LP` | Liquidity providers, professional clients at launch, given the inventory exposure a vault carries | Live | | `MAKER` | Professional market-making firms that have been admitted to RFQ | Live | | `RELAYER` | Services submitting swaps for somebody else, such as account-abstraction bundlers and integrators | Live | ## Attestations **Ethereum Attestation Service** attestations, compatible with ONCHAINID, are what eligibility rests on, issued by the KYC provider once identity, sanctions and residency checks have been completed. Inside each attestation: * the wallet address, * the role, * a jurisdiction class, with the country itself present only if the user elects to disclose it, * an investor class where that applies, * an expiry. No name, document or personal identifier appears anywhere in it. Attestations run out and get renewed through continuous re-screening, and a revocation bites immediately. ### Zero-knowledge path An optional credential route, through Privado ID or zkPass, lets a wallet demonstrate "eligible in jurisdiction class X, investor class Y" while revealing neither which provider ran the check nor any underlying attribute. The registry takes either form. ## The check ```solidity function isEligible(address account, bytes32 role) external view returns (bool); ``` `SwapRouter`, `AnchorVault` and `RfqSettlement` each call this for whichever parties are relevant. A failed check reverts the call, and since the front-end resolves the same view before anything gets signed, an ineligible user is given the reason rather than paying gas to discover it. Views stay permissionless throughout, so indexers, explorers and aggregators can read whatever they need. ### Which actions get checked | Action | Checked parties | | -------------------- | ------------------------------------------------------------------------- | | `swap` | The trader (`TRADER`), and the recipient as well where they differ | | RFQ `settle` | The taker (`TRADER`) and the maker (`MAKER`) | | Vault `deposit` | The depositor (`LP`) | | Vault `withdraw` | Nothing beyond owning the shares: exiting is a property, not a permission | | Vault share transfer | The recipient (`LP`) | | Relayed submission | The relayer (`RELAYER`), plus the underlying user's own role | ## Adapters An adapter interface sits on the registry, which lets the policy engine be replaced without touching the core: * **EAS adapter** at launch, reading attestations by schema and issuer. * **ONCHAINID adapter**, for identities that follow ERC-3643. * **Chainlink ACE / CCID adapter**, an alternative engine that the timelock can switch on if needed. Which issuers and schemas are accepted is a `ParamController` value, so tightening the policy or swapping providers is a logged, timelocked change instead of a redeployment. ## Permissioned assets Should Stock Tokens or bridged RWAs take on ERC-7943 (uRWA) or ERC-3643 hooks, the vaults and `RfqSettlement` already call `canTransfer` and `canReceive` defensively and would get allowlisted by the issuer in turn. Both sets of rules, the token's and the venue's, would then be satisfied without either side needing to trust the other. See [Asset roadmap](/assets/asset-roadmap.md). ## Geo-fencing Restricted jurisdictions get excluded at more than one layer: 1. Attestations are never issued to wallets in restricted jurisdictions. 2. A jurisdiction self-attestation is required from every wallet during onboarding. 3. The front-end applies IP-based geo-fencing against restricted jurisdictions. 4. Sanctions screening runs independently at the sequencer. Maintained by the attestation issuer, the restricted list tracks the Stock Token issuer's own availability list; see the [Compliance model](/compliance/model.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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.useicaria.xyz/architecture/eligibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.