> For the complete documentation index, see [llms.txt](https://docs.firelight.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.firelight.finance/protocol-architecture.md).

# Protocol Architecture

This section documents the protocol's components: the on-chain contracts, the off-chain services, and the liquidation pipeline that executes payouts.

### What you'll find here

* [On-Chain Components](/protocol-architecture/on-chain-components.md) covers the smart contracts stakers, program operators, and the Risk Consortium interact with directly.
* [Off-Chain Components](/protocol-architecture/off-chain-components.md) covers the services that monitor risk, match orders, and drive liquidation execution.
* [Claims Liquidation](/protocol-architecture/claims-liquidation.md) walks through the payout waterfall, liquidation sizing, and post-payout recovery.

{% hint style="info" %}
A deeper technical treatment of the vault contract surface is maintained separately and will be added once finalized. The MVP-relevant vault model is described in [Core Concepts → Vault Architecture](/core-concepts/vault-architecture.md).
{% endhint %}

### How the pieces fit together

Firelight separates responsibilities between contracts and supporting services:

* **Contracts** handle things that must be transparent, immutable, or atomic: capacity publication, coverage issuance, the on-chain incident record, vote tallying, slashing instructions, and fund movements.
* **Supporting services** handle things that depend on large data inputs or rapidly changing conditions: real-time risk monitoring, premium pricing, order matching at period boundaries, execution sizing for liquidation, and custody-policy enforcement.

This separation is designed so that anyone reading on-chain state can verify outcomes (coverage active, incidents validated, payouts executed) even though some supporting computations happen elsewhere. Supporting services publish their outputs on-chain where they are material (for example, the Cover Registry's capacity and rates).

### Trust assumptions

| Component                 | Trust assumption                                                                                                                          |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Smart contracts           | Audited and immutable within version bounds                                                                                               |
| Cover Registry parameters | Produced off-chain, written on-chain. Trust in the off-chain monitoring/pricing services and the authorities that can update the registry |
| Matching engine           | Runs off-chain. Output is visible on-chain (which orders matched at what amounts and premium)                                             |
| Liquidation service       | Runs off-chain with on-chain settlement. Slashed collateral routes into a permissioned execution pipeline                                 |
| Risk Consortium           | Independent of the Network and commercial counterparties. Conflicts declared on-chain. 3-of-5 quorum enforced                             |
| Firelight Network         | Holds treasury and engages service providers. Does not direct consortium votes or end-user payouts                                        |

Where on-chain verification is practical, the protocol uses it. Where it is not (for example, complex risk monitoring), off-chain outputs are signed and written to the relevant contracts.


---

# 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.firelight.finance/protocol-architecture.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.