> For the complete documentation index, see [llms.txt](https://docs.miragefi.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.miragefi.org/introduction/design-principles.md). # Design principles The eight principles against which every MirageFi design decision is tested. ## 1. The reference price is the truth The authoritative price of an RWA is formed on the venue where the underlying trades, and MirageFi never pretends otherwise. Each quote is built outward from the Chainlink mid, each fill is bounded against it, and [execution quality](/transparency/execution-quality.md) is measured against it and published. The protocol does not exist to discover the price of Apple; it exists to deliver that price on-chain, at any hour, with the cost of doing so stated plainly. ## 2. Honest quotes The mid, the spread and the protocol fee appear on a quote as three separate, labelled numbers. The session badge is on the ticket rather than in a tooltip: while US markets are closed, the trader reads "closed session, spreads widened" before signing, never afterwards. There is no payment for order flow, no hidden markup and no fee buried in the curve. Economics that cannot survive being itemised are the wrong economics for the venue. ## 3. Non-custodial, always User assets are never held by MirageFi. Traders keep custody themselves and sign every swap; vault inventory belongs to LPs and sits in immutable contracts; RFQ settlement moves assets straight from maker to taker. The emergency pause can halt new swaps, but it can never reach funds or prevent an LP from withdrawing. ## 4. Compliance at the protocol boundary Because Stock Tokens carry no on-chain transfer restrictions, any venue that lists them has to decide for itself who may trade. MirageFi enforces eligibility at every entry point using attestations, keeps personal data off-chain, and tells an ineligible user why before they sign instead of reverting afterwards. See the [Compliance model](/compliance/model.md). ## 5. Sessions are first-class At 3pm on Tuesday and at 3am on Sunday an equity token is a different asset, and the protocol prices that difference rather than ignoring it. Spreads, clip sizes and halts are all determined by the [trading regime](/protocol/trading-regimes.md), which is driven by the oracle's market-status field and never by guesswork. ## 6. Isolation per market Every listed asset has its own vault, with its own inventory, its own parameters and its own LPs. A dislocation, halt or delisting in one market cannot reach another. There are no shared pools and no socialised losses. ## 7. Everything is inspectable Each fill links to its transaction on Blockscout. Each parameter can be read from a public contract. Each parameter change passes through a timelock with a published rationale. The [trade explorer](/using-miragefi/trade-explorer.md) exists so that "transparently on-chain" is a claim anyone can verify, not a slogan. ## 8. Design for the chain's failure modes A single sequencer can fail while the underlying market continues to move. Oracles can go stale. Corporate actions pause feeds. Every one of these has a designed response (halt, widen, grace period), documented in the [Risk](/risk/framework.md) section, because a venue that works only when everything else works is not infrastructure. ## What these principles rule out * No liquidity funded by emissions. Liquidity is paid for out of real spread revenue or not at all. * No leverage, margin or liquidations. The venue does a single thing. * No discretionary intervention in pricing. Parameters change through the timelock, and quotes come from the formula. --- # 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.miragefi.org/introduction/design-principles.md?ask=&goal= ``` `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.