> For the complete documentation index, see [llms.txt](https://quantixfinance.gitbook.io/quantixfinance-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quantixfinance.gitbook.io/quantixfinance-docs/security-and-operational-resilience/security-model.md).

# Security model

Credit risk is managed in the Risk Management section. This section addresses everything else that could cost a lender money — a contract fault, a compromised key, a hijacked interface, a failed dependency, an operational error — and the protocol is architected so that none of these has a clear path to funds.

The model rests on four commitments that are built into the system rather than added on top of it.

**Faults are contained.** The on-chain system is split into independent modules — token, pool, loan, collateral and liquidation, first-loss, and access control — so a code-level defect or exploit in one module cannot reach the others. This separation is architectural, not economic: QFI is not required as a settlement asset for lending, but it can be posted as delegate collateral on the same terms as other accepted assets, which means QFI's market price is directly connected to credit-facility health wherever it's used that way. Module separation limits how far a technical fault can spread; it does not, and is not intended to, insulate loan coverage from QFI's own price volatility where QFI sits behind a facility as collateral.

**Privilege is minimal and observable.** Administrative capabilities are scoped narrowly, governed by a 2-of-3 multi-signature authorization rather than a single key, and the most sensitive changes execute only after a 24–48 hour time delay. Privileged actions emit on-chain events, so they can be seen as they happen rather than discovered afterward.

**Defenses are layered.** Contract security, key security, application security, and operational security are independent, each built on the assumption that another may fail. A phishing attempt that fools a user, a bug that survives review, or a compromised operator device each meets a further control rather than an open path to capital.

**Security is verifiable.** Contract addresses, deployment details, governance parameters, and completed audits are published so a reviewer can confirm the protocol's security properties directly rather than take them on trust.