> For the complete documentation index, see [llms.txt](https://docs.usefarlight.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usefarlight.com/architecture/eligibility.md). # Eligibility and the attestation registry The roles a wallet can hold on Farlight, the attestations that prove them, and the exact points at which the contracts check before anything moves. Every loan on Farlight can be seen from a distance. Who is allowed to stand behind one is decided up close, at the edge of the protocol. Stock Tokens carry no transfer restriction of their own on-chain: Robinhood enforces eligibility at its own interface and at the KYC'd points where tokens are issued and redeemed, not inside the token contract. A protocol that lends against those tokens therefore has to draw its own line. Supplying capital, originating a loan, refinancing one, and taking delivery of collateral after a liquidation or a repayment are each preceded by an eligibility check on the parties involved. A failed check stops the transaction before any value changes hands. ## The roles | Role | Who holds it | Status | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | `BORROWER` | Wallets that have passed KYC in a jurisdiction that is not restricted, following 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, such as credit funds, market makers and family offices | Live | | `LENDER_RETAIL` | Retail lenders, switched on one jurisdiction at a time where regulation permits | Roadmap | | `LIQUIDATOR` | Any address allowed to take collateral from an auction or an in-kind settlement | Live | | `RELAYER` | Services that submit originations on behalf of a user | Live | ## What an attestation records Each role is evidenced by an attestation on the **Ethereum Attestation Service**, in a form compatible with ONCHAINID. The KYC provider issues it once identity, sanctions and residency checks have all passed, and it holds five things: * the wallet address; * the role; * a jurisdiction class, never the country itself unless the user chooses to disclose it; * an investor class, where one applies; * an expiry. Nothing else is stored. There is no name, no document and no personal identifier of any kind. An attestation lapses when it expires and is renewed through continuous re-screening. A revocation is effective from the moment it is made. ### Zero-knowledge credentials A wallet may instead present a credential from Privado ID or zkPass that proves the statement "eligible in jurisdiction class X, investor class Y" while revealing neither the provider that ran the check nor any of the underlying attributes. The registry accepts both forms without distinction. ## One question, one answer The contracts only ever ask the registry one thing: ```solidity function isEligible(address account, bytes32 role) external view returns (bool); ``` `LoanDesk`, `RolloverAuction`, `CollateralAuction` and `SliceToken` call it for every party that matters to the action in hand, and a negative answer reverts the transaction. Read-only functions stay open to all, so indexers, explorers and aggregators see the whole protocol without holding a role. ### Where the checks sit | 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 | ## Interchangeable policy engines Behind the registry sits an adapter interface, so the policy engine can change while the core stays untouched: * **EAS adapter**, in use today, which resolves attestations by schema and issuer. * **ONCHAINID adapter**, for identities compatible with ERC-3643. * **Chainlink ACE / CCID adapter**, an alternative policy engine that the timelock can enable. The accepted issuers and schemas live in a `PolicyController` value. Narrowing that list or swapping a provider is a timelocked and logged parameter change rather than a redeployment. ## Collateral that carries its own rules If 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. The token's rules and the protocol's rules are both honoured, and neither side has to trust the other to get it right. The [collateral roadmap](/assets/future-collateral.md) covers this in more depth. ## Four layers against restricted jurisdictions Each layer works on its own; none depends on another holding: 1. No attestation is issued to a wallet in a restricted jurisdiction. 2. Every wallet self-attests its jurisdiction during onboarding. 3. The front-end geo-fences restricted jurisdictions by IP address. 4. The sequencer performs its own sanctions screening. The specifics are on the [Jurisdictions](/compliance/jurisdictions.md) page. --- # 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.usefarlight.com/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.