> 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/protocol/overview.md). # Protocol at a glance Ethosis has no lending pool. Nobody deposits USDG into a common balance, and no utilisation curve decides what a borrower pays. In its place there is a public book of signed messages, one origination contract that consumes them, and a small set of participants whose every action is recorded on-chain. ## Participants | Participant | Responsibilities | Access control | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | **Borrower** | Owns Stock Tokens. Posts borrow requests, submits originations, repays, adds collateral and rolls loans over. | Needs the `BORROWER` role in the access registry | | **Lender** | Signs targeted or standing offers, holds slice tokens, is repaid in proportion to principal, and may opt into idle-capital parking and in-kind liquidation. | `LENDER_PROFESSIONAL` today; `LENDER_RETAIL` in permitted regions | | **Keeper** | Starts collateral auctions, accepts rollover bids for lenders who delegate that, pushes margin alerts and rebalances parked capital. Earns part of each penalty. | `LIQUIDATOR` role to take collateral; every other action is open | | **Relayer** | Keeps and serves signed offers, checks them against chain state and proposes matches. Permissionless to operate. | `RELAYER` role only when submitting transactions for users | ## What the contracts track * **Market.** The tuple `(collateralToken, loanToken, oracle, ltvConfig)`. Each market is walled off from the others: the same Stock Token may appear in several markets with different loan assets or parameters, and trouble in one market has no path into another. * **Borrow request.** The borrower's stated intent. It lives with the relayer, and targeted offers point at its hash. * **Offer.** An EIP-712 `LendOffer` message. Detailed in [Intents: signing, matching and origination](/protocol/offers-and-matching.md). * **Loan.** The on-chain record written at origination. A loan has exactly one borrower and one collateral escrow, and one or more slices. * **Slice.** A single lender's portion of a loan, represented by a slice token. Detailed in [Many lenders, one loan](/protocol/syndication.md). ## One loan, end to end ```mermaid flowchart LR B[Borrower] -->|1. posts request| R[(Relayer book)] L[Lenders] -->|2. sign offers| R R -->|3. proposed fill| B B -->|4. originate with request, offers, sigs| S[LoanDesk] S -->|eligibility| E[AccessRegistry] S -->|price and session| O[PriceGate] S -->|lock| C[(Collateral escrow)] S -->|draw USDG| L S -->|principal out| B S -->|issue| P[Slice tokens] B -->|5. repay or roll over| S K[Keeper] -->|6. HF under 1.0| A[CollateralAuction] ``` 1. The borrower publishes a request naming the collateral token and amount, the principal wanted, the highest APR acceptable, a term of 7, 14, 30 or 90 days, and a deadline by which it must fill. 2. Lenders respond by signing offers off-chain. An offer can be aimed at that one request, or it can stand against a token or a whole tier and wait for any request that fits. 3. The borrower, or a keeper working for them, pulls a matching set of offers from the relayer. 4. A single `originate` transaction does the rest: it verifies every signature and eligibility, prices the collateral through the oracle with the session haircut applied, checks LTV, locks the collateral, draws USDG from each lender and issues one slice token per slice. 5. From that block onward interest accrues every second at each slice's fixed APR. Once the minimum interest period has passed the borrower can repay whenever they like, or open a rollover auction ahead of maturity. 6. Should the collateral lose enough value to push the health factor under 1.0, any address can open a Dutch auction on it. Lenders are made whole first and whatever remains goes back to the borrower. Each of these steps emits an on-chain event. The single off-chain piece is the book of signed offers that have not yet been used, and that book is public and mirrored by the indexer. ## Guarantees by omission * Lender funds are never taken into custody ahead of a match. * Nothing is lent without a live oracle price. The one intended exception is on the roadmap: negotiated Tier D loans, limited to professional lenders, which carry no automatic liquidation. * Losses are never socialised across loans. * Repayment, and collateral withdrawal after repayment, can never be paused. ## Where to go next * [Loan states and transitions](/protocol/loan-lifecycle.md) walks through the state machine. * [Loan health and collateral auctions](/protocol/health-and-liquidation.md) covers the risk mechanics. * [Smart contracts](/architecture/smart-contracts.md) lists the on-chain components. --- # 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/protocol/overview.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.