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

# How Axis Manages Risk

Risk management in Axis is layered, and the layers are not equally strong. The first four sections below are controls the smart contracts enforce, so they hold whatever anyone intends. The sections after them depend on offchain operations and judgement, which is where most of the residual risk sits. The existence of a control is not proof that every loss will be prevented.

## Onchain issuance controls

New USDx is issued only through the primary market (`USDxMarket`), which settles signed orders. Before an order settles, `checkSettlement` / `settle` verify:

* EIP-712 signatures validated against the order's `signer` / `accountId`, via a direct EOA match, an accepted `DelegatedSigner`, or ERC-1271 smart-account validation;
* single-use nonces (namespaced per account) and order expiry;
* the mint or redeem operator authority executing the order (`MINT_OPERATOR_ROLE` / `REDEEM_OPERATOR_ROLE`);
* an enabled route (asset pair and side) and an approved settlement channel (custody path);
* per-scope capacity limits across the global, asset, route, account, and channel dimensions.

These checks constrain who can execute orders and whether an order matches configured routes, channels, and capacity. They do not verify the market value of the order through an external price oracle.

## Role separation and emergency controls

Supply authority, order execution, collateral settlement, reward funding, restrictions, and administration use separate roles. Mint authority on the token is a single role (`MARKET_ROLE`) held by the `USDxMarket` contract, so all issuance flows through approved orders; operators (`MINT_OPERATOR_ROLE` / `REDEEM_OPERATOR_ROLE`) can only execute orders, not change what supply means. An emergency holder (`EMERGENCY_ROLE`, with token/vault `PAUSER_ROLE`) can pause capacity, disable mint and redeem, and remove hot roles, but this is risk-**down** authority only: it cannot grant roles, raise limits, or upgrade contracts.

Role separation can limit the scope of a compromised operational key. Risk-**up** changes, raising capacity, adding routes, custodians, or assets, or granting roles, require a deliberate action by the **governance Safe (multisig)** that holds `DEFAULT_ADMIN_ROLE` (never a hot EOA). **Contract upgrades are governed separately by a `TimelockController`**, the owner of each `ProxyAdmin`, so upgrading an implementation additionally passes through a timelock delay before it can execute (the delay is set on the `TimelockController` and is verifiable onchain); the governance Safe itself is not behind the timelock. Administrative keys still carry material power over supported assets, custodians, limits, roles, and vault parameters.

## Staking-vault controls

The rewards vault (`StakedUSDx`):

* accounts for sUSDx shares under ERC-4626 rules, against `accountedAssets` (principal plus vested rewards);
* vests delivered rewards linearly over a configured window instead of recognizing them all at once;
* supports a configurable withdrawal cooldown between a redemption request and when it becomes serviceable;
* redeems asynchronously (modeled on ERC-7540): you `requestRedeem` shares (which burns them). An account holding `REDEMPTION_SERVICER_ROLE` runs `serviceRedemptions` to make eligible requests claimable, and you then claim the underlying USDx; a still-pending request can be cancelled to restore the burned shares;
* carves cooldown and redemption assets out of `accountedAssets` into in-vault `pendingRedeemAssets` and `claimableRedeemAssets` liability buckets. There is no separate silo contract, and reserved redemptions earn no further rewards and cannot dilute active holders;
* funds rewards through `fundRewards` (gated by `REWARD_MANAGER_ROLE`), which folds a top-up into the active vesting window rather than resetting it;
* restricts privileged functions through roles.

These controls address vault accounting and withdrawal mechanics. They do not make strategy returns certain or protect the US-dollar value of USDx. Yield reaches the vault only when realized results, generated offchain, with Axis's structural edge in cross-venue and cross-asset fragmentation, are delivered as USDx rewards; a period with no new rewards produces no yield by itself.

## Smart contract review

Axis publishes independent audit reports. An audit is a time-bounded review of a defined code scope, not a warranty that the system has no vulnerabilities. Readers should review the reviewers, revisions, scope, and findings directly in the reports linked from [Audit Reports](/backing-reserves-and-transparency/audits.md), which is the authoritative source for which contracts and revisions were covered.

## Asset and venue frameworks

Axis's offchain risk framework calls for fail-closed asset gates, a tiered venue-eligibility and concentration model, continuous venue monitoring, and staged de-risking. Thresholds and response parameters can change with market and operational conditions.

These processes remain dependent on data quality, timely decisions, operational access, and the ability to execute. See [Asset Selection Framework](/risk/asset-selection.md), [Venue & Counterparty Risk](/risk/venue-counterparty-risk.md), and [Market & Trading Risk](/risk/market-trading-risk.md).

## Over-collateralization and loss absorption

Axis does not operate a reserve fund. Instead, the backing is designed to be **over-collateralized** against a target over-collateralization level, the backing portfolio is intended to exceed outstanding USDx. By design, drawdowns, negative reserve growth, and reserve contractions are intended to be absorbed by this over-collateralization buffer rather than passed straight through to USDx or sUSDx holders.

This is a design intent, sized against reserves, not a named guarantee fund and not a promise. A large enough or fast enough loss can exceed the buffer, and live collateralization is established only by the reserve metrics and Proof of Reserves reporting, not by this description. See [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency.md) for what can and cannot be independently verified.

## Offchain risk remains

Smart contracts cannot fully control:

* exchange or custodian solvency and availability;
* execution quality, slippage, partial fills, or settlement;
* the future relationship between hedged assets;
* the accuracy and timeliness of operational decisions;
* legal or regulatory intervention.

For that reason, risk assessment should cover the complete asset and information flow, not only the deployed contracts.

## What users can verify

Users can inspect deployed addresses, contract code, roles, configured capacity limits, redemption-request state, events, and vault accounting. Offchain positions, custody arrangements, and strategy performance require separate offchain evidence and cannot be inferred from the token contracts alone.

See [Contract Addresses](/reference/contract-addresses.md), [Access Control](/reference/access-control.md), and the [Risk Overview](/risk/risk-overview.md).


---

# 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.axis.to/risk/risk-management.md?ask=<question>&goal=<endgoal>
```

`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.