> 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/architecture/assurance.md). # Assurance: tests, audits and safeguards The test layers behind the Gimbal contracts, the audit, contest and bounty programme, the safeguards that stay on in production, and the limits placed on whoever holds the governance keys. Gimbal follows the discipline Morpho Blue set out: a small immutable core, formally proved, audited and attacked by outsiders, with exposure widened only as fast as the evidence allows. ## Keys that cannot reach funds | Property | In practice | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No path to user money | The multisig has no way to touch collateral in escrow, principal owed to lenders, or anything parked in the vault. | | Immutable core | `TermDesk`, `OfferBook`, `LenderSlice`, `CollateralAuction` and `RolloverAuction` carry no proxy and no administrator. A new version is a new deployment. | | Everything else timelocked | Each tunable lives in `PolicyBoard` behind a multisig and a timelock. A change is queued with `schedule`, carries the hash of a published rationale, runs with `execute` once the delay has passed, and emits `ParamChanged`. A batch left unexecuted for 14 days goes stale. After bootstrap the delay can never drop below one hour. | | A narrow pause | The guardian's one power, `setPaused`, halts **originations and liquidations** and cannot lift a pause it raised. Repayment, collateral top-ups and the return of escrow after repayment have no pause switch at all. | | Exposure caps in stages | Every collateral token has a cap that opens conservatively and widens as liquidation and repayment history accumulates. | | Bytecode you can rebuild | The build is reproducible; each deployment's source is verified on Blockscout. | [How parameters change](/transparency/parameter-changes.md) walks through the timelock from a user's side. ## Five layers of testing | Layer | What runs | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unit and integration | Foundry. 109 tests in eight files (nine suites) cover origination, repayment, liquidation, rollover, pricing, parked capital and governance, every path and every revert. [Build and deploy](/architecture/build-and-deploy.md) breaks them down per file. | | Invariants and fuzzing | A handler drives a live loan through random repayments, top-ups and jumps in time while four ledger identities are asserted after each step: a loan's principal equals the sum of its slices, exposure per collateral equals live principal, escrow covers every loan's collateral, and the desk holds no loan token between transactions. Fuzz runs add that any partial repayment keeps the ledger consistent, any syndicate split repays in full, and a liquidation leaves no exposure behind. Targeted tests pin monotonic accrual, nonce and partial-fill bookkeeping, the health factor's response to price, and the auction curve holding above its floor. | | Mutation testing | Faults are injected into the source on purpose to confirm the suite notices. | | Fork tests | The suite is replayed against a Robinhood Chain fork, with the real Chainlink feeds, real USDG and the real Morpho vaults. | | Formal specifications | Proofs over `TermDesk` and `OfferBook`: no principal leaves without collateral in escrow, no collateral leaves while debt is outstanding, and no offer fills twice. | Every change runs the whole stack, and no release is tagged with anything red. ## Outside eyes * Every release of the contract set receives an **independent audit** before it goes to Robinhood Chain, and a **public contest** follows each audit. Reports get linked here once public. * The **bug bounty** is live and scaled to the protocol's exposure. A finding reported responsibly qualifies from the day it arrives. * A high or critical finding left open blocks the release. ## What the design expects to face | Threat | Answer | | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Forged or replayed offers | The EIP-712 domain binds the chain ID and the desk address; each maker has a nonce bitmap for cancellation; fills accumulate per offer hash, so capacity cannot be spent twice | | A relayer acting in bad faith | Each offer is verified again on chain. A relayer may sit on an offer; it cannot change one | | Manipulated prices | Feeds and streams from Chainlink sit behind session, staleness and pause guards that cross-check one another, plus a move cap, and the price is always for the exact token in escrow. See [Pricing, sessions and the price checks](/risk/pricing.md) | | Wrapped or derived-rate collateral | Rejected. Each market points at the feed of the token actually escrowed and nothing else | | The weekend gap | Closed-market haircuts, bounded auction floors and per-lender opt-outs | | The sequencer down or censoring | A grace window once the sequencer returns, with every call still possible via the delayed inbox on L1. See [When the sequencer stops](/risk/sequencer.md) | | The parking vault failing | Parking is opt-in, limited to one whitelisted vault, allowance-based and inside audit scope. See [Capital parked between fills](/mechanics/parked-capital.md) | | Governance keys compromised | The timelock gives everyone time to react, and the keys have no power to move funds or stop a repayment | ## Found something? Write to rather than filing a public issue. Responsible disclosures get an acknowledgement inside one business day and qualify for the bounty. --- # 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/architecture/assurance.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.