> 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/risk/register.md). # The risk register Every material risk Gimbal carries, ranked by severity and paired with the control that answers it, plus the limits the protocol keeps on itself and the points where protection ends. Two commitments sit underneath the whole protocol. A lender is owed collateral that covers the debt. A borrower is owed a liquidation that follows published rules and cannot surprise them. Each mechanism in Gimbal serves one of those two commitments, and the register below is the list of what could break them. The pages after this one take the largest items one at a time: [pricing](/risk/pricing.md), [the sequencer](/risk/sequencer.md), [the token issuer](/risk/issuer.md) and [the precedents](/risk/precedents.md) that shaped the design. ## Limits the protocol keeps on itself Gimbal is deliberately narrow. The envelope today: * Only Tier A and Tier B tokens are accepted as collateral. * Each token has a published dollar cap on outstanding principal, and the caps start small. * Lending is limited to professional lenders. Borrowing is limited to verified businesses and verified professionals. * Telemetry, the risk page anyone can open, publishes the LTV distribution, concentration by token, bad debt (target: zero), and every liquidation, with the realised price shown next to the oracle price at the time. A cap moves up only after liquidation and repayment history has accumulated behind it. Growth follows the data rather than leading it. ## The register | Severity | Risk | Control | | ------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | High | Exposure to the Stock Token issuer, a Jersey company whose debt instrument carries freeze rights | Tier LTVs carry a discount for it. Deployed bytecode is read for freeze roles before a market opens. Where a feed publishes proof of reserve, Telemetry shows it. Every token has its own concentration cap. See [The issuer behind every Stock Token](/risk/issuer.md). | | High | Gaps between the Friday close and the next open, and across any closed session | Session-aware haircuts, an auction floor that is bounded while the market is closed, opt-outs for lenders and conservative tier LTVs. See [Pricing, sessions and the price checks](/risk/pricing.md). | | High | Shallow DEX liquidity in a single stock | Collateral goes through a Dutch auction and is never sold into a DEX. Lenders can take it in kind. Each token's cap is sized to the on-chain depth actually observed. | | High | A regulator reclassifying the lender-side instrument in one jurisdiction or another | Lending is restricted to professional lenders. The front end is geo-fenced. Eligibility is a swappable module, so rules tighten without a redeploy. See [Compliance at the boundary](/compliance/boundary.md). | | Medium | A centralised sequencer that stops or censors | A grace period driven by the uptime feed, and a route to every function via the L1 delayed inbox. See [When the sequencer stops](/risk/sequencer.md). | | Medium | An oracle that fails or is manipulated | Chainlink Feeds and Streams are cross-checked, staleness bounds apply per session, a move cap trips a pause, `oraclePaused` halts the market, and the token in escrow is the token that is priced, never a wrapper. | | Medium | A bug in the contracts | A small immutable core, formally verified, audited twice, opened to a public contest, covered by a bounty, and caps that rise in stages. See [Assurance](/architecture/assurance.md). | | Medium | Too few lenders, an empty book | Standing offers, yield on parked capital, and professional lenders seeded before each market opens. | | Medium | Chain activity concentrating in memecoins rather than RWAs | Serve the Stock Token and RWA holders who already exist, $100M-plus of them, and grow alongside Robinhood's own tokenisation roadmap. | | Low to Medium | Pooled lending markets adding single-stock collateral | Fixed terms, isolated positions, long-tail coverage and syndication are structural features a pool cannot copy. Gimbal interoperates with pooled markets rather than fighting them. | ## Where the protection ends The limits of the design deserve the same plain language as its defences. * A lender who misprices a slice loses on that slice. That outcome is intended, not a failure of the system. * A borrower who lets the warnings pass is liquidated at whatever price the auction reaches. That price can be under the oracle, and while the market is closed it often will be. * The issuer failing is a genuine loss scenario. LTVs shrink the damage; nothing removes it. * Tier D, a roadmap tier for tokens without a live feed, has no liquidation. Recovery there depends on the borrower paying, or on the lender claiming the collateral at maturity. ## Changing a risk parameter Tier LTVs, closed-market haircuts, the staleness bound for each session, move caps, the shape of the auction curve, the split of the liquidation penalty, per-token caps, plus the oracle and vault whitelists: all of these are risk parameters. Each one changes the same way: 1. Someone proposes the change, writes down the rationale, and backtests it against price history wherever history exists. 2. The proposal sits in public for the whole timelock period. 3. It executes on chain and emits an event. 4. It is recorded in the public governance log. [How parameters change](/transparency/parameter-changes.md) walks through the process step by step. --- # 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/risk/register.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.