> For the complete documentation index, see [llms.txt](https://docs.syndromics.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.syndromics.xyz/architecture/eligibility.md).

# Eligibility registry

Stock Tokens carry no on-chain transfer restrictions. Robinhood enforces eligibility at its own interface and at KYC'd issuance and redemption. A protocol that lends against those tokens therefore has to enforce eligibility itself, and Syndromics does so at the **protocol boundary**: every settlement, every supply, every refinance, and every recipient of collateral in a liquidation or repayment is checked.

## Roles

| Role                  | Who                                                                                                                                                                     | Status  |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `BORROWER`            | KYC'd, non-restricted jurisdiction, mirroring the Stock Token eligibility list. Borrowers today are verified businesses and professional or high-net-worth individuals. | Live    |
| `LENDER_PROFESSIONAL` | Professional clients under the applicable regime (credit funds, market makers, family offices)                                                                          | Live    |
| `LENDER_RETAIL`       | Retail lenders, added jurisdiction by jurisdiction where permitted                                                                                                      | Roadmap |
| `LIQUIDATOR`          | Any address that may receive collateral in an auction or in-kind settlement                                                                                             | Live    |
| `RELAYER`             | Services that submit settlements on behalf of users                                                                                                                     | Live    |

## Attestations

Eligibility is backed by **Ethereum Attestation Service** attestations, compatible with ONCHAINID, issued by the KYC provider after identity, sanctions and residency checks.

An attestation contains:

* the wallet address,
* the role,
* a jurisdiction class (not the country, unless the user opts to disclose it),
* an investor class where relevant,
* an expiry.

It contains no name, no document and no personal identifier. Attestations expire and are renewed on continuous re-screening; revocation takes effect immediately.

### Zero-knowledge path

An optional credential path (Privado ID or zkPass) lets a wallet prove "eligible in jurisdiction class X, investor class Y" without revealing which provider checked it or any underlying attribute. The registry accepts either form.

## The check

```solidity
function isEligible(address account, bytes32 role) external view returns (bool);
```

`LoanSettlement`, `RefinanceAuction`, `LiquidationAuction` and `PositionNFT` call this for every relevant party. A failing check reverts the transaction. View functions stay permissionless so that indexers, explorers and aggregators can read everything.

### Where the check runs

| Action                          | Checked parties                                  |
| ------------------------------- | ------------------------------------------------ |
| `settle`                        | Borrower (`BORROWER`), every lender (`LENDER_*`) |
| `accept` in a refinance auction | New lender                                       |
| `buy` in a liquidation auction  | Buyer (`LIQUIDATOR`)                             |
| In-kind liquidation             | Receiving lender                                 |
| Collateral release on repayment | Receiving borrower                               |
| Position NFT transfer           | Recipient                                        |

## Adapters

The registry is an adapter interface so that the policy engine can change without touching the core:

* **EAS adapter** (launch): reads attestations by schema and issuer.
* **ONCHAINID adapter**: for ERC-3643-compatible identities.
* **Chainlink ACE / CCID adapter**: an alternative policy engine that can be enabled through the timelock.

The list of accepted issuers and schemas is a `ParamController` value, so tightening or replacing a provider is a timelocked, logged change rather than a redeploy.

## Permissioned collateral

If Stock Tokens or bridged RWAs adopt ERC-7943 (uRWA) or ERC-3643 hooks, the escrow contract calls `canTransfer` and `canReceive` defensively and is itself allowlisted by the issuer. The token's own rules and the protocol's rules are both satisfied without either having to trust the other. See [Collateral roadmap](/collateral-and-assets/future-collateral.md).

## Geo-fencing

Restricted jurisdictions are excluded in layers:

1. Attestations are not issued to wallets in restricted jurisdictions.
2. A jurisdiction self-attestation is required on every wallet at onboarding.
3. The front-end applies IP-based geo-fencing for restricted jurisdictions.
4. The sequencer applies its own sanctions screening.

See [Jurisdictions](/compliance/jurisdictions.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.syndromics.xyz/architecture/eligibility.md?ask=<question>&goal=<endgoal>
```

`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.
