> For the complete documentation index, see [llms.txt](https://docs.tigris.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tigris.global/risk-management.md).

# Risk Management

Tigris approaches risk management under two principles.

**First, no reliance on the assumption that accidents will not happen**: roles may fail in their duties, keys may be stolen, assets may deteriorate — what the protocol guarantees is that when these things happen, losses are bounded and responsibility is attributable.

**Second, risk management belongs to the market, not to a committee**: the protocol maintains no internal risk desk; through staking, slashing, and open competition, it turns risk management into a public market in which managers can be chosen — and eliminated. The mechanisms below all follow from these two principles.

## Staking and Slashing

* **Qualification is the stake**: staking sSOSO above the minimum automatically confers curator status; no permission is required.
* **Delegation amplifies reputation**: users may delegate sSOSO to add weight to a curator's credit, with a cap on delegation as a share of the curator's total stake.
* **Slashing as the backstop**: a derelict curator's staked assets are slashed; falling below the minimum stake forfeits curator status immediately.
* **Exits carry cooldowns**: unstaking and revoking a delegation are both subject to a cooldown of 1–30 days.

Together these close the loop of a working market: curators vouch for their competence with stake, users express trust through delegation and subscription, and slashing punishes dereliction. Competition in risk management brings better and cheaper products — users need only choose whom to trust.

## Timelock

The timelock makes every change **publish first, take effect later**: any sensitive change must be scheduled in advance, remain publicly visible, and wait out its delay. Investors therefore always hold a guaranteed exit window — whoever disagrees with an incoming rule can leave before it takes effect; the rules never change beneath anyone's feet.

## Sentinel and the Emergency Brake

The sentinel equips the disclosure period with an **emergency brake**: the moment a scheduled change is identified as malicious or mistaken — a stolen curator key, a misconfigured parameter, or any other accident — the sentinel can revoke the change outright, or pause the vault and the market to stop the loss.

Since the sentinel cannot alter parameters or touch funds, distributing the braking power across more addresses adds no risk. Oversight is thereby separated from execution: even if the curator itself fails, vaults and markets retain a final line of defense.

## Market Isolation and Independent Accounting

Each market–vault pair keeps independent books and accrues interest independently. The failure of a single market is confined to each vault's exposure to that market, with losses calculable in proportion to allocation. The curator's diversification and the protocol's structural isolation form two complementary layers of risk control.

## Multi-Party Verification of Data

Every number produced off-chain — asset prices, NAV, execution results — must pass independent multi-party verification before it can change any user balance; no single role has the final word:

* The **curator** reviews the credibility of data sources before an asset is admitted: whether the issuer's NAV-reporting mechanism is sound, and whether the token is backed by real assets.
* The **executor** verifies the asset tokens and the counterparty in every swap; the amounts it reports are the first point of entry for the data.
* The **team signers** apply EIP-712 signatures to every settlement, NAV report, and price update — without their signatures, no number is accepted by the protocol.
* **Oracle** price updates must carry strictly increasing round numbers, precluding the replay of stale prices; reads enforce a heartbeat freshness check, and expired prices are refused outright rather than returned silently.

## Hard Caps on Fees and Rates

The protocol enforces hard ceilings on fees and rates, compiled into the contract bytecode: management fees may not exceed 5% per annum, performance fees may not exceed 50%. Once compiled, these ceilings become an immutable part of the protocol that no governance action can breach — a constraint enforced by the code itself, not by any policy promise.