> 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/security.md).

# Verification, audits and safeguards

How the Farlight contracts are tested, verified, audited and operated, and what the holders of governance keys can and cannot do.

A probe far from home is trusted because every reading it sends back can be checked against another instrument. Farlight applies the same discipline to its contracts, following the approach Morpho Blue established: a core that is small and immutable, formally verified, independently audited and publicly contested, with exposure widened only as far as the evidence supports.

## How the code is tested

| Layer                | Tooling and scope                                                                                                                                                                                                                                                                                |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Unit and integration | Foundry, exercising every contract, every path and every revert reason. There are 65 tests covering origination, repayment, liquidation, refinancing and governance; the [Deployment](/architecture/deployment.md) page breaks them down file by file.                                           |
| Invariant and fuzz   | Foundry's invariant suite. It checks solvency (the sum of slice claims never exceeds escrow plus proceeds), that accrual is monotonic, that nonces and partial fills stay consistent, that the health factor moves monotonically with price, and that the auction curve stays within its bounds. |
| Mutation testing     | Confirms that the suite catches faults deliberately injected into the code.                                                                                                                                                                                                                      |
| Fork tests           | Run on forks of Robinhood Chain against the live Chainlink feeds, USDG and Morpho vaults.                                                                                                                                                                                                        |
| Formal verification  | Specifications over `LoanDesk` and `IntentBook`: nothing disburses without escrow, nothing releases collateral while debt remains, and no offer can be filled twice.                                                                                                                             |

The full suite runs on every change. A release is tagged only when all of it passes.

## Audits, contests and the bounty

* Each release of the contract set is **independently audited** before it reaches Robinhood Chain, and each audit is followed by a **public contest**. Reports are linked from this page as they are published.
* A **bug bounty** is open, sized in proportion to the protocol's exposure. Findings reported responsibly qualify from the day they are submitted.
* Nothing ships while a high or critical finding remains unresolved.

## Safeguards in operation

| Safeguard             | What it means in practice                                                                                                                          |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Immutable core        | `LoanDesk`, `IntentBook`, `SliceToken` and both auctions have no proxy and no admin.                                                               |
| Timelocked parameters | Every parameter sits behind a multisig with a timelock. Each change emits an event and is published with its rationale.                            |
| Emergency pause       | Applies to **new loans and liquidations only**. Repayment, and withdrawal of collateral after repayment, cannot be paused under any circumstances. |
| No access to funds    | The multisig cannot move escrowed collateral, lender principal or vault balances.                                                                  |
| Staged caps           | Per-token exposure caps start conservative and rise as liquidation and repayment data builds up.                                                   |
| Verified bytecode     | Builds are reproducible, and the source of every deployment is verified on Blockscout.                                                             |

## Threat model

| Threat                             | Response                                                                                                          |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Forged or replayed offers          | An EIP-712 domain that includes the chain ID; per-maker nonce bitmaps; partial fills tracked per offer hash       |
| A hostile relayer                  | Offers are re-verified on-chain. A relayer can withhold an offer but cannot alter one                             |
| Oracle manipulation                | Chainlink feeds and streams behind guards and cross-checks; move caps; the exact escrowed token is the one priced |
| Wrapper or derived-rate collateral | Refused outright. Each market is configured with the feed for its own escrowed token                              |
| Exploiting the weekend gap         | Session haircuts, bounded auction floors and lender opt-outs                                                      |
| Sequencer outage or censorship     | A grace period following an outage, and every function reachable through the L1 delayed inbox                     |
| Failure of the idle-capital vault  | Opt-in only, a single whitelisted vault, allowance-based, and within audit scope                                  |
| Compromised governance keys        | The timelock buys time to respond, and the keys can neither move funds nor pause repayment                        |

## Reporting a vulnerability

Send findings to <security@usefarlight.com> instead of opening a public issue. A responsible disclosure is acknowledged within one business day and is eligible for the bounty.


---

# 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/security.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.
