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

# Risk framework

Each material hazard on Canopic, the party it falls on, and the mechanisms that cap its impact.

Putting real-world assets on a blockchain does not leave their real-world dangers behind. We think the right response is to list those dangers openly, name the people they affect, and document the mechanisms that contain them. That is the purpose of this section. If you notice a hazard that belongs on this list but is missing, tell us: we treat a gap here the same way we treat a defect in the docs.

## The hazard table

| Risk                            | Borne by                                     | Mitigations                                                                                    | Details                                                                    |
| ------------------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| Oracle failure or manipulation  | LPs and traders                              | Halts, the band, staleness limits, cross-checks and further guards                             | [Oracle safeguards](/risk/oracle-safeguards.md)                            |
| Weekend and overnight gaps      | LPs                                          | Reduced clips and higher spread multipliers while the home market is closed                    | [Market hours and pricing modes](/how-trading-works/market-hours.md)       |
| Issuer credit and freeze powers | Every Stock Token holder                     | Bytecode review, disclosure, tiered caps, and one published single-issuer exposure figure      | [Issuer exposure](/risk/issuer-exposure.md)                                |
| Sequencer outage or censorship  | LPs, and traders with transactions in flight | Halts, a post-recovery grace window, and forced inclusion through L1                           | [Chain outages and sequencer faults](/risk/chain-incidents.md)             |
| Smart contract defects          | Everyone                                     | Audits, invariants, a bounty, guarded caps and as little upgradeability as possible            | [Security program](/architecture/security.md)                              |
| Adverse or toxic flow           | LPs                                          | Skew-sensitive pricing, clips, inventory bands and one-sided quoting                           | [Market vaults](/how-trading-works/market-vaults.md)                       |
| Depeg of the quote asset        | Everyone                                     | A chain-native issuer under MiCA regulation, plus disclosed concentration                      | [Settling in USDG](/assets/usdg.md)                                        |
| Misconfigured parameter         | LPs and traders                              | The timelock, guarded caps, a written rationale for every change, and the band as a final stop | [Changing protocol settings](/transparency/settings-changes.md)            |
| Maker misconduct                | Takers                                       | Expiry, nonces, signature checks, revocable attestations and the band                          | [Large orders and signed maker quotes](/how-trading-works/large-orders.md) |
| Regulatory change               | Canopic as a venue                           | Jurisdiction-based access, enforced at a boundary that one parameter can narrow                | [Regulatory stance](/compliance/regulatory-stance.md)                      |

## Why the band catches almost everything

Follow the failure paths in the table and nearly all of them end at one control, the oracle band. A bad parameter, a stolen maker key or a quote sent to the wrong place each begin earlier in the pipeline. None of them, though, can yield a fill more distant from the last guarded oracle price than the band allows. What would otherwise be an open-ended list of scenarios reduces to a capped cost per fill. The guarded launch caps rely on that cap: it turns the worst case into a figure you can compute beforehand, not one you simply trust to be modest.

## Risks Canopic leaves with you

Any honest framework also has to spell out what remains:

* **Market movement in your position.** If you hold tokenized NVDA, you carry NVDA's price risk. Canopic sets prices for trades. It does not insure holdings.
* **Issuer insolvency.** Disclosure and caps keep this exposure visible and bounded in size. Neither removes it.
* **An accurate oracle during a turbulent market.** Stale data, pauses and implausibly large jumps trigger halts. Real volatility does not. When the underlying drops hard, Canopic reflects that drop exactly as the primary listing does.

## How the table stays up to date

Any incident affecting a row in the table leads to a published post-mortem. If the findings justify it, a design or parameter change then goes through the timelock. We also track incidents at other venues and record Canopic's response to each in [Lessons from earlier tokenized venues](/risk/lessons.md), and we expect our own record to be judged by the same standard.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.usecanopic.com/risk/framework.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
