For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Last updated