Our documentation has been updated with details on Phase 2, how coverage works, claims payouts, and more.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

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 covers the smart contracts stakers, program operators, and the Risk Consortium interact with directly.

  • Off-Chain Components covers the services that monitor risk, match orders, and drive liquidation execution.

  • Claims Liquidation walks through the payout waterfall, liquidation sizing, and post-payout recovery.

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.

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 Foundation and commercial counterparties. Conflicts declared on-chain. 3-of-5 quorum enforced

Foundation

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.

Last updated