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 for the properties these mechanisms are intended to preserve. Protocol Administration explains who can change caps, roles, assets, custodians, and cooldown parameters. Audit Reports records the reviewed revisions and reported findings.