> 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/syndication.md). # Syndicates and slices How one borrow request is filled by several lenders at once, what a slice token records, and how repayments and auction proceeds are divided between slices. A Farlight loan is a syndicated loan in miniature. Any number of lenders can fill a single borrow request, and each of them holds a proportional slice at the APR they chose. Syndication is not an add-on; it is how every loan is constructed. ## Why loans are syndicated * **Large loans can be assembled from small lenders.** Twenty lenders contributing 10,000 USDG each can fund a 200,000 USDG borrow against tokenised NVDA. * **Borrowers are not tied to one balance sheet.** Depth is a function of how many offers are resting in the book, not of any single large lender. * **Risk is never shared between lenders.** There is no pool and no communal bad-debt account. A lender who priced a slice at 8.5% owns that slice and nothing else. ## The slice token At origination the contract mints one ERC-721 slice token per lender. The collection is named Farlight Lender Slice, symbol FSLC. Each token records: * the loan ID and market, * the principal of the slice, * the slice's fixed APR, * the start timestamp, * the flags the lender chose (`selfLiquidate`, `noClosedMarketLiquidation`). Every slice accrues interest independently at its own APR. Repayments, rollover payouts and auction proceeds are all divided by slice principal. A slice token can change hands, but only to an address that passes the access registry. That single restriction is what makes a secondary market in loan positions possible without loosening compliance. ## The arithmetic of a split For a loan with slices (s\_1 \dots s\_n), principals (P\_1 \dots P\_n), and total principal (P): * A partial repayment (R) reduces the principal of slice (i) by (R \times P\_i / P). * Auction proceeds (X), once the keeper's share of the penalty has been taken out, pay slice (i) the amount (X \times P\_i / P), capped at that slice's outstanding principal plus accrued interest. Anything remaining is surplus and goes to the borrower. * The interest accrued to date on slice (i) is `P_i × apr_i × elapsed / 365 days`. Because slices carry different APRs, the effective rate the borrower pays is the principal-weighted average across them. ## Fills are all or nothing Origination is atomic, and the offers in the transaction must cover the request exactly. If the book cannot fund the whole request, nothing is originated; the borrower either lowers the principal or waits for more offers. Adding slices to an existing loan is on the roadmap. ## Senior and junior slices (roadmap) The next protocol release introduces tranching within a syndicate, modelled on the Centrifuge DROP/TIN pattern. A lender may elect the **junior** slice, which absorbs the first loss if an auction comes up short and earns a higher rate in return, while **senior** slices are paid before it. Tranching is chosen per offer, and lenders who never elect it see no change. The waterfall gets its own audit before it is enabled. ## Example: twenty lenders, one transaction A borrower wants 200,000 USDG against 2,500 NVDA tokens worth roughly 441,000 USDG, an LTV of 45.4%. The relayer assembles twenty standing offers of 10,000 USDG each, with APRs from 8.2% to 9.0%. One `originate` call then: * locks the 2,500 NVDA in escrow, * pulls 10,000 USDG from each of the twenty lenders (from the Morpho vault for those who opted in), * pays the borrower 199,500 USDG after the origination fee is deducted, * mints twenty slice tokens. If the borrower repays after 30 days at a blended 8.6%, interest comes to about 1,414 USDG, split across the twenty slices by each one's principal and its own APR. The protocol retains 10% of that interest as its share. --- # 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/syndication.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.