> 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/platform-architecture/design-objective.md).

# Design Objective

The architecture serves one requirement above the rest: a lender, a borrower, an auditor, or an integrator should be able to reconstruct the state that matters to them from independent sources, without asking Quantix to vouch for it.

Three design commitments follow from that.

**Verifiable settlement.** Everything that determines who is owed what — deposits, withdrawals, drawdowns, repayments, and pool balances — is recorded on-chain. A lender's claim on a pool is not an entry in a private database; it is on-chain state that anyone can read.

**A clean on-chain / off-chain seam.** Legal enforceability and identity require documents and counterparties that do not belong on a public ledger. Rather than force those on-chain or hide the balances that should be public, the system keeps each where it belongs and links them, so that an on-chain position corresponds to an off-chain agreement and neither contradicts the other.

**Least privilege.** Administrative power is scoped to function and, wherever possible, constrained by timelocks and multiple signatures. The goal is that no single party can unilaterally move user funds or silently change protocol behavior, and that any privileged action is observable. The specific powers and who holds them are documented under Smart-Contract Modules and Upgradeability, and again under Security.

These commitments are what let the rest of the documentation make verifiable claims. A protocol that keeps critical state in private systems cannot honestly ask an institution to diligence it; one that keeps that state on-chain can.