> For the complete documentation index, see [llms.txt](https://docs.usegimbal.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.usegimbal.app/collateral/tiers-and-ltv.md). # Tiers and loan-to-value limits The three numbers a tier fixes for every loan against a token, the parameters currently in force for tiers A to D, and how a token moves between tiers. Every loan on Gimbal inherits three limits from its collateral token's tier: how much can be borrowed against it at origination, the point at which a collateral auction can begin, and how far both figures drop while the underlying market is shut. Liquidity depth and oracle quality alone decide the tier. Ticker, issuer brand and popularity count for nothing. ## Current parameters | Tier | Contract tier id | Max LTV, regular session | Liquidation LTV | Closed-market haircut | | ---- | ---------------- | ------------------------------------------------- | ------------------------------ | --------------------- | | A | 1 | 55% | 70% | 10 points | | B | 2 | 45% | 60% | 10 points | | C | 3 | 30% | 45% | 15 points | | D | not configured | Negotiated by the lender, 25% or less recommended | None; default at maturity only | Not applicable | | Tier | What sits in it | Remarks | | ---- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | A | Mega-caps and index products: NVDA, AAPL, MSFT, SPY, QQQ | The deepest DEX pools on Robinhood Chain | | B | Single-name large caps, about the hundred deepest by DEX liquidity | | | C | Everything else that has a live Chainlink feed | Each lender opts in one token at a time | | D | No live oracle: tokens tied to private companies (linked to SpaceX or OpenAI), where they are still sold | No automatic liquidation. On the roadmap, professional lenders only | {% hint style="info" %} Live values, read from `PolicyBoard.tierConfig`. Each change goes through the timelock with a published rationale and a governance-log entry. See [How parameters change](/transparency/parameter-changes.md). {% endhint %} The board refuses a tier whose max LTV exceeds its liquidation LTV, whose liquidation LTV exceeds 100 percent, or whose haircut is larger than its max LTV, so a haircut can never push a ceiling below zero. ## What each number does **Max LTV** caps the loan at the moment it is written. The desk divides the requested principal by the collateral's value, in basis points, and rejects the request if the result is above the ceiling (`LtvTooHigh`). Each lend offer also carries its own `maxLtvBps`, and an offer only fills a request whose LTV is at or under that figure. A lender can insist on less leverage than the tier permits, and can never grant more. **Liquidation LTV** is where the health factor equals 1.0. The distance between it and the max LTV is the cushion a borrower has before a warning, and then before an auction. See [Health factor and the collateral auction](/mechanics/health-and-auctions.md). **The closed-market haircut** is subtracted from both of the other two whenever the quote comes from a closed session or the feed has gone stale. Take a Tier A loan written at 55% late on a Friday: over the weekend its liquidation LTV is 60%, not 70%. The same rule applies at origination, so on a closed market the Tier A ceiling is 45%. A stale price during a live session is not haircut; it blocks origination. See the [pricing and sessions](/risk/pricing.md) page. ## Exposure caps A tier limits leverage per loan. A cap limits size per token. `TokenConfig.exposureCap` sets a ceiling on the principal owed against one collateral token, summed over every loan, and the desk reverts with `ExposureCapExceeded` once a request would cross it. Caps start small, anchored to the token's observed DEX depth and past auction clearing, and grow as liquidation history builds. Telemetry shows each token's cap and how much of it is in use. ## How a token changes tier A token's tier is one field in its `TokenConfig` on the PolicyBoard. It is reviewed against four inputs: * whether the token's DEX depth on the chain has held over time, * the Chainlink feed's quality: update cadence, deviation threshold, and whether Data Streams cover the token, * how past auction clearing prices lined up against the oracle, * corporate actions and issuer events. When the batch executes, new loans use the new tier at once. Open loans keep their rate and their term. Their liquidation LTV is not fixed: the desk reads the token's current tier each time it computes a health factor, so a lower threshold reaches open loans the moment the change executes. The timelock delay is the notice, and a demotion is scheduled in the open so borrowers can top up before it lands. ## Tier D: lending with no oracle Tier D covers tokens that have no live price feed, meaning private-company tokens. A loan against one is a bilateral arrangement negotiated between professionals. Without a price there is nothing to liquidate against, so nothing liquidates automatically. Recovery runs through maturity alone: if the borrower has not repaid by the end of the grace window, the collateral passes to the lenders. Tier D sits on the roadmap, open only to `LENDER_PROFESSIONAL`; full documentation follows when its market opens. --- # 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.usegimbal.app/collateral/tiers-and-ltv.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.