> 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/backing-reserves-and-transparency/security/smart-contract-protections.md).

# Smart Contract Protections

Axis contracts use several controls to constrain invalid orders, replay, reentrancy, excessive issuance, and vault share manipulation. Each control covers a specific failure mode; none guarantees the value or availability of offchain assets.

## Capacity limits

The primary market (`USDxMarket`) meters throughput with configurable capacity caps (`CapConfig`) rather than a single fixed per-block ceiling. Each cap applies to one of five scopes (`CapScope`: global, per-asset, per-route, per-account, or per-channel), sets a notional ceiling in USDx wei, and carries a window basis (`WindowType`: none, per-`block.number`, or fixed timestamp buckets). Mint capacity meters USDx output; redeem capacity meters USDx input. `SETTLEMENT_MANAGER_ROLE` configures the caps, and a failed settlement consumes neither the nonce nor the capacity.

These limits bound operator throughput per scope and window, but they do not verify collateral prices or guarantee redemption liquidity.

## Order authorization

Mint and redemption orders use EIP-712 typed data. The domain is bound to the market contract (name `USDxMarket`) and the chain ID, while the order includes its account, route, channel, side, signer, assets and amounts, receiver, deadline, nonce, and accepted-terms hash.

A per-account nonce bitmap, keyed by `accountId`, not by signer address, makes each accepted nonce single-use without requiring sequential values, and a nonce is consumed only on successful settlement. Beyond a direct EOA signer, an order may be authorized by an ERC-1271 smart account or by a two-step delegated signer (`DelegatedSigner` on `USDxMarket`): a proposed delegate must confirm (`setDelegatedSigner`, then `confirmDelegatedSigner`) before it can sign orders for a source account.

## External-call protection

Neither `USDxMarket` nor the rewards vault (`StakedUSDx`) uses a `ReentrancyGuard`; there is no `nonReentrant` modifier on settlement, collateral movement, deposit, redemption-request, servicing, claim, or reward-funding paths. Instead these paths rely on checks-effects-interactions ordering, and settlement additionally uses the per-order `settled` flag on the stored `OrderRecord` as a double-settle guard so a completed order cannot be settled again.

Where these paths make external ERC-20 transfer calls, they use `SafeERC20`. These controls address non-standard ERC-20 return behavior and repeated settlement; they do not establish that a supported token, integration, or custodian is economically safe.

## Vault share protection

The rewards vault (`StakedUSDx`) follows the OpenZeppelin ERC-4626 pattern with virtual shares and assets. It computes share value from `accountedAssets` (active principal plus already-vested rewards) rather than the raw asset balance, so a direct USDx donation raises the vault's balance but not the exchange rate. There is no minimum-share or dust-balance floor; the only related check, `MinSharesViolation`, is an ordinary insufficient-balance guard in `requestRedeem` that reverts when an owner requests to redeem more shares than they hold.

Together the `accountedAssets` pricing and the OpenZeppelin virtual offset mitigate donation-style share inflation. They do not prevent USDx price changes, strategy losses, or redemption delays.

## Review the guarantees precisely

Read [Onchain Safety Properties](/backing-reserves-and-transparency/security/onchain-safety-properties.md) for the properties these mechanisms are intended to preserve. [Protocol Administration](/technical-and-architecture/governance.md) explains who can change caps, roles, assets, custodians, and cooldown parameters. [Audit Reports](/backing-reserves-and-transparency/audits.md) records the reviewed revisions and reported findings.


---

# 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/backing-reserves-and-transparency/security/smart-contract-protections.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.