> For the complete documentation index, see [llms.txt](https://docs.syndromics.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.syndromics.xyz/introduction/design-principles.md). # Design principles Syndromics borrows what has worked in on-chain lending (Morpho Blue's isolated, oracle-agnostic minimalism; Blend and NFTfi-style signed offers with on-chain settlement; Blend's refinancing auctions) and deliberately avoids what has failed. The following principles are the filter every design decision passes through. ## 1. Overcollateralised only Version one accepts only loans backed by liquid, oracle-priced, on-chain collateral held by the escrow contract. There are no uncollateralised loans, no off-chain collateral and no reliance on legal recovery. If a loan goes bad, the remedy is a liquidation auction that any address can trigger. ## 2. Price the exact token you hold The protocol values the token that is actually in escrow, never a wrapper, a derived exchange rate or a proxy. The Edel Finance loss in July 2026 came from a wrapper rate that was pushed 78 times higher than the underlying while the oracle itself was correct. That single rule would have prevented it. ## 3. Isolate risk Every lender slice is its own position. Every collateral and loan-asset pairing is its own market configuration. One bad asset, one bad borrower or one bad lender decision cannot contaminate anyone else. Bad debt, if it ever occurs, lands on the lender who priced the loan and nobody else. ## 4. Negotiate the rate, fix the term There is no utilisation curve. Borrowers state a ceiling, lenders state a price, and the contract settles whatever overlaps. Terms are fixed (7 to 90 days) with a refinancing auction at maturity, so lenders know their duration and borrowers are never surprised by a rate spike. ## 5. Never custody before a match Signed offers are just messages. Funds move only at settlement through `permit`, Permit2 or a prior approval. Unmatched lender capital is not held by Syndromics; if the lender opts in, it sits in a whitelisted Morpho vault under the lender's own allowance. ## 6. Small, immutable core The settlement contract is a minimal singleton in the Morpho Blue style with no upgradeability. Parameters (LTV tiers, haircuts, staleness bounds, fee rates, whitelisted vaults and oracles) live in a separate controller behind a timelocked multisig, and every change emits an event. Repayment and post-repayment withdrawal are never pausable. ## 7. Design for the chain you are on Robinhood Chain has a single sequencer, 24/5 equity price feeds with market-status flags, and Stock Tokens that carry no on-chain transfer restrictions. The protocol handles sequencer outages with a grace period and L1 forced inclusion, applies session-aware haircuts when markets are closed, and enforces eligibility itself at the protocol boundary. ## 8. Everything observable Every state change is an event. The order book is public and reconstructible from signed messages. The loan registry, risk page, oracle status and governance log are all public. Contracts, relayer, indexer and keeper bots are open source with reproducible builds. See [Transparency commitments](/transparency/commitments.md). --- # 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.syndromics.xyz/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.