> 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/protocol/overview.md). # The protocol, end to end The four roles in the protocol, the objects the contracts record, and the path a loan follows from a signed request to its close. Farlight brings capital and collateral together from a long way apart, and it keeps every loan in plain view once they meet. There is no pool in the middle. USDG is never deposited into a shared balance, and no utilisation curve sets the rate. What exists instead is a public book of signed messages, a single origination contract that consumes them, and a handful of roles whose every action lands on-chain where anyone can inspect it through the [Observatory](/guides/loan-explorer.md), the public loan explorer at `/platform/explorer`. ## Who takes part | Role | What they do | How access is gated | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | **Borrower** | Holds Stock Tokens. Publishes borrow requests, sends origination transactions, repays, tops up collateral and rolls loans over. | Must hold the `BORROWER` role in the access registry | | **Lender** | Signs targeted or standing offers, holds slice tokens and is repaid pro rata to principal. May opt into idle-capital parking and in-kind liquidation. | `LENDER_PROFESSIONAL` today; `LENDER_RETAIL` in permitted regions | | **Keeper** | Opens collateral auctions, accepts rollover bids on behalf of lenders who delegate, sends margin alerts and rebalances parked capital. Receives part of each penalty. | `LIQUIDATOR` role to take collateral; every other action is open | | **Relayer** | Stores and serves signed offers, validates them against chain state and proposes matches. Anyone may run one. | `RELAYER` role only when submitting transactions for users | ## The objects the contracts know about * **Market.** A tuple of `(collateralToken, loanToken, oracle, ltvConfig)`. Markets are sealed from one another. One Stock Token can sit in several markets with different loan assets or parameters, and a problem in one has no route into the next. * **Borrow request.** What the borrower wants, as a signed message. It is held by the relayer, and targeted offers reference it by hash. * **Offer.** A lender's signed `LendOffer`, an EIP-712 typed message. [Signed offers and the originate call](/protocol/offers-and-matching.md) covers it field by field. * **Loan.** The record written on-chain at origination. Every loan has one borrower, one collateral escrow and at least one slice. * **Slice.** One lender's share of a loan, carried by a slice token. [Syndicates and slices](/protocol/syndication.md) explains how shares are computed. ## The path of a loan ```mermaid flowchart LR B[Borrower] -->|1. publishes request| R[(Relayer book)] L[Lenders] -->|2. sign offers| R R -->|3. proposed fill| B B -->|4. originate with request, offers, sigs| S[LoanDesk] S -->|eligibility| E[AccessRegistry] S -->|price and session| O[PriceGate] S -->|lock| C[(Collateral escrow)] S -->|draw USDG| L S -->|principal out| B S -->|mint| P[Slice tokens] B -->|5. repay or roll over| S K[Keeper] -->|6. HF under 1.0| A[CollateralAuction] ``` 1. The borrower publishes a request. It names the collateral token and amount, the principal sought, the highest APR they will pay, a term of 7, 14, 30 or 90 days, and a fill deadline, the request's launch window, after which it can no longer be filled. 2. Lenders answer with offers signed off-chain. An offer may target that single request, or it may stand against a token or an entire tier and wait for any request whose terms fit. 3. The borrower, or a keeper acting for them, asks the relayer for a set of offers that covers the request. 4. One `originate` transaction completes the deal. It checks every signature and every party's eligibility, prices the collateral through the oracle with the session haircut applied, tests the LTV, locks the collateral, pulls USDG from each lender and mints one slice token per slice. 5. Interest starts accruing in that block, every second, at each slice's own fixed APR. After the minimum interest period the borrower may repay at any moment, or open a rollover auction before maturity arrives. 6. If the collateral falls far enough to take the health factor under 1.0, any address may start a Dutch auction on it. Lenders are paid first; anything left returns to the borrower. Every one of these steps writes an event to the chain. The only piece held off-chain is the book of signed offers that have not yet been consumed, and that book is public and mirrored by the indexer. ## What the design rules out * Lender funds are never held in custody before a match exists. * No loan is made without a live oracle price. The single planned exception sits on the roadmap: negotiated Tier D loans, open to professional lenders only, with no automatic liquidation. * Losses stay with the loan that produced them and are never spread across others. * Repayment, and the withdrawal of collateral once a loan is repaid, cannot be paused under any circumstances. ## Continue reading * [Loan states and the flight log](/protocol/loan-lifecycle.md) describes the state machine and the event record behind each loan. * [Health factor and the collateral auction](/protocol/health-and-liquidation.md) covers health factors and liquidation. * [Smart contracts](/architecture/smart-contracts.md) lists every on-chain component. --- # 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/protocol/overview.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.