> 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.md). # Security Overview Axis combines onchain contracts with privileged accounts, external custody, operators, venues, and offchain strategy execution. Contract controls can constrain specific actions, but they cannot guarantee collateral value, custody access, trading results, liquidity, or regulatory availability. {% hint style="warning" %} Security is a system property, not an audit label. Review the onchain controls together with the offchain risks and the exact scope of each audit. {% endhint %} ## Trust assumptions Axis is designed to minimize trust wherever it can, but it does not eliminate it. Real trust assumptions remain today, most importantly, the **centralized liquidity** the protocol needs to trade at scale, which requires assets to sit on external venues. Axis treats these as assumptions to be **reduced gradually over time**, not as permanent guarantees. For a holder of USDx, the practical trust assumptions are: * **Venue solvency.** The exchanges and custodians holding the backing remain solvent and honor withdrawals. * **Order-execution systems.** The offchain trading and settlement systems submit, price, and settle orders correctly. * **Entering and exiting positions.** The protocol can put on and unwind its actively-managed trading positions when needed, including to service redemptions. * **Risk management.** The protocol's risk controls hold across market conditions. These are the trust assumptions behind the offchain, actively-managed trading operations that generate the backing's returns; the onchain contracts constrain what privileged accounts can do, but they cannot guarantee any of the above. See [Onchain Safety Properties](/backing-reserves-and-transparency/security/onchain-safety-properties.md) for the onchain half of the model and the risk pages below for the offchain exposures. ## What the contracts protect The contracts validate signed orders, consume nonces once, enforce order expiry and configured capacity caps (`CapConfig` over a chosen `CapScope` and `WindowType`), separate operational roles, and provide a one-way emergency halt role. The rewards vault (`StakedUSDx`) applies share-accounting rules, vests delivered rewards linearly over a configured window. The live value is a configured parameter, not a fixed constant, and services redemptions through an asynchronous (ERC-7540) flow: `requestRedeem` opens a request subject to a configured cooldown, `serviceRedemptions` marks it claimable, and the controller then claims the underlying USDx. Read [Smart Contract Protections](/backing-reserves-and-transparency/security/smart-contract-protections.md) for how those mechanisms work and [Onchain Safety Properties](/backing-reserves-and-transparency/security/onchain-safety-properties.md) for the intended invariants. ## Privileged powers The root admin (`DEFAULT_ADMIN_ROLE`) is held by the **governance Safe (multisig)**, a geographically-distributed **3-of-5** signer set inside and outside the Axis Labs team, which acts seldom. **Contract upgrades are governed by a separate `TimelockController`**: an upgrade must pass a timelock delay before it can execute (the delay is set on the `TimelockController` and is verifiable onchain). The governance Safe is not itself behind the timelock, its non-upgrade admin actions are direct, while proxy upgrades are delayed by the timelock. Administrators can materially change supported deposit/input assets, custody destinations, capacity caps, roles, address restrictions, reward configuration, and cooldown timing. Role separation narrows individual operator permissions, and the guardian roles act one-way (risk-down): * The **Emergency** role, the V2 successor to the V1 "Gatekeeper", can pause the market, disable mint/redeem, and remove hot market roles, but cannot increase risk or upgrade. * **Compliance** is a separate role that can freeze, never seize, addresses. None of these protects against every compromise or misuse by the current authority. [Protocol Administration](/technical-and-architecture/governance.md) lists the powers and emergency role. [Access Control](/reference/access-control.md) provides the complete technical permission matrix, including the privileged-function-to-authority table. ## Trust boundaries outside the contracts The primary market (`USDxMarket`) does not use an external price oracle to determine the economic fairness of an order. Offchain pricing and operations therefore remain trust dependencies. Collateral routed to external custodians also depends on asset value, key management, legal access, and operational availability. Where does the yield come from? The offchain strategy's structural edge is cross-venue and cross-asset fragmentation, a durable, market-neutral yield source that does not rely on any single mechanism. Funding is one component (and can be the larger share in a given period); see the Transparency Dashboard for current attribution. Those returns depend on trading execution, hedging, and settlement that the contracts cannot guarantee. These dependencies can combine with venue, hedge, settlement, and liquidity failures. Review: * [Market & Trading Risk](/risk/market-trading-risk.md) for basis, execution, funding, and data failures; * [Venue & Counterparty Risk](/risk/venue-counterparty-risk.md) for venue assessment and concentration controls; * [Custody & Liquidity Risk](/risk/custody-liquidity-risk.md) for backing availability, redemption, and withdrawal timing; * [Risk Overview](/risk/risk-overview.md) for the complete exposure map. ## Custody and counterparty controls Several offchain trust dependencies are managed by operational controls rather than by contract code: * **Venue and counterparty selection.** Axis trades only on established, reputable venues, draws on long-standing client relationships with them, and applies **counterparty scoring** to assess and monitor exposure. * **Account whitelisting.** All protocol accounts pass **rigorous, regimented whitelisting policies** before use, constraining where assets are permitted to move. * **On-venue by necessity.** The strategy requires liquidity positioned on the venues and inventory rebalanced across them multiple times per day, so the backing is held on-venue. Axis does **not** currently use off-exchange settlement or off-exchange custody. * **Independent verification.** Axis works with **Accountable**, which has **read-only access to the exchange accounts** and can independently **attest the reserves and the accounting methodology**, so the existence and control of positions can be checked by a third party. These controls reduce, but do not eliminate, the offchain dependencies above. See [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency.md) for the full treatment and [Venue & Counterparty Risk](/risk/venue-counterparty-risk.md) for the residual exposure. ## Access, key management, and operational security Alongside the onchain controls, Axis applies operational measures to constrain who can move value and how orders reach the chain. These are design measures, not guarantees; each reduces a specific failure mode without eliminating it. **Access and destination allowlisting** * Only **whitelisted users** can mint or redeem on the primary market. * The market restricts settlement to **whitelisted destination addresses**, collateral can only move to pre-approved custodian channels, not arbitrary recipients. * Only **dollar-denominated (or similarly dollar-pegged) deposit/input assets** are accepted initially. (These are deposit/input assets, not collateral in the traditional sense.) **Key management** * Signing keys are held **air-gapped** and under **multiple parties**, no single person can unilaterally move funds. * Key material is managed with **AWS KMS**. * Multisig signer keys are held in **cold storage** on **hardware wallets**. **Order and role controls** * **Address-validity checks** and **strict order-submission** validation guard what can be submitted and where value can go. * **Robust role management** separates execution from configuration, so a hot operator key cannot reconfigure the system (see [Access Control](/reference/access-control.md)). * A **last-look architecture** on order handling improves pricing and gas estimation and guards against adverse selection before an order is committed. {% hint style="info" %} Axis does **not** currently use internal pricing to determine order economics, order pricing comes from the offchain quoting flow, not an internal price feed. This may change in future; it is not in use today. {% endhint %} ## Code lineage and audits Axis originated from the upstream [Ethena contracts](https://github.com/ethena-labs/bbp-public-assets) at commit `f3e56d5`, then changed dependencies and added Axis-specific code. Relevant V2 changes include the OpenZeppelin migration, Solidity 0.8.30, the vault's own linear reward funding (`fundRewards`, gated by `REWARD_MANAGER_ROLE`), and share-price accounting via `exchangeRate()` rather than a separate rate-provider contract. Upstream audit lineage is not a substitute for Axis-specific review. OpenZeppelin reviewed the V2 contracts. Audits are time-bounded reviews, not warranties. Deployment-level assurance requires matching each reviewed revision to deployed bytecode. Read [Audit Reports](/backing-reserves-and-transparency/audits.md) for the reviewed revisions, reported finding counts, and the reports themselves. --- # 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.md?ask=&goal= ``` `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.