> 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/risk/framework.md). # The Farlight risk register The register of material risks Farlight carries, how severe each one is, and the control that answers it. Farlight exists to manage risk; the lending is what happens once the risk is handled. Two promises hold the design together. Lenders are promised collateral that covers what they are owed. Borrowers are promised liquidations that are fair and predictable. Every mechanism on the platform can be traced back to one of those two commitments. This page sets out the material risks as a register, with the control that answers each one. The pages that follow look closer at oracles, the sequencer, the token issuer and the failures of earlier lenders. ## Register | Risk | Severity | Control | | -------------------------------------------------------------------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issuer exposure on Stock Tokens, a Jersey debt instrument whose issuer holds freeze rights | High | Tier LTVs price it in; bytecode is reviewed for freeze roles; proof of reserve is displayed wherever a feed exists; each token carries a concentration cap. Detail in [Issuer exposure on Stock Tokens](/risk/issuer.md). | | Price gaps across weekends and closed markets | High | Haircuts that follow the trading session, bounded auction floors, lender opt-outs and conservative tier LTVs. Detail in [Oracles, sessions and the price checks](/risk/oracles.md). | | Thin DEX liquidity in single names | High | Collateral is sold by Dutch auction, never dumped into a DEX; liquidation settles in kind; per-token caps are sized to the depth actually observed. | | Regulatory change in how the lender-side instrument is classified from one jurisdiction to another | High | Lending is open to professional lenders only; geo-fencing; eligibility is modular, so rules can tighten without a redeploy. Detail in [Compliance model](/compliance/model.md). | | Sequencer centralisation or downtime | Medium | A grace period keyed to the uptime feed; every function reachable through the L1 delayed inbox. Detail in [Surviving sequencer failure](/risk/sequencer-and-chain.md). | | Oracle failure or manipulation | Medium | Chainlink Feeds and Streams checked against each other, staleness bounds, move caps, a halt on `oraclePaused`; the exact escrowed token is priced, never a wrapper. | | Smart-contract bugs | Medium | A small immutable core, formal verification, two audits, a public contest, a bounty and staged caps. Detail in [Security programme](/architecture/security.md). | | Not enough lenders; an empty book | Medium | Standing offers, yield on idle capital, professional lenders seeded in advance. | | Chain activity drifting to memecoins rather than RWAs | Medium | Concentrate on the existing base of Stock Token and RWA holders, $100M-plus already; growth tracks Robinhood's tokenisation roadmap. | | Pooled markets listing single-stock collateral | Low to Medium | Fixed terms, isolation, long-tail coverage and syndication are things a pooled market cannot offer structurally; Farlight interoperates with them instead of competing. | ## How a parameter changes Tier LTVs, haircuts, staleness bounds per session, move caps, the auction curve, the penalty split, per-token caps and the whitelists of vaults and oracles are all risk parameters. None of them moves without going through the same four steps: 1. A proposal with a written rationale, backtested against historical prices wherever that is possible. 2. Publication for the full timelock period. 3. On-chain execution that emits an event. 4. An entry in the public governance log. [Parameter governance](/transparency/governance.md) covers the process in detail. ## Narrow by design Farlight operates inside deliberate limits: * Collateral from Tier A and Tier B only. * A published dollar cap per token, small to begin with. * Professional lenders only, and borrowers who are verified businesses or professionals. * Telemetry, the public risk page, showing the LTV distribution, concentration, bad debt (the target is zero) and the liquidation record, with realised prices set against the oracle. Caps rise as liquidation and repayment data builds up. They do not rise ahead of it. ## Where the protection stops The boundary of the protection deserves the same plain statement as the protections themselves. * A lender who prices a slice badly takes the loss on that slice. That is the intended outcome. * A borrower who ignores the warnings is liquidated at whatever the auction clears, and that can sit below the oracle price, most of all while the market is closed. * Issuer failure is a real loss scenario. LTVs make it smaller; they do not make it disappear. * Tier D loans carry no liquidation at all. They rest entirely on the borrower repaying or the lender taking the collateral. --- # 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/risk/framework.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.