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

# Access control and attestations

Stock Tokens themselves impose no transfer restrictions on-chain; Robinhood enforces eligibility at its own interface and at the KYC'd points of issuance and redemption. A lending protocol built on those tokens therefore has to police eligibility on its own. Ethosis does this at the **protocol boundary**: each origination, each supply of capital, each refinance, and each party that receives collateral through a liquidation or a repayment is checked before anything moves.

## Role catalogue

| Role                  | Who holds it                                                                                                                                                                        | Status  |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `BORROWER`            | KYC'd wallets in non-restricted jurisdictions, tracking the Stock Token eligibility list. Today's borrowers 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, to be enabled one jurisdiction at a time where the rules allow                                                                                                      | Roadmap |
| `LIQUIDATOR`          | Any address permitted to receive collateral from an auction or an in-kind settlement                                                                                                | Live    |
| `RELAYER`             | Services that submit originations on a user's behalf                                                                                                                                | Live    |

## What an attestation contains

Every role is evidenced by an **Ethereum Attestation Service** attestation, compatible with ONCHAINID, which the KYC provider issues once identity, sanctions and residency checks have passed.

The attestation records:

* the wallet address;
* the role;
* a jurisdiction class (never the country itself, unless the user chooses to disclose it);
* an investor class, where one is relevant;
* an expiry.

There is no name in it, no document, and no personal identifier of any kind. Attestations lapse at expiry and are renewed through continuous re-screening. A revocation takes effect the moment it is made.

### Proving eligibility with zero knowledge

As an alternative, a wallet can present a credential (Privado ID or zkPass) that proves "eligible in jurisdiction class X, investor class Y" without disclosing which provider performed the check or any underlying attribute. The registry treats either form as valid.

## The single question the contracts ask

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

`LoanDesk`, `RolloverAuction`, `CollateralAuction` and `SliceToken` put this question for every party that matters to the action at hand, and a negative answer reverts the transaction. Read-only functions are left open to everyone so that indexers, explorers and aggregators can see the full picture.

### Checkpoints

| Action                          | Whose eligibility is checked                           |
| ------------------------------- | ------------------------------------------------------ |
| `originate`                     | The borrower (`BORROWER`) and each lender (`LENDER_*`) |
| `accept` in a rollover auction  | The incoming lender                                    |
| `buy` in a collateral auction   | The buyer (`LIQUIDATOR`)                               |
| In-kind liquidation             | The lender taking delivery                             |
| Collateral release on repayment | The borrower taking delivery                           |
| Slice token transfer            | The recipient                                          |

## Pluggable policy engines

The registry is defined as an adapter interface, which means the policy engine behind it can be replaced without touching the core:

* **EAS adapter** (in use today): resolves attestations by schema and issuer.
* **ONCHAINID adapter**: for identities compatible with ERC-3643.
* **Chainlink ACE / CCID adapter**: a different policy engine that the timelock can switch on.

Accepted issuers and schemas are stored as a `PolicyController` value. Tightening the list or replacing a provider is therefore a timelocked, logged parameter change, not a new deployment.

## Collateral with its own transfer rules

Should Stock Tokens or bridged RWAs adopt ERC-7943 (uRWA) or ERC-3643 hooks, the escrow contract will call `canTransfer` and `canReceive` defensively and will itself be allowlisted by the issuer. Both the token's rules and the protocol's rules are satisfied, and neither side has to trust the other. The [collateral roadmap](/assets/future-collateral.md) has more.

## Keeping restricted jurisdictions out

Exclusion works in four layers, each independent of the others:

1. No attestation is ever issued to a wallet in a restricted jurisdiction.
2. Every wallet must self-attest its jurisdiction during onboarding.
3. The front-end geo-fences restricted jurisdictions by IP.
4. The sequencer runs its own sanctions screening.

The [Jurisdictions](/compliance/jurisdictions.md) page lists the details.


---

# 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.ethosis.org/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.
