> For the complete documentation index, see [llms.txt](https://docs.ethosis.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethosis.org/introduction/design-principles.md). # Principles behind the design Ethosis keeps the parts of on-chain lending that have proven themselves and leaves out the parts that have not. From Morpho Blue it takes isolated markets, oracle-agnosticism and a minimal core. From Blend and NFTfi-style designs it takes signed offers that settle on-chain, and from Blend specifically the refinancing auction. The eight rules below are the test each design choice has to pass. ## 1. Collateral in escrow, always worth more than the debt The current version lends only against liquid, oracle-priced collateral that lives on-chain and is held by the escrow contract. It does not make uncollateralised loans, does not accept off-chain collateral, and does not rely on courts for recovery. When a loan fails, the remedy is a liquidation auction that any address may start. ## 2. Value the token in escrow, nothing else What the protocol prices is the token actually sitting in escrow. It never prices a wrapper, a derived exchange rate or a stand-in. The Edel Finance loss of July 2026 happened because a wrapper's rate was driven to 78 times the underlying while the oracle itself reported correctly. This one rule would have stopped it. ## 3. Keep every exposure separate Each lender slice is a position of its own, and each pairing of collateral and loan asset is a market configuration of its own. A bad asset, a bad borrower or a bad lending decision stays with the party that took it on. Should bad debt ever arise, it falls on the lender who priced that loan and on no one else. ## 4. Rates by negotiation, terms by contract Nothing in the protocol resembles a utilisation curve. A borrower names a ceiling, lenders name their price, and the contract originates whatever overlaps. Terms run from 7 to 90 days and are fixed, with a refinancing auction when they end, so a lender knows how long their money is committed and a borrower is never hit by a sudden rate jump. ## 5. No custody until a match exists A signed offer is only a message. Money moves at origination and not before, via `permit`, Permit2 or an earlier approval. Ethosis does not hold unmatched lender capital; a lender who opts in can leave it in a whitelisted Morpho vault, under an allowance the lender controls. ## 6. A small core that cannot be changed The origination contract, LoanDesk, is a minimal singleton in the Morpho Blue mould with no upgrade path. Everything tunable (LTV tiers, haircuts, staleness bounds, fee rates, the whitelists of vaults and oracles) lives in PolicyController, a separate contract controlled by a timelocked multisig, and each change emits an event. Repayment, and withdrawal after repayment, can never be paused. ## 7. Built for Robinhood Chain specifically The chain has one sequencer, equity price feeds that run 24/5 and carry market-status flags, and Stock Tokens with no transfer restrictions at the token level. Accordingly the protocol gives a grace period after a sequencer outage and supports forced inclusion from L1, applies haircuts that depend on the market session when markets are closed, and enforces eligibility itself at its own boundary. ## 8. Nothing hidden Every change of state emits an event. The order book is public and can be rebuilt from the signed messages. The loan registry, the risk page, oracle status and the governance log are all open to anyone. The 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.ethosis.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.