# 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 This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.axis.to/index.md?ask=&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. --- # Welcome to Axis Axis builds the infrastructure behind digital asset markets: liquidity, settlement, and credit for the institutions moving capital through them. Axis provisions liquidity, makes markets, and manages risk across venues, currencies, and settlement systems. Two products are live today, and they are deliberately different things: * **USDx.** The Axis Dollar, is a dollar with real utility: a dollar-denominated, over-collateralized token that finances positions and settles trades between Axis counterparties. You **mint** it against supported assets. * **sUSDx.** The Axis Rewards Vault, is a separate product, and it is the yield-bearing one: a tokenized vault position, permissionlessly created when you stake USDx. It is where deposits that would otherwise sit idle earn a return. The rate is variable. {% hint style="warning" %} **Read this first. USDx is not a stablecoin.** USDx is a **synthetic dollar**. It is backed by **digital and tokenized assets first**, plus traditional assets, plus the **corresponding futures and hedge positions** that keep the book market-neutral. That backing is **actively-managed trading inventory**, and holding it is **risky**: USDx can trade above or below its target price, its value depends on live trading, custody, and counterparty conditions, and sUSDx withdrawals may be subject to a cooldown. USDx and sUSDx involve market, liquidity, custody, counterparty, smart contract, operational, and regulatory risks. Start with the [Risk Overview](/risk/risk-overview). {% endhint %} ## Start here | If you want to... | Read... | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Understand what Axis is, in plain language | [What is Axis?](/start-here/what-is-axis) | | Learn where Axis came from | [Origin](/start-here/origin) | | See how assets, USDx, strategies, and sUSDx connect | [How Axis Works](/start-here/how-axis-works) | | Understand the USDx price-stability mechanism | [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability) | | Review backing, custody, and transparency | [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency) | | Understand where sUSDx yield comes from | [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield) | | Evaluate what can go wrong | [Risk Overview](/risk/risk-overview) | | Review the contracts | [System Architecture](/technical-and-architecture/architecture) | ## The system at a glance The mint-and-redeem system and the trading engine are related but distinct. Smart contracts enforce the USDx mint, redemption, staking, reward-distribution, and access-control rules. The trading and custody that stand behind the backing are directed offchain and introduce dependencies that smart contracts cannot eliminate. ## Core concepts ### USDx USDx, the Axis Dollar, is Axis's synthetic dollar: a dollar-denominated, over-collateralized token. It is **minted** against supported assets through signed orders submitted by an authorized operator, and a corresponding redemption flow burns USDx and returns the assets specified in the order. Read [What is USDx?](/usdx-the-synthetic-dollar/usdx). ### sUSDx sUSDx is the Axis Rewards Vault, a yield-bearing, tokenized vault position that is permissionlessly created when you stake USDx. When rewards are added and vest, each sUSDx position can become redeemable for more USDx. Read [What is sUSDx?](/susdx-the-rewards-vault/susdx). ### The trading engine Behind the tokens is a market-neutral trading engine spanning four complementary categories: cross-venue arbitrage, cross-currency arbitrage, funding rate arbitrage, and OTC/RFQ. The engine provisions liquidity where markets need it most, and the active mix can change as opportunities and risk conditions change. None of these return sources is risk-free: execution, liquidity, basis, FX, funding, venue, custody, counterparty, and operational failures can reduce or reverse an expected return. Read [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield). The trading and risk infrastructure behind this engine **predates Axis**. It was built and run for years before Axis existed, and has been battle-tested through multiple market cycles and edge cases. See [Origin](/start-here/origin). ## Important distinction The sUSDx exchange rate measures **USDx per sUSDx**. It is not the market price of USDx in US dollars, and it is not a guarantee that either token can be sold or redeemed at a particular price or time. ## Where Axis fits Axis is not about capturing every available source of dollar returns. It is about **positioning capital and liquidity where they need to go to meet demand**, creating liquid markets across asset classes and asset standards, and **bridging digital and traditional assets**. ## Community & links * [Website](https://axis.to) · [X](https://x.com/AxisFDN) · [Telegram](https://t.me/AxisFDN) · [LinkedIn](https://www.linkedin.com/company/axis-career/) * Quick links: [FAQ](/resources-and-legal/faq) · [How to buy (mint)](/usdx-the-synthetic-dollar/mint-and-redeem) # What is Axis? {% hint style="info" %} **V2 · Ethereum · live.** This page describes the audited (OpenZeppelin) V2 contracts, deployed on Ethereum mainnet; USDx and its rewards vault are live on Ethereum, and contract addresses are on the [Contract Addresses](/reference/contract-addresses) page. The V1 private beta on Plasma is covered under Legacy. {% endhint %} Axis builds the infrastructure behind digital asset markets: liquidity, settlement, and credit for the institutions moving capital through them. Axis provisions liquidity, makes markets, and manages risk across venues, currencies, and settlement systems. Institutions hold credit lines and settlement relationships with Axis, so a trade does not have to wait for every position to be pre-funded. USDx is the first product built on that infrastructure, and the only one live today. USDx is a dollar with real utility: an asset that finances positions and settles trades between Axis counterparties. sUSDx is a separate product, and it is where deposits that would otherwise sit idle earn a return. ## Why Axis Axis is built around a simple thesis: markets are fragmented, and capital that can move to where liquidity is scarce, and price the risk of doing so, can earn a return. Four ideas define the business. 1. **Global liquidity provision and market making.** Axis exists to make markets more efficient, supplying depth and two-sided prices wherever there is demand for liquidity, across venues, currencies, and settlement systems. 2. **Resilience across market cycles, and the ability to capture volatility.** A market-neutral book is built to hold up whether markets are rising, falling, or sideways. Just as important, Axis is positioned to *capture* volatility rather than be hurt by it: dislocation, stress, and repricing are when fragmentation is widest and opportunities are richest. That long-volatility, long-optionality posture is a distinctive source of capital efficiency for the wider industry. 3. **Trading-execution and risk-management infrastructure.** Underneath the products sits the machinery of a professional trading desk, execution across many venues, hedging, and continuous risk management that keeps the book within defined limits and prices counterparty, venue, and custody exposure. 4. **Capital efficiency.** Every unit of USDx is backed by assets held by the protocol, and the design keeps that backing deployed rather than idle, so the book can scale without hard collateral constraints. Realized returns can be directed into rewards, including incentive programs featuring sUSDx. Rewards are a consequence of the business, not its starting point, and the reward rate is variable. ## What Axis does Axis runs a market-neutral trading operation and packages access to it as onchain products. Day to day, that means: * **Trading.** Capturing price dislocations of the same or related exposure while hedging out market direction. * **Liquidity provisioning.** Supplying depth to venues and pairs that are underserved. * **Market making.** Quoting two-sided prices and earning the spread. * **Managing risk.** Keeping the book delta-neutral and within defined limits, and pricing counterparty, venue, and custody exposure. Market-neutral arbitrage, capturing price differences while hedging out market direction, is an established institutional trading strategy, not a crypto invention. Axis's structural edge is cross-venue and cross-asset fragmentation: a durable, market-neutral return source that does not rely on any single mechanism. ## Where the return comes from Axis earns its return from structural fragmentation across venues, currencies, and settlement systems. That edge is expressed through four complementary trading categories: * cross-venue arbitrage * cross-currency arbitrage * funding rate arbitrage * OTC/RFQ Funding is one component (and can be the larger share in a given period); see the Transparency Dashboard for current attribution. The active mix can change as opportunities and risk conditions change. ## USDx as the first product USDx connects a synthetic dollar to that trading engine. USDx, the **Axis Dollar**, is a **dollar-denominated, over-collateralized synthetic dollar**, **not** a stablecoin. It is backed by **digital and tokenized assets first**, plus traditional assets, plus the **corresponding futures and hedge positions** that keep the backing market-neutral. That backing is **actively-managed trading inventory**, so holding USDx carries real risk. The protocol separates three functions that are easy to confuse: 1. **Mint and redemption.** Supported assets enter through a signed mint order, and USDx is **minted**. A signed redemption order burns USDx and returns the assets specified in that order. 2. **Trading.** Axis runs the market-neutral trading described above. It takes place outside the rewards vault, and it introduces market, custody, counterparty, and operational dependencies. 3. **Reward distribution.** Realized returns can be funded into the rewards vault. As rewards vest, the amount of USDx represented by each sUSDx position increases. ## The two tokens | Token | What it is | Does it earn staking rewards? | | --------- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | **USDx** | The Axis Dollar, a dollar-denominated, over-collateralized synthetic dollar | No, not by simply holding it | | **sUSDx** | The Axis Rewards Vault, a yield-bearing, tokenized vault position, permissionlessly created when you stake USDx | It accrues distributed rewards through its exchange rate | Holding sUSDx does not create a fixed interest payment. Returns depend on rewards actually delivered to the vault, and those rewards depend on trading results and operations. ## What Axis is not * USDx is **not a stablecoin**, it is a synthetic dollar backed by actively-managed trading inventory. * USDx is not a bank deposit. * sUSDx does not promise a fixed APY. * The sUSDx exchange rate is not the USDx market price. * A mint-and-redeem mechanism does not guarantee that USDx will always trade at exactly $1. * Market-neutral arbitrage is not risk-free. ## Why the system has two tokens Separating USDx from sUSDx lets users choose between holding the Axis Dollar and accepting the additional staking-vault mechanics needed to receive distributed trading returns. It also makes the accounting explicit: rewards accrue to vault positions rather than changing every USDx balance. ## Where to go next * [Origin](/start-here/origin) covers where Axis came from and why it is built this way. * [How Axis Works](/start-here/how-axis-works) follows the complete lifecycle. * [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability) explains the price-stability pathway and its limits. * [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield) separates trading returns from vault accounting. * [Risk Overview](/risk/risk-overview) explains the principal risks. # Origin Axis started in 2025. The people and the trading discipline behind it go back much further, to the earliest days of crypto market structure. ## Making markets when few others would Axis co-founder and CEO Chris Kim was the first employee at QCP Capital, where he ran the firm's most active book. At the time only a handful of desks anywhere were willing to quote non-dollar stablecoins, and his was one of them. That market looked nothing like today's. It was small, but the inefficiencies were large. Emerging market structure, cross-border barriers, and thin connectivity between regions held open real price gaps on the same asset. The work was cross-asset arbitrage: price a local or regional market against the global price for Bitcoin, other digital assets, and currencies, then trade the difference. Some of those gaps came from a promise rather than from the market. One trade ran across three legs: buy a stablecoin at a fixed 1:1 against dollars from a payments company that guaranteed that rate to its users, sell it for another stablecoin on an exchange, then convert back to dollars. The first leg did not move when the market did. Finding trades like that is the job. ## From arbitrage to a quantitative fund Chris took that experience to a proprietary quantitative trading firm, where the cross-border discipline was joined to cross-venue arbitrage, low-latency execution, and a market-microstructure edge. That operation grew into a hedge fund with outside investors, run on the same market-neutral discipline Axis uses today. ## From a fund to a protocol In 2025 the team came together, redeemed its LPs, and set out to build something larger. The trading and risk infrastructure Axis runs on was not built for Axis. It predated Axis, tested through several market cycles, and the moment to point it at a bigger opportunity had arrived. ## Why now Four things converged that had not been true in earlier cycles: * **Institutional participation became real.** After several cycles of promise, serious institutions started moving capital through digital asset markets. * **Real assets began intersecting crypto.** Not only Treasuries onchain, but tokenized gold, commodities, equities, and non-dollar stablecoins: a widening set of real-world exposures moving onto public infrastructure. * **Tokenization became durable.** Blockchain-based issuance and settlement became established enough to be treated as a lasting asset standard rather than an experiment. * **Synthetic dollars and yield tokens found adoption.** They were taken up across DeFi as a settlement and savings layer. Together these point at the opportunity Axis is built for: capital markets forming around a new asset class, with global institutional participation, and a team whose trading edge is built to supply liquidity where those markets need it most. ## Why it is built this way Axis trades, provisions liquidity, makes markets, and manages risk. That is what the team has always done. USDx and sUSDx are the onchain expression of that operation, a way to package institutional-grade, market-neutral trading into products anyone can hold. They are not a pivot into a different business. ## Where to go next * [What is Axis?](/start-here/what-is-axis): the fuller identity and the two tokens. * [How Axis Works](/start-here/how-axis-works): the end-to-end lifecycle. * [Risk Overview](/risk/risk-overview): the principal risks of holding USDx and sUSDx. # Size of the Opportunity The most consequential shift in financial markets is already underway: the assets themselves are moving onchain. What began with dollars, stablecoins and synthetic dollars, is now reaching Treasuries, money-market funds, gold and commodities, equities, and credit. The direction is set by the largest allocators in the world. BlackRock's Larry Fink put it plainly in his 2025 Chairman's Letter to Investors: > Every stock, every bond, every fund, every asset, can be tokenized. If they are, it will revolutionize investing. Tokenization is not a niche within crypto. It is the migration of the entire financial system onto crypto-native rails. As that migration runs its course, the venues catch up to the assets. Tokenized and traditional assets alike come to trade across **centralized exchanges and decentralized exchanges**, a single, programmable market structure spanning both. The distinction between "the crypto market" and "the traditional market" thins out, and what remains is one emerging layer of onchain market infrastructure and shared asset standards on which everything trades. ## The scale The numbers attached to this transition are among the largest in finance. Estimates vary widely by definition, from roughly **$2 trillion by 2030** (McKinsey, excluding stablecoins) to **$16 trillion by 2030** (Boston Consulting Group) and as much as **$30 trillion by 2034** (Standard Chartered, including bonds, commodities, and trade finance), but even the most conservative scenarios describe a market structure being rebuilt from the ground up. The precise figure matters less than its shape. A market of this size is not a single product or a single venue, it is thousands of assets, issued and traded across many chains, venues, currencies, and jurisdictions, all at once. Building it out is not a question of demand. Demand, global supply of tokenized assets on one side, global investor appetite on the other, is not in doubt. The open question is more fundamental. ## A two-sided gap Put the two sides together and a gap appears in the middle. On one side: an enormous and growing **supply of tokenized assets**, and a global base of **investors who want to hold and trade them.** On the other: the plumbing that would let that supply and that demand actually meet, deep, continuous, two-sided liquidity, is **fragmented.** The reason is structural. The world's most global assets, Bitcoin, digital assets, gold and commodities, have **global supply and global demand.** They are moved and traded across borders; investors everywhere need to get in and out. Yet the markets for them **evolved independently.** Different regions built their own venues, their own participants, their own market conventions, their own local and regional currencies, and their own jurisdictional rules. Liquidity pooled locally rather than globally. ![Order books for the same asset on three venues at the same moment. Buying the best ask on one regional venue at $59,975 and selling the best bid on another at $60,120 is $145 apart, because liquidity pooled locally rather than globally.](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-7bed9fadc7c2e74206fff5baefc645b4a6061612%2Ffragmented-liquidity.svg?alt=media) The result is that a genuinely global asset trades in a patchwork of **only-local liquidity.** The same or economically related exposure sits at different prices across venues, instruments, currencies, and settlement systems, not because the asset differs, but because the markets never joined up. As traditional assets tokenize and established players push more of the financial system onchain, that patchwork does not automatically resolve. It multiplies. ## How are these markets going to be made? This is the question the tokenization thesis usually skips. A tokenized asset is not a market. An order book with nothing on both sides is not a market. For every new asset standard and every new venue that comes onchain, someone has to **provide the liquidity**, quote both sides, absorb imbalances, connect the fragmented pools, and price the risk of doing so, so that a real market exists at all. That is the need Axis is built to meet. Axis's purpose is to **position capital and liquidity where they need to go to meet demand**, provisioning liquidity, making markets, and managing risk wherever the markets are thinnest, and in doing so bridging digital and traditional assets across the venues where they trade. Where markets are fragmented, the work is to knit them together; where markets do not yet exist, the work is to make them. ## The opportunity If tokenization brings the world's assets onchain, the markets for those assets still have to be made, and made across the borders, currencies, and venues that keep them fragmented today. **Axis is built to be the liquidity layer for global, tokenized markets.** # How Axis Works Axis combines an offchain order and strategy system with onchain issuance and staking contracts. The end-to-end lifecycle below is how the V2 contracts are designed to behave once deployed. ## 1. Mint USDx USDx, the **Axis Dollar** (Axis's synthetic dollar), is created through the **USDx primary market** (`USDxMarket`), a single contract that settles both sides of issuance as signed orders. An **approved counterparty**, a whitelisted, eligible participant, submits an order on the USDx market whose side is `MINT` and which specifies the collateral and USDx amounts. When the order is filled, USDx is **minted at roughly 1:1** against the incoming collateral. An **operator** (holding `MINT_OPERATOR_ROLE`) submits the order onchain. The market validates the signature, expiry, nonce, supported collateral, custody route and channel, and current capacity before moving collateral to registered custody addresses and minting USDx. Interface, legal, and operational eligibility can impose additional conditions outside the contract. Once collateral leaves the contract it is **routed through the market's channels and lanes to a custodian account**, and from there **custody is transferred out to the exchanges and trading venues** that hold the backing portfolio. By design, Axis takes **no profit from minting or redeeming USDx**, mint and redeem settle against the collateral in the order rather than at a margin for Axis. Where that collateral is custodied and how the backing is evidenced is covered separately in [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). The amounts in the signed order define the transaction. The market does not use an external price oracle to calculate the mint quote. ## 2. Use or hold USDx USDx is transferable as an ERC-20 token. Secondary-market price depends on market supply, demand, liquidity, and confidence in the mint-and-redeem pathway. Read [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability). ## 3. Stake USDx for sUSDx Users can deposit USDx into the ERC-4626 rewards vault (`StakedUSDx`) and receive sUSDx. An sUSDx position is designed to represent a proportional claim on the vault's accounted assets. $$ \text{sUSDx value in USDx} = \frac{\text{vault total assets}}{\text{sUSDx total supply}} $$ ## 4. Generate and distribute rewards Axis's market-neutral trading engine covers cross-venue arbitrage, cross-currency arbitrage, funding rate arbitrage, and OTC/RFQ. The engine evaluates opportunities across these categories and allocates within its risk limits as market conditions change. Axis'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. When realized trading results are delivered to the vault as rewards, a reward manager (holding `REWARD_MANAGER_ROLE`) calls `fundRewards` to add them to the vault's linear vesting schedule. Vested rewards increase the vault assets represented by each sUSDx position. Yield is therefore neither created by the token contract nor guaranteed by staking. The vault can only distribute rewards it actually receives, and only as they vest. ## 5. Unstake or redeem Exiting sUSDx is an **ERC-7540 asynchronous redemption**, a request/claim lifecycle rather than an instant swap: 1. **Request.** The controller calls `requestRedeem`, which burns the owner's shares and moves the corresponding assets out of the vault's accounted assets into `pendingRedeemAssets`. The request snapshots its own terms, including an `eligibleAt` time derived from the cooldown parameter in force at request time. Cooldown is a property of the async request, not an optional add-on. 2. **Service.** A redemption servicer (holding `REDEMPTION_SERVICER_ROLE`) calls `serviceRedemptions`, which moves eligible pending requests to claimable, shifting their reserved assets from `pendingRedeemAssets` to `claimableRedeemAssets`. 3. **Claim.** Once claimable, the controller withdraws/claims the reserved USDx. Redeeming the underlying **USDx** is the redeem side of the same primary market: a holder signs an order whose side is `REDEEM`, and an operator (holding `REDEEM_OPERATOR_ROLE`) settles it, burning USDx and returning the collateral specified in the order. Mint and redeem are two sides (`OrderSide`) of one market, not separate contracts. ## Onchain and offchain responsibilities | Onchain contracts enforce | Offchain systems are needed for | | ---------------------------------------------------------------- | ---------------------------------------------- | | Signature, nonce, expiry, and role checks | Constructing and submitting mint/redeem orders | | Supported-asset and registered-custodian checks | Custody operations | | Route, channel, and capacity limits | Strategy execution and venue access | | USDx minting and burning | Determining order terms | | sUSDx accounting, reward vesting, and the async redemption queue | Delivering realized rewards to the vault | This boundary matters for risk analysis. Contract safeguards can constrain onchain actions, but they cannot remove custody, venue, execution, or operator risk. # USDx Quickstart Use this page to choose the right path before interacting with Axis. {% hint style="warning" %} Verify the current contract addresses and current protocol parameters before signing. A token symbol or address shared through an unofficial channel is not proof that a contract is part of Axis. {% endhint %} ## Choose what you want to do ### Hold USDx USDx is the synthetic-dollar token. Holding USDx alone does not earn the staking-vault yield. Before acquiring it, understand the [price-stability pathway](/usdx-the-synthetic-dollar/peg-stability) and [risk profile](/risk/risk-overview). ### Stake USDx Staking deposits USDx into the vault and returns sUSDx. As funded rewards vest into the vault's accounted assets, each sUSDx position becomes redeemable for more USDx and the exchange rate rises over time. Axis's structural edge is cross-venue and cross-asset fragmentation; funding is one component (and can be the larger share in a given period), with current attribution on the Transparency Dashboard. Yield is variable and is not guaranteed. Unstaking is not instant. It is an asynchronous redeem request (ERC-7540): you call `requestRedeem`, which burns your shares and reserves the corresponding assets. The request must first clear the cooldown, currently **7 days**, then be serviced by an operator (`serviceRedemptions`) before it becomes claimable; only then can you claim USDx. The cooldown is the eligibility delay on that request, not a simple setting on an otherwise instant unstake. For contract-level steps, see [Stake & Unstake USDx](/susdx-the-rewards-vault/stake-and-unstake). ### Mint or redeem USDx Minting and redemption use EIP-712 signed orders submitted by authorized operators to the USDxMarket. The order states the collateral and USDx amounts; it must pass signature, deadline, nonce, asset, route, authority, and capacity checks before it can settle. For the integration flow, see [Mint & Redeem USDx](/usdx-the-synthetic-dollar/mint-and-redeem). ## Before every transaction 1. Verify the address on [Contract Addresses](/reference/contract-addresses). 2. Read the wallet prompt, including token, amount, spender, and network. 3. If you may need near-term liquidity, plan for the sUSDx async exit: a redeem request must clear its 7-day cooldown and be serviced before USDx is claimable. 4. Do not infer a guaranteed dollar exit price from the sUSDx vault exchange rate. 5. Consider whether you can tolerate a delay, depeg, or loss. ## Understand your exit path | Position | Immediate next asset | Additional step for collateral | | -------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | sUSDx | Open an async redeem request (`requestRedeem`); once the 7-day cooldown elapses and an operator services the request, claim USDx | Submit a USDx redemption order | | USDx | USDx | Submit a USDx redemption order | Secondary-market trading may offer another path, but its price and available liquidity are external to the protocol contracts and are not guaranteed. # Origin Vault The pre-deposit phase of the Axis ecosystem vault, curated by the Axis core team and hosted via Upshift. {% hint style="info" %} **The Origin Vault pre-deposit is live.** Season 1 opened **July 29** and the deposit window closes **August 5**, or earlier if the cap fills. The parameters are: * **Season 1 start date.** July 29 * **Initial cap.** $100M * **Rewards.** \~10 Coordinates/day + Multiplier (2x for depositors in the first $50M, 1.75x for the second $50M) * **Lock-up.** 30-day hard lock * **Position token.** ogUSDx * **"Coordinates"** points branding {% endhint %} ## Overview The **Origin Vault** is the **pre-deposit phase** of the Axis ecosystem vault, curated by the Axis core team and hosted via [Upshift](https://upshift.finance). Its **mandate** is to **grow the supply of USDx and seed its distribution across DeFi** by seeding the markets USDx trades in. Season 1 of the pre-deposit opened **July 29** and runs until **August 5**. Deposit **USDT or USDC** to earn yield and **Coordinates** from day one. **Fees are waived** for the entire time the pre-deposit runs. When the pre-deposit phase ends, the Origin Vault converts into the ongoing **Ecosystem Vault**. ## At a glance | | | | ------------------ | -------------------------------------------------------------------------------------------------- | | **What it is** | Pre-deposit phase of the Axis ecosystem vault | | **Mandate** | Grow the supply of USDx and seed its distribution across DeFi | | **Initial cap** | $100M | | **Deposit assets** | USDT or USDC | | **Chain** | Ethereum | | **Position token** | ogUSDx | | **Fees** | Waived | | **Rewards** | \~10 Coordinates/day + Multiplier (2x for depositors in the first $50M, 1.75x for the second $50M) | | **Lock-up** | 30-day hard lock | ## How yield works Yield accrues through **share-price appreciation**, denominated in USDx. The vault earns, and the price of your position token rises over time, **your token balance stays the same**. There are **no manual claims and no rebasing**: the value simply accrues into the position. ## Phases | Phase | Lock-up | Withdrawals | | -------------------------------------- | ---------------- | --------------------------- | | **Pre-deposit** (Origin Vault) | 30-day hard lock | Locked until the phase ends | | **Ecosystem Vault** (after conversion) | Soft lock | 7-day withdrawal period | ## Rewards & referral Depositors earn **Coordinates**, the Axis rewards points. **Season 1 of Coordinates began July 29.** Depositors in the first **$50M** are set at a **2x** multiplier for all their deposits in the Origin Vault. Depositors in the second **$50M** are set at a **1.75x** multiplier. The Coordinates and referral program is live at [app.axis.to/coordinates](https://app.axis.to/coordinates), where you can see your Coordinates, create an invite link and set what you share with the people you invite. ## Next steps * [USDx Quickstart](/start-here/quickstart): how to mint, stake, and unstake USDx * [What is USDx?](/usdx-the-synthetic-dollar/usdx): the Axis Dollar and how it works ## FAQ **Where do the returns come from?** The Axis engine runs a delta-neutral arbitrage strategy, closing price variations across trading venues. Returns come from real market activity, not from token emissions or incentives. That is why the base return is a verifiable 10-20%, and why it holds across market conditions rather than depending on a bull market. **Is the 10-20% APY real, or a promo rate?** Real. Performance is independently verified by [Accountable](https://axis.accountable.capital) and the Axis Transparency Dashboard, and the strategy has a multi-year track record behind it. It is a net range. **What happens when funding rates go negative?** Our strategy does not rely on funding rates, we profit from spot price dislocations. Also, delta-neutral does not mean single-strategy. The Axis engine runs multiple uncorrelated sources of return at once. When one compresses, capital rotates to the others. The strategy is built to hold up when any single source turns unfavorable. **Where can I verify performance?** You can head to the Axis Transparency Dashboard to verify the engine's performance. **Is the Origin Vault the only way to access the strategy?** No. The strategy itself is not gated, and sUSDx gives permissionless access to the same engine at any time. What the Origin Vault opens is the chance to be early and receive a 2x multiplier on the first $50M. For a limited window, your deposit helps bootstrap the balance sheet and seed the early liquidity that compounds into network effects, and Axis Origin rewards the capital that shows up first. **Is there a minimum deposit size?** No, there is no minimum deposit size. **What is USDx?** USDx is a synthetic dollar backed by the collateral and delta-neutral Axis positions. When you deposit, your capital sits in the Axis engine. USDx mints at vault close. Staking USDx into sUSDx earns Axis performance, and continues your loyalty clock. See [What is USDx?](/usdx-the-synthetic-dollar/usdx) to learn more. **How do I deposit?** Deposit USDT or USDC into the Origin Vault on Ethereum L1, starting July 29. The vault is enabled by [Upshift](https://upshift.finance). **Is there a lock?** Yes. Deposits carry a mandatory one-month lock after the window closes. **What is the Multiplier?** Depositing from July 29 puts you on a Multiplier applied to your accrual. Depositors in the first $50M are set at a 2x multiplier for all their deposits in the Origin Vault. Depositors in the second $50M are set at a 1.75x multiplier. **What are Coordinates?** Coordinates are your position on the Grid, the map of every depositor's standing in Axis Origin. You accrue them on your deposited balance over time, scaled by your Multiplier. **Is my deposit safe?** The onchain contracts behind the vault have been independently audited by [OpenZeppelin](https://www.openzeppelin.com/news/axis-coordinate-v2-contracts-audit), with zero critical issues. The Axis team has been operating this same strategy, together, for 8 years already. **Is there a cap?** Yes, $100M. The deposit window runs July 29 to August 5, and closes earlier if the cap fills. **What is the deadline?** The window closes August 5, or when the cap fills, whichever comes first. Given expected demand, plan for sooner rather than later. **Who is behind Axis?** Axis is led by [industry veterans](https://axis.to/about) with decades of experience in capital markets, digital assets, and financial infrastructure. Our team has delivered consistent, risk-adjusted returns since 2018 while maintaining exceptional liquidity and scale as the leading delta-neutral arbitrageur in crypto markets. # What is USDx? USDx, the Axis Dollar, is Axis's synthetic dollar, an upgradeable ERC-20 token. New USDx is created only through the Axis primary market against supported collateral; the token itself grants minting rights to the market alone. ## Minting Minting runs through the **primary market** (`USDxMarket`), which settles signed market orders. A mint order states: * who provides the collateral and who receives USDx; * the collateral asset and amount, and the USDx amount; * an expiry and a one-time nonce. An eligible participant signs the order and an authorized operator submits it for settlement. The market verifies the order, checks capacity, and routes collateral to registered custody before USDx is minted. Mint capacity is bounded by configured caps, a `CapConfig` meters USDx output against a `cap` over a chosen `CapScope` and `WindowType` (for example, per block), and a failed settlement consumes neither the nonce nor the capacity, so a rejected order can be safely retried. Eligibility and access conditions are enforced around the market, not inside the token. ## Redemption Redemption also settles through the primary market. A signed redeem order specifies the USDx to burn and the collateral asset and amount to return; an authorized operator submits it. Settlement depends on order validity, operator availability, the same configured `CapConfig` capacity (metering USDx input), and sufficient collateral available to the market. Redeeming *staked* USDx (sUSDx → USDx) is a separate, asynchronous flow. See [What is sUSDx?](/susdx-the-rewards-vault/susdx). ## Token controls USDx is a governed token: every balance-changing transfer routes through a single enforcement point, so these controls apply uniformly. * **Supply** is role-gated, only the primary market may mint (`MARKET_ROLE`, held by `USDxMarket`). * **Bridging** across chains uses dedicated mint/burn under `BRIDGE_ROLE`. * **Pause** (`PAUSER_ROLE`) can halt transfers in an emergency. * **Restrictions** (`RESTRICTION_ROLE`) can block specified addresses from sending, receiving, or spending USDx. These powers serve security and compliance, and they also create administrative and censorship risk. See [Access Control](/reference/access-control) and [Disclosures](/resources-and-legal/compliance). ## What supports USDx At the contract level, USDx issuance is tied to supported collateral received through the primary market. The contracts enforce which collateral tokens and custody addresses are allowed, but they do not, by themselves, prove the current composition, value, liquidity, or safety of assets held outside the contracts. Where does the yield come from? The collateral backing USDx is deployed into market-neutral strategies whose structural edge is cross-venue and cross-asset fragmentation, a durable 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. That yield is passed to stakers through sUSDx, not to USDx holders directly, since holding USDx alone earns nothing. That distinction matters: **onchain issuance controls are not the same as a real-time proof of reserves or a guarantee of redemption.** See [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). ## USDx versus sUSDx | | USDx | sUSDx | | ----------------- | ------------------------------------------- | ------------------------------------------------- | | Type | Synthetic-dollar token (ERC-20) | Rewards vault position (ERC-4626) | | Primary purpose | Transfer, hold, stake, or redeem | Accrue vested rewards paid to the vault | | Value measured by | Market price and redemption terms | USDx assets per sUSDx position (exchange rate) | | Staking yield | No | Variable; depends on rewards delivered and vested | | Exit | Submit a redeem order to the primary market | Request redemption (async), then claim USDx | ## What USDx does not guarantee USDx does not guarantee: * a market price of exactly $1 at every moment; * immediate or unlimited minting or redemption; * secondary-market liquidity; * the absence of custody, counterparty, or strategy losses. Read [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability) for the mechanism and [Risk Overview](/risk/risk-overview) for its failure modes. # How USDx Targets $1 {% hint style="info" %} **This page describes how the peg mechanism is designed to work. It is not a guarantee of peg performance.** USDx can trade above or below $1. {% endhint %} USDx, the Axis Dollar, is designed to reference the US dollar, but its market price is set by buyers and sellers. The protocol's main price-stability pathway is a two-sided **arbitrage incentive** that pulls the market price back toward the value of the backing. It works in both directions, carried by approved counterparties who can access the primary market. ## The peg-arbitrage mechanism The peg is held by arbitrage on both sides of the target, not by a hard price lock: * **When USDx trades at a premium.** Above the value of its backing, an approved counterparty can buy collateral from the primary market, mint new USDx at roughly the value of the backing, and sell that USDx into the premium on the secondary market. The added supply works to push the price back down toward backing. * **When USDx trades at a discount.** Below the value of its backing on the secondary market, a counterparty can buy USDx cheaply on the secondary market and redeem it with the protocol at the value of the backing. The reduced circulating supply works to push the price back up toward backing. In each direction the arbitrage *incentive* exists, the spread between the market price and the backing is what a participant may capture, but it is not a promise of profit. Arbitrage of the primary market (minting and redeeming) requires being an **approved counterparty**; the secondary-market leg is open to anyone. These are arbitrage incentives, not a hard price lock. ![The potential above-target minting pathway and below-target redemption pathway for USDx.](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-f0b6c81feaca192f03a9f9d2bfc4e24665b2ce6d%2Fpeg-stability-pathways.svg?alt=media) The word **may** is essential. An incentive only affects price if participants can execute it and if the trade remains economical after liquidity, timing, fees, and risk. ## What the contracts contribute The primary market (`USDxMarket`) validates signed order terms, supported collateral, registered custody routes and channels, order deadlines, one-time nonces, authorized operators, and configured capacity caps (`CapConfig`). These controls define how primary issuance and redemption can occur. The contract does not automatically force the secondary-market price to $1, calculate orders from an external price oracle, or guarantee continuous operator and collateral availability. ## Why USDx can trade away from $1 A premium or discount can persist when: * minting or redemption is rate-limited by capacity caps, paused, or unavailable; * an operator, custodian, or venue is unavailable; * the specified collateral cannot be delivered on time; * secondary-market liquidity is thin; * transaction costs exceed the available arbitrage spread; * market participants price in custody, strategy, smart contract, or regulatory risk. ## sUSDx does not set the USDx price The sUSDx exchange rate reports how much accounted USDx each sUSDx position represents. It does not report the US-dollar market value of USDx. If USDx trades below $1, an sUSDx position worth more than one USDx can still be worth less than the same number of US dollars. ## No absolute peg guarantee The mint-and-redeem pathway is intended to create incentives around the target price. It cannot eliminate every reason that the market price might diverge, and it does not make USDx equivalent to cash or an insured bank deposit. # USDx Primary Market Mint USDx from collateral and redeem USDx back to collateral through the Axis primary market. {% hint style="info" %} This is a **How-to Guide**. For background on why the minting system works this way, see [Architecture](/technical-and-architecture/architecture). For complete function signatures, see [Core Contracts Reference](/reference/core-contracts). {% endhint %} *** ## Minting and redeeming are one market Minting creates new synthetic dollars and redeeming is the reverse. Both are the same action seen from opposite sides: you are **buying or selling USDx in the primary market** against the whitelisted collateral assets. Each collateral asset defines a market that can come online or be deprecated over time. The market is the general case, which is why the core V2 contract is `USDxMarket`. Participants trade against it through signed orders rather than calling a mint function directly, so one contract settles both directions. Its signed-order, **settle-onchain / match-offchain** design is inspired by the [**0x**](https://0x.org) **and** [**CoW Swap**](https://swap.cow.fi) **style** of onchain settlement: settlement happens atomically onchain while order matching happens offchain (RFQ), and participants keep control of their assets until settlement. The flow is the same on both sides: 1. An approved counterparty requests a price from the **Axis Market API**. 2. The counterparty generates a **signed EIP-712 order** on those terms. 3. The protocol server checks the required balances and approvals. It may **reject** an order but **cannot alter** it, the terms are pre-approved by the signer and settle exactly as signed, or not at all. 4. On approval, the order is sent to the chain and settles as an **atomic onchain mint** (or redeem). Settlement is atomic on chain; matching is off chain (RFQ); users retain control throughout. Putting reserves to work involves the cost of winding and unwinding positions, so the price a counterparty is quoted reflects that cost; the protocol works to **minimize slippage** in servicing primary market orders. *** ## How to Mint USDx Minting converts supported collateral into USDx by settling a signed EIP-712 order on `USDxMarket`. An **approved counterparty**, a whitelisted, eligible primary market account, submits an order on the USDx market; when that order is filled, USDx is **minted at roughly 1:1** against the incoming collateral, at the asset and amounts specified in the order. An eligible participant signs the order; an authorized operator submits it for settlement. New supply flows only through the market: `USDxMarket` holds `MARKET_ROLE` on `USDx` and is the only supply authority at launch, Axis ships no separate `MINTER_ROLE`/`BURNER_ROLE`. On settlement, the incoming collateral is **routed through the market's channels and lanes to a custodian account**, from which **custody is then transferred out to the exchanges and trading venues** that hold the backing portfolio, see [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). By design, Axis takes **no profit from minting or redeeming USDx**: mint and redeem settle against the collateral in the order rather than at a spread meant to earn Axis a margin. Yield comes from how the backing is deployed, not from the mint or redeem itself. ### Prerequisites * The order's `accountId` must be an approved primary market account, eligible under current access and terms. * The `signer` must be authorized for that account, a direct EOA match, an accepted delegated signer, or an ERC-1271 smart account. * The collateral asset and USDx must form an enabled route (`routeId`), and the settlement path (`channelId`) must be enabled. * The account must have approved `USDxMarket` to spend the collateral (the order's input asset). * An operator holding `MINT_OPERATOR_ROLE` must submit the order for settlement. Issuance itself is gated by `MARKET_ROLE` on `USDx`, held by `USDxMarket`, there is no standalone minter role. ### Step 1: Construct the Order The V2 order (`Order`, documented as `PrimaryMarketOrder`) binds the account, the approved route and channel, the signer, the side, the input/output assets, the receiver, a deadline, a one-time nonce, and the accepted-terms hash. ```solidity IUSDxMarket.Order memory order = IUSDxMarket.Order({ accountId: userAccountId, // approved primary market account routeId: mintRouteId, // enabled USDT -> USDx route channelId: custodyChannelId, // approved settlement path signer: userAddress, // authorized for accountId side: IUSDxMarket.OrderSide.MINT, inputAsset: USDT_ADDRESS, outputAsset: USDX_ADDRESS, inputAmount: 1000e6, // 1000 USDT (6 decimals) minOutputAmount: 1000e18, // min 1000 USDx out (18 decimals) receiver: userAddress, // receives USDx deadline: block.timestamp + 1 hours, nonce: 1, // non-zero, unique per accountId termsHash: acceptedTermsHash // accepted Minting-ToS version }); ``` {% hint style="warning" %} The nonce must be **non-zero** and unused. Check availability with `verifyNonce(accountId, nonce)` before signing, nonces are namespaced per `accountId`, not per signer address, and are consumed only on successful settlement. {% endhint %} ### Step 2: Sign the Order (EIP-712) The EIP-712 domain name is `USDxMarket`, version `1`. ```javascript // ethers.js v6 const domain = { name: "USDxMarket", version: "1", chainId: chainId, verifyingContract: usdxMarketAddress }; const types = { Order: [ { name: "accountId", type: "bytes32" }, { name: "routeId", type: "bytes32" }, { name: "channelId", type: "bytes32" }, { name: "signer", type: "address" }, { name: "side", type: "uint8" }, { name: "inputAsset", type: "address" }, { name: "outputAsset", type: "address" }, { name: "inputAmount", type: "uint256" }, { name: "minOutputAmount", type: "uint256" }, { name: "receiver", type: "address" }, { name: "deadline", type: "uint256" }, { name: "nonce", type: "uint256" }, { name: "termsHash", type: "bytes32" } ] }; const signature = await signer.signTypedData(domain, types, order); ``` ### Step 3: Preview the Settlement Before an operator settles, preview the order against current policy, routing, nonce, signature, and capacity: ```solidity // Read-only: does this order settle under current state? IUSDxMarket.SettlementCheck memory check = usdxMarket.checkSettlement(order, sig, settlementData); ``` `checkMint(order, sig)` returns an `OrderCheck` (`valid`, `code`, `orderHash`, `signer`, `nonceUsed`, `availableBlockCapacity`) for the mint side. The `settlementData` argument is ignored by the preview; it only feeds the emitted settlement hash at real settlement. ### Step 4: Operator Settles the Order An operator holding `MINT_OPERATOR_ROLE` submits the signed order. Settlement re-runs every check, routes collateral to the channel's custody, mints USDx to the receiver, marks the nonce used, and records a settlement proof. ```solidity IUSDxMarket.Signature memory sig = IUSDxMarket.Signature({ signatureType: IUSDxMarket.SignatureType.EIP712, signatureBytes: signatureBytes }); // side alias: settle(...) with OrderSide.MINT, or mint(...) bytes32 proofId = usdxMarket.settle(order, sig, settlementData); ``` ### Using cast ```bash $ cast send $USDX_MARKET \ "settle((bytes32,bytes32,bytes32,address,uint8,address,address,uint256,uint256,address,uint256,uint256,bytes32),(uint8,bytes),bytes)" \ "($ACCOUNT_ID,$ROUTE_ID,$CHANNEL_ID,$SIGNER,0,$INPUT_ASSET,$OUTPUT_ASSET,$INPUT_AMOUNT,$MIN_OUTPUT_AMOUNT,$RECEIVER,$DEADLINE,$NONCE,$TERMS_HASH)" \ "(0,$SIGNATURE)" \ "$SETTLEMENT_DATA" \ --private-key $MINT_OPERATOR_KEY ``` ### Why a Settlement Is Rejected `checkMint` / `checkSettlement` surface a `bytes32` reason code without reverting, so a rejected order can be diagnosed before submission. Settlement re-runs the same checks. Common codes: | Reason code | Cause | | ------------------- | ------------------------------------------------------------------------ | | `NOT_ELIGIBLE` | Account not approved, or access/terms conditions not met | | `RESTRICTED` | Account or receiver blocked by a restriction | | `ROUTE_DISABLED` | The `routeId` is not an enabled market route | | `CHANNEL_DISABLED` | The `channelId` settlement path is not enabled | | `UNAUTHORIZED` | Signer is not the account's EOA, accepted delegate, or ERC-1271 approver | | `CAPACITY_EXCEEDED` | Configured `CapConfig` capacity for the scope is exhausted | | `PAUSED` | Market, token, or the relevant flow is paused | A failed settlement consumes neither the nonce nor the capacity, so a rejected order can be safely retried. Signature expiry (`block.timestamp > deadline`) and a consumed nonce also block settlement. *** ## How to Redeem USDx Redemption burns USDx and returns collateral to the receiver, settled by an operator on the primary market, the mirror of mint. {% hint style="info" %} This is the **primary market** redemption of USDx for collateral. Redeeming *staked* USDx (sUSDx → USDx) is a separate, asynchronous ERC-7540 flow with a cooldown, see the [Stake & Unstake guide](/susdx-the-rewards-vault/stake-and-unstake) and [What is sUSDx?](/susdx-the-rewards-vault/susdx). {% endhint %} ### Redemption pricing Redemption carries an execution fee. It is not a spread Axis earns: as above, mint and redeem settle against the collateral in the order, and Axis takes no margin on either side. The fee passes through the cost of unwinding backing positions to meet the redemption, which is why it rises with the size and the speed demanded: an instant exit prices above a 7d one, and a larger share of the book prices above a smaller one. | Redemption option | Target fee | Maximum fee | | -------------------------------------- | ---------- | ----------- | | **Instant**, up to 2% of book per day | 10 bps | 30 bps | | **7d**, aggregate redemptions ≤10% | 10 bps | 15 bps | | **7d**, aggregate redemptions >10–50% | 10–18 bps | 25 bps | | **7d**, aggregate redemptions >50–100% | 18–35 bps | 50 bps | **Target fee** is the level the schedule prices to under normal conditions. **Maximum fee** is the ceiling applied once capacity is constrained. {% hint style="warning" %} These figures are indicative. They are not a quote, committed capacity, or a redemption SLA. Pricing applies to approved primary market counterparties and remains subject to eligibility, available capacity, and governing terms. The 7d bands are read against aggregate redemptions across the book over the period, not against any one counterparty's size. {% endhint %} ### Prerequisites * The `accountId` must be an approved, eligible primary market account, and the `signer` authorized for it. * USDx and the collateral asset must form an enabled redeem route (`routeId`), with an enabled settlement `channelId`. * The account must have approved `USDxMarket` to spend its USDx (the order's input asset). * An operator holding `REDEEM_OPERATOR_ROLE` must submit the order. * The market must have sufficient collateral available through the channel. ### Step 1: Construct a Redeem Order Same `Order` schema as mint, with `side = REDEEM` and the assets reversed, USDx in, collateral out: ```solidity IUSDxMarket.Order memory order = IUSDxMarket.Order({ accountId: userAccountId, routeId: redeemRouteId, // enabled USDx -> USDT route channelId: custodyChannelId, signer: userAddress, side: IUSDxMarket.OrderSide.REDEEM, inputAsset: USDX_ADDRESS, outputAsset: USDT_ADDRESS, inputAmount: 1000e18, // 1000 USDx (18 decimals) minOutputAmount: 1000e6, // min 1000 USDT out (6 decimals) receiver: userAddress, // receives collateral deadline: block.timestamp + 1 hours, nonce: 2, termsHash: acceptedTermsHash }); ``` ### Step 2: Sign and Settle Sign with the same EIP-712 domain (`USDxMarket`, version `1`). An operator holding `REDEEM_OPERATOR_ROLE` then settles: ```solidity // side alias: settle(...) with OrderSide.REDEEM, or redeem(...) bytes32 proofId = usdxMarket.settle(order, sig, settlementData); ``` Settlement verifies the order, meters redeem capacity (`CapConfig` metering USDx input), burns the USDx, and releases collateral to the receiver through the approved channel. *** ## How to Set Up Delegated Signing Smart contracts cannot produce ECDSA signatures directly. The delegation registry on `USDxMarket` lets a source account authorize an EOA to sign orders on its behalf (a two-step initiate-then-confirm handshake). ERC-1271 smart-account validation is also supported as a separate path. ### Step 1: Source Account Initiates Delegation ```solidity // Called by the delegating account usdxMarket.setDelegatedSigner(eoaAddress); // SignerStatus: PENDING ``` ### Step 2: Signer Confirms ```solidity // Called by the EOA being delegated usdxMarket.confirmDelegatedSigner(sourceAccount); // SignerStatus: ACCEPTED ``` The EOA can now sign orders whose `signer` is authorized for the source account. Read current status with `delegatedSigner(signer, source)`. ### Revoking Delegation ```solidity // Called by the delegating account usdxMarket.removeDelegatedSigner(eoaAddress); // SignerStatus: REJECTED ``` *** ## Nonce & Replay Protection Nonces prevent order replay. Each `accountId` has an independent nonce space tracked as a bitmap (256 nonces per storage slot). A nonce must be non-zero and is consumed **only on successful settlement**. ### Check Nonce Availability ```solidity bool used = usdxMarket.isNonceUsed(accountId, nonce); // or the bitmap form: (uint256 slot, uint256 bitmap, uint256 bit) = usdxMarket.verifyNonce(accountId, nonce); bool available = (bitmap & bit) == 0; ``` ```bash $ cast call $USDX_MARKET "isNonceUsed(bytes32,uint256)(bool)" $ACCOUNT_ID $NONCE ``` Nonces do not need to be sequential, any unused non-zero nonce in the `uint256` space is valid. ### Cancelling an Order A holder of `SETTLEMENT_MANAGER_ROLE` can pre-emptively tombstone an order hash with `cancelOrder(order)`, emitting `OrderCancelled`, so it can never settle. Cancellation does **not** consume the nonce, the order is invalidated by its tombstone, not by the nonce slot, and does not verify the signature. *** Staked USDx (sUSDx) is where yield accrues: the collateral backing USDx is deployed into strategies whose 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), and that yield is passed to stakers through sUSDx. See [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield). Holding USDx alone earns nothing. # What is sUSDx? sUSDx is **the Axis Rewards Vault**, the staking rewards vault of the protocol. Staking **USDx, the Axis Dollar** (a synthetic dollar), into the vault makes a holder **eligible for the protocol's incentive reward distributions**, and in return you receive sUSDx, a tokenized position in the vault whose value grows as rewards accrue to it. Rewards accrue directly to the staking contract, so the amount of USDx each sUSDx represents rises over time **with no further action required**. You are never required to rebase or claim, and the reward accrues into the position itself. Those rewards are **discretionary and forward-looking**, a signal of what the protocol is willing to pay for capital (a capital cost), **unbundled** from the reserve yield rather than a direct pass-through of it. The reserves may grow or contract with little direct relationship to the rewards available in the vault. How rewards are funded and vest is covered in [How Rewards Reach sUSDx](/susdx-the-rewards-vault/reward-distribution). ## The vault in one line sUSDx is the share token of an **ERC-4626 vault** (`StakedUSDx`) whose underlying asset is USDx. One sUSDx is a claim on a growing amount of USDx: $$ \text{USDx per sUSDx} = \frac{\text{vault assets (incl. vested rewards)}}{\text{total sUSDx supply}} $$ ## How a share accrues value The vault's returns come from **Axis's structural edge in cross-venue and cross-asset fragmentation**, a durable, market-neutral yield source that does not rely on any single mechanism, with Axis's trading engine capturing pricing differences across venues and assets offchain (see [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield)). Funding is one component (and can be the larger share in a given period); see the Transparency Dashboard for current attribution. Market-neutral arbitrage, capturing price differences while hedging out market direction, is an established institutional trading strategy, not a crypto invention. Realized results are delivered to the vault as USDx rewards by the reward manager (`fundRewards`, gated by `REWARD_MANAGER_ROLE`). The backing behind the yield is evidenced separately. See [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). Rewards do **not** hit the share price all at once. They **vest linearly over a configured window**. The live value is a configured parameter of the deployed contract, and only the vested portion counts toward vault assets. So the exchange rate rises smoothly as rewards vest, rather than jumping on each funding, which also means a large deposit can't front-run a reward and capture it instantly. Your sUSDx balance never changes; each token simply comes to represent more USDx. By design, the vault's accounting only ever vests **positive or flat** rewards into the exchange rate: rewards are added when they are funded and vest forward over the window, so the intended behaviour is for the USDx-per-sUSDx rate to rise or hold steady rather than step down on each funding. This is a description of how vesting works, not a promise that the rate can never fall. Separately, the protocol is designed to be **over-collateralized**: backing is intended to exceed outstanding USDx, so that this buffer can **absorb contractions in the reserves** rather than passing them straight through to stakers. The buffer is a design intent, sized against reserves; it is not a named guarantee fund, and it does not remove the risks described below. ## Staking and redeeming * **Stake.** Deposit USDx and receive sUSDx immediately, priced at the current exchange rate. * **Request redemption.** Redemption is **asynchronous** (ERC-7540): you `requestRedeem` your shares, which burns them and opens a request subject to a per-policy **cooldown**, currently **7 days**. * **Wait and claim.** Once the cooldown elapses, the request is serviced. An account holding `REDEMPTION_SERVICER_ROLE` calls `serviceRedemptions` to mark it claimable, after which you claim the underlying USDx. * **Change your mind.** A request can be **cancelled while it is still pending** (`cancelRedeemRequest`), which restores the burned shares. Amounts reserved for pending and claimable redemptions are tracked as vault liabilities, so the vault can always weigh what it holds against what it owes. ## Two different price questions | Question | Measure | | ------------------------------------------- | ------------------------------------ | | How much USDx does one sUSDx represent? | Vault exchange rate | | How many US dollars is that position worth? | USDx market price × USDx represented | An increasing exchange rate does not prevent a loss in dollar terms if USDx trades below its target or cannot be exited on expected terms. ## Yield is not fixed The vault promises no fixed rate. Realized return depends on whether strategy returns are generated, whether they are delivered to the vault, when rewards vest, and the exchange rate at which you enter and exit. A period with no new rewards creates no yield by itself, and past returns do not determine future ones. ## Key risks sUSDx holders keep every risk of USDx and add vault-specific ones, smart contract risk, dependence on reward delivery, and redemption delay (your assets are not liquid until a request is serviced). See [Risk Overview](/risk/risk-overview) and the [Stake & Unstake guide](/susdx-the-rewards-vault/stake-and-unstake). # How Axis Earns Yield Axis earns yield from structural fragmentation across venues, currencies, and settlement systems, capturing price dislocations of the same or related exposure. That fragmentation is Axis's **structural edge**: a durable, market-neutral return source. The bread-and-butter is **cross-venue and cross-currency arbitrage**; **funding-rate positions are used mainly to hedge the spot inventory**, not as a primary source of yield. Current attribution across the strategy is published on the Transparency Dashboard. Market-neutral arbitrage, capturing price differences while hedging out market direction, is an established institutional trading strategy, not a crypto invention. The engine evaluates opportunities offchain and allocates within its risk limits as market conditions change. ## One strategy, many layers Axis runs a **single market-neutral strategy expressed in several layers**, so returns come from multiple, partly independent sources rather than one trade: * **Spot arbitrage, the core.** Capturing price dislocations of the same or related exposure across execution venues, built on **low-latency execution and a microstructure edge**. It spans digital, traditional, and cross-asset markets as those markets become accessible to the strategy. * **Funding rates, the hedging leg.** Spot paired with offsetting perpetuals, so the position earns funding while hedging out broad market direction. * **Delta-neutral basis trades.** Across crypto, other digital assets, and traditional markets, including FX, tokenized equities, and commodities, as those markets become accessible to the strategy. * **Cross-asset arbitrage.** Relative value between related instruments and asset classes. * **Yield-bearing margin.** Margin held in **real-world assets, T-bills and tokenized money-market funds**, earning a return while it backs the actively-managed positions, for additional capital efficiency. Layering these is what makes the book **resilient across market cycles**: when one layer is thin, others can carry, and dislocation and volatility tend to *widen* the opportunity rather than close it. Current attribution across layers is published on the Transparency Dashboard, not fixed here. The four categories detailed below, cross-venue, cross-currency, funding rate, and OTC/RFQ, are the core layers of that single strategy. Realized strategy results can be delivered to the vault as USDx rewards by the reward manager (`fundRewards`, gated by `REWARD_MANAGER_ROLE`). Those rewards vest linearly over a configured window. The live value is a configured parameter, and only the vested portion counts toward vault assets. So the amount of USDx represented by each sUSDx position rises smoothly as rewards vest (see [How Rewards Reach sUSDx](/susdx-the-rewards-vault/reward-distribution)). ## 1. Cross-venue arbitrage Cross-venue arbitrage captures fragmentation of the same or closely related exposure across centralized execution venues. It includes exchange-to-exchange spot arbitrage and regional-to-global pricing gaps. For example, if BTC is executable at $60,000 on one exchange and $60,050 on another, a paired trade can buy on the cheaper venue and sell on the more expensive one. The displayed $50 difference is a gross spread, not guaranteed profit: fees, slippage, transfer time, partial fills, custody, and settlement risk determine the realized result. ## 2. Cross-currency arbitrage Cross-currency arbitrage captures fragmentation of the same asset across quote currencies while hedging or converting the currency exposure. For example, a structure can buy BTC in USD and sell BTC in TRY where a premium exists. The premium must remain after FX conversion or hedging, trading costs, settlement timing, local liquidity, banking access, and capital controls. A price difference measured in two currencies is not directly comparable until those effects are included. ## 3. Funding rate arbitrage Funding rate arbitrage is one of the four strategy categories. It pairs a spot position with an offsetting perpetual-futures position to seek funding income while reducing broad market direction. A common example is long spot BTC and an equal short BTC perpetual when funding is positive, so the short side receives funding under the venue's payment convention. The hedge can still lose money if funding reverses, the spot and perpetual prices diverge, margin becomes insufficient, either leg executes incompletely, or a venue restricts access or withdrawals. Equal notional at entry does not guarantee the position remains fully hedged. ## 4. OTC/RFQ Over-the-counter and request-for-quote execution seeks bilateral prices for a defined asset, size, and settlement arrangement. An RFQ lets a trader ask one or more counterparties for an executable quote rather than exposing the full order to a public order book. For example, a trader can request quotes for a block sale from several counterparties and compare each response with an executable market hedge. If the selected bilateral trade and hedge both execute within the cost and risk budget, the remaining spread becomes the intended return. The result depends on quote validity, hedge execution, credit, legal terms, custody, and settlement. ## Why performance varies Opportunities, funding, FX rates, quote availability, interest rates, capacity, costs, and risk change over time. A strategy can be inactive or unattractive, and an expected profitable position can realize less than expected or lose money. Historical performance is not a promised future APY. Realized results reflect offchain trading; the reserves and custody behind them are evidenced separately in [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). Read [Trading Strategy Overview](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies) for the strategy taxonomy, [How Rewards Reach sUSDx](/susdx-the-rewards-vault/reward-distribution) for the accounting boundary, and [Risk Overview](/risk/risk-overview) for failure modes. # Trading Strategy Overview Axis's market-neutral trading engine earns its return from structural fragmentation across venues, currencies, and settlement systems, capturing price dislocations of the same or related exposure. Two strategies are the **bread and butter**: cross-venue arbitrage and cross-currency arbitrage. This fragmentation across venues and assets is Axis's **structural edge**, a durable, market-neutral yield source that does not rely on any single mechanism. Alongside the two core strategies, **funding rate arbitrage** plays a supporting role: for Axis it is primarily a way to hedge the spot inventory those strategies hold, not a primary source of yield, the funding trade has been well arbitraged across the industry over many years. **OTC/RFQ** is treated as a future expansion built on Axis's execution infrastructure rather than a live product, and Axis offers no institutional lending. Axis's strategies execute on **centralized venues**; the protocol does **not** run onchain arbitrage. Current attribution across the active strategies lives on the Transparency Dashboard. ## The basic arbitrage loop The simplest cross-venue setup pairs a purchase where an exposure is cheaper with a sale or hedge where it is more expensive. The displayed difference is only a **gross spread**; it becomes a realized result only after both legs execute and all costs are included. ## Strategy map | Strategy | Illustrative structure | What execution depends on | Key residual risks | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | **Cross-venue arbitrage** | Buy BTC at $60,000 on one exchange and sell at $60,050 on another | Both legs remaining executable after fees, slippage, transfers and settlement | Partial fills, latency, trapped inventory, venue and custody failure | | **Cross-currency arbitrage** | Buy BTC in USD and sell BTC in TRY where a premium exists | FX conversion or hedge, local liquidity, banking access and settlement | FX mismatch, capital controls, local-market dislocation and counterparty failure | | **Funding rate arbitrage** | Hold long spot BTC and an equal short BTC perpetual while positive funding is paid to the short | Funding staying favorable, basis behavior, margin and borrow or collateral availability | Funding reversal, basis divergence, liquidation, hedge drift and venue failure | | **OTC/RFQ** | Request an executable bilateral quote for a defined block, then compare or pair it with an available market hedge | Quote validity, credit, legal terms, hedge execution, custody and settlement | Counterparty default, information leakage, failed hedge and settlement delay | The cross-venue and cross-currency rows are the fragmentation core, Axis's bread-and-butter and structural edge. Funding rate arbitrage is shown for completeness, but for Axis its main role is to **hedge the spot inventory** those strategies hold rather than to drive returns; it is also not the same as basis trading. Funding is the periodic payment between perpetual longs and shorts; basis is the price difference between related instruments. A funding strategy may also carry basis risk, but the intended return driver described here is funding. OTC/RFQ is a roadmap direction rather than a current strategy. ## What Axis does not do **Axis does not run onchain arbitrage strategies.** Onchain markets, automated market makers, transaction-ordering opportunities, and intent or solver systems can host arbitrage and market-neutral structures. Axis's trading engine executes on **centralized venues** instead. Concretely, Axis does not arbitrage automated market makers, does not trade onchain spot, and does not treat pool rebalancing, ordering-based extraction, or intent-based execution as a source of return. Onchain settlement appears in Axis only where the protocol itself settles onchain, minting and redeeming USDx for example, not as a venue for the desk's trading strategies. This is a current scope decision, not a permanent exclusion. Onchain perpetual venues, Hyperliquid among them, run order books and funding mechanics of the same kind the desk already trades on centralized venues, and are a plausible extension. Any such extension would carry its own venue, custody, settlement, and execution risks, and would be described here before it is relied on. Nothing here commits Axis to adding a venue, or to a date. ## Choose a strategy topic * [Cross-Venue Arbitrage](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/cross-venue-arbitrage) covers exchange-to-exchange and regional-to-global structures. * [Cross-Currency Arbitrage](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/cross-currency-arbitrage) explains quote-currency premiums and the FX hedge boundary. * [Funding Rate Arbitrage](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/funding-rate-arbitrage) explains the spot–perpetual funding structure and how it differs from basis trading. * [OTC/RFQ](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/otc-rfq) explains bilateral liquidity and RFQ execution. * [Delta Neutrality](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/delta-neutrality) explains what directional hedging removes, and what it leaves behind. For execution mechanics, see [Centralized-Venue Execution](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/centralized-arbitrage), where Axis's strategies run. ## From spread to user reward A quoted spread is not profit. Realized results depend on both legs executing, all costs, financing, settlement, hedge performance, and the ability to exit. A realized strategy result is also not yet sUSDx yield: only USDx rewards delivered to the vault by the reward manager (`fundRewards`, gated by `REWARD_MANAGER_ROLE`) enter its accounting. Read [How Rewards Reach sUSDx](/susdx-the-rewards-vault/reward-distribution) for that boundary. # Cross-Venue Arbitrage Cross-venue arbitrage is Axis's bread-and-butter strategy. As dollars enter the protocol, the desk puts on basis positions and spreads spot inventory across execution venues. It monitors the same pair across those venues and, when a price discrepancy appears, executes trades to close the gap. Closing gaps this way steadily moves inventory from one venue to another, so the desk continually rebalances, transferring inventory (mostly stablecoins) between venues to keep trading capacity where it is needed. The core operational requirement is keeping trading inventory positioned on the right venues, where the opportunities are. The strategy seeks temporary price differences for the same or closely related exposure across centralized execution venues. Axis does not trade on decentralized venues. See [What Axis does not do](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies#what-axis-does-not-do). ## Common structures ### Exchange versus exchange If BTC is executable at $60,000 on one exchange and $60,050 on another, a paired trade can buy on the cheaper exchange and sell on the more expensive exchange. The $50 difference is a gross spread before trading fees, slippage, market impact, transfers, and settlement. Profit remains uncertain until both legs execute and costs are known. ### Regional venue versus global venue The same asset can price differently on a regional venue than on a global one, because capital cannot move freely between them. Cross-border barriers, local banking access, and thin connectivity hold the gap open. Trading it requires inventory positioned on both sides and a route to move value between them. ## Why coordination matters The two legs may not settle together. One can fill while the other is delayed, rejected, or repriced. Transfers can be slow, inventory can become trapped, and an outage can prevent rebalancing. This creates combined exposure to price movement, venue solvency, custody, bridges, chains, contracts, and operational access. A larger displayed spread may simply compensate for larger execution risk. ## Result boundary Profit remains uncertain until both legs execute, costs are known, and the position is closed or reliably valued. Read [How Rewards Reach sUSDx](/susdx-the-rewards-vault/reward-distribution) for why even a realized result is separate from a distributed vault reward. # Funding Rate Arbitrage Funding rate arbitrage seeks periodic payments between perpetual-futures longs and shorts while using an offsetting position to reduce broad market direction. Market-neutral arbitrage, capturing price differences while hedging out market direction, is an established institutional trading strategy, not a crypto invention. For Axis, funding rate arbitrage is **not the primary source of yield**. The funding trade has been well arbitraged across the industry over many years, so its standalone return has compressed. The desk has deep experience managing it, and it still carries real risk. Its main role at Axis is to **hedge the spot inventory** held for the bread-and-butter cross-venue and cross-currency strategies, not to serve as a primary revenue driver. ## Illustrative structure When a BTC perpetual has positive funding paid by longs to shorts, a structure can: 1. buy spot BTC; 2. short an equal notional amount of the BTC perpetual; and 3. receive funding on the short perpetual while the long spot position offsets much of the directional exposure. The two legs are equal at entry in this example. Price changes, contract mechanics, fees, and rebalancing can change the hedge ratio over time. ## Funding is not basis The **funding rate** is a periodic payment between perpetual-futures longs and shorts. The **basis** is the price difference between two related instruments, such as spot and a perpetual. A funding rate strategy can experience gains or losses from basis changes, but its intended return driver is the funding payment. A basis trade instead seeks a change or convergence in the price difference itself. ## Residual risks Positive funding can shrink or reverse. The perpetual can diverge from spot, margin requirements can rise, the short can be liquidated, either leg can fill incompletely, and a venue can restrict trading or withdrawals. Fees, borrow or collateral costs, and rebalancing can exceed funding received. Read [Delta Neutrality](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/delta-neutrality) for the hedge boundary and [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for venue controls. # Cross-Currency Arbitrage Cross-currency arbitrage is triangular. The desk combines legs such as an asset priced in country A's currency and country A's currency priced against country B's currency. Chained together, these legs form a **synthetic FX pair** that can be priced differently than the same pair in traditional FX markets. The desk hedges out the FX exposure and seeks to capture the difference. The approach applies to any asset traded across jurisdictions and currencies, BTC is only one example. The intended spread only becomes comparable after the quote currencies are converted or hedged. ## Illustrative structure Suppose BTC can be bought in country A's currency, while the currency leg between country A and country B implies a different price than the traditional FX cross would suggest. A paired structure trades the two legs and then hedges or converts the resulting FX exposure to isolate the synthetic-versus-traditional difference. The visible local-market premium is not the realized return. The calculation must include: * the executable exchange rate between the two currencies; * FX hedge or conversion costs; * trading fees and market impact in each market; * transfer, banking, custody, and settlement costs; * the time during which the asset and currency legs can move independently. ## Why the premium can exist Local demand, capital controls, banking access, settlement speed, market hours, and uneven liquidity can cause the same asset to trade at different currency-adjusted prices. Those frictions can also prevent the spread from being captured. ## Residual risks Cross-currency arbitrage remains exposed to FX hedge mismatch, local-market liquidity, capital controls, banking or counterparty disruption, delayed settlement, trapped funds, partial fills, and price movement between legs. Read [Delta Neutrality](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/delta-neutrality) for the hedge boundary and [Market & Trading Risk](/risk/market-trading-risk) for broader failure modes. # OTC/RFQ OTC/RFQ is a **future expansion** of what Axis can offer, built on the protocol's existing execution infrastructure rather than on any lending activity, Axis does no institutional lending. Axis runs a strong order-execution and order-management system (OMS) with direct venue access, broad market connectivity, and pre- and post-trade risk management. The same infrastructure that positions and hedges the protocol's own inventory can, over time, provide tight and competitive quotes to fintechs, neobanks, and other liquidity providers that need to convert one asset into another, any-to-any, across a growing set of asset standards and classes. Offering this kind of execution would also help manage the protocol's reserves productively and sustainably, making returns less reliant on pure market inefficiency. This is a direction on the roadmap, not a live product today. Over-the-counter and request-for-quote execution gives the engine a bilateral path for sourcing a price for a defined asset, size, and settlement arrangement. ## How an RFQ works An RFQ asks one or more counterparties to respond with an executable quote instead of exposing the full order to a public order book. A quote normally specifies the asset, side, size, price, validity window, and settlement terms. ## Illustrative structure A trader may request quotes to sell a block and receive a response at a premium to an executable market hedge. If the bilateral sale and the hedge can both be completed within the risk and cost budget, the paired execution may seek the remaining spread. The quoted premium is not guaranteed profit. The hedge can move or fail before execution, the counterparty can withdraw or reject the quote, and legal, credit, custody, and settlement terms can change the result. ## Why bilateral execution can help OTC/RFQ execution can provide a firm price for a defined size, reduce public order-book impact, and match specific settlement needs. It can also concentrate counterparty exposure and reveal information about trading interest. ## Residual risks Key risks include counterparty default, quote expiry, information leakage, incomplete or delayed hedging, documentation disputes, custody failure, settlement mismatch, and limited ability to unwind a block. Read [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for the counterparty framework and [How Rewards Reach sUSDx](/susdx-the-rewards-vault/reward-distribution) for the boundary between a realized result and a vault reward. # Delta Neutrality Delta measures how much a position's value is expected to change when the underlying market price moves. A delta-neutral structure pairs exposures so their directional sensitivities approximately offset at a point in time. ## What the hedge reduces If a long position and a short hedge respond similarly, broad market moves should have less effect on the combined position than on either leg alone. This can make basis, funding, or cross-venue spreads the main intended return driver. ## What the hedge does not remove Delta-neutral does **not** mean risk-neutral or lossless. The position can still lose money when: * the basis widens or does not converge; * one leg fills late, partially, or not at all; * funding, borrow, fees, or margin terms change; * liquidity disappears or an exit moves the market; * a venue, custodian, counterparty, chain, or contract fails; * the instruments stop tracking each other as expected. ## Why delta changes Price movement, nonlinear derivatives, funding, rebalancing, and changing correlations can alter the hedge ratio. Maintaining low directional exposure therefore requires measurement and execution; it is not a permanent property of opening two opposite positions. ## How to interpret delta-neutral Treat “delta-neutral” as a description of the intended directional hedge, not a guarantee about return, drawdown, solvency, or liquidity. See [Market & Trading Risk](/risk/market-trading-risk) for the control framework and residual risks. # Centralized-Venue Execution Centralized venues can provide spot, perpetual, FX, financing, and block-liquidity execution for the four trading-engine categories. A venue is an execution environment, not a separate strategy category. ## Spot and derivative execution A strategy can pair a spot asset with a derivative while reducing broad directional exposure. Funding rate arbitrage seeks periodic funding payments; basis trading seeks a price difference between related instruments. They are distinct return drivers even when the same spot and derivative instruments are involved. The hedge does not remove basis expansion, liquidation or margin pressure, funding changes, partial fills, venue default, restricted withdrawals, or hedge mismatch. ## Funding and financing Perpetuals, lending markets, and financing instruments can carry different rates. A strategy can use them when the expected return exceeds execution costs and the risk budget. Rates can reverse, borrow can be recalled, collateral terms can change, and liquidity or counterparties can fail. A quoted rate difference is therefore not a locked return. ## Cross-currency execution Price differences can arise across currency denominations. For example, a structure can buy BTC in USD and sell BTC in TRY where a premium exists. Pairing or converting the currency exposure seeks to isolate the intended spread. Residual risks include FX hedge mismatch, settlement timing, capital controls, local-market liquidity, and banking or counterparty disruption. ## What determines the result Realized results depend on fill quality, fees, funding, borrow availability, collateral, margin, and the ability to close both legs. Read [Delta Neutrality](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies/delta-neutrality) for the hedge boundary and [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for venue controls. # Track Record {% hint style="warning" %} **These are the results of prior trading businesses, not of USDx or sUSDx.** Those businesses were not open to the public, and nothing on this page is a quote or forecast of sUSDx yield. Past performance does not guarantee future results. {% endhint %} The strategy behind Axis is not new. The same core team has run the same market-neutral book since 2018, through every market cycle since. ![Cumulative return since July 2018](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-6af67cbf5f7c95f0d11ca7f9276d32731bf1917c%2Fcumulative-return.svg?alt=media) **360.7% cumulative since July 2018**, gross of fees, across 77 months. ## Through every cycle Market-neutral means the book does not need the market to go up. What it needs is fragmentation and volume, and both tend to arrive when markets move, in either direction. | Cycle | What happened | Result | | --------- | --------------------------------------------- | --------------------------------- | | 2018–2019 | Post-peak contraction, thin liquidity | Profitable in every month of 2019 | | 2020 | March dislocation, then recovery | 39.2% | | 2021 | Expansion, peak fragmentation across venues | 37.5% | | 2022 | Industry-wide contraction and venue failures | −7.0%, the only negative year | | 2023–2024 | Recovery, tightening spreads, growth in scale | 17.9%, then 27.0% | ![Annual return](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-cace23514d7fb5b081f3a5551760120f5075eec7%2Fannual-returns.svg?alt=media) Positive in six of seven years, including the year the market lost roughly two thirds of its value. The worst full year was −7.0%. ## Scale in the market This is not a small book capturing a rounding error. It is consistently responsible for a measurable share of global spot trading. ![Share of global centralized spot volume](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-67092f2bba23114264420f45c73cb9d9de82bc6f%2Fvolume-share.svg?alt=media) * **0.2% to 0.5%+ of global centralized spot volume**, month after month, rising with volatility. * **14 to 64 basis points of volume on Binance, OKX and Bybit**, and materially higher on regional venues. * **Billions of dollars of stablecoin transfers per month**, rebalancing inventory across venues. ## Operating record For anyone holding a synthetic dollar, the more useful question than return is whether the book absorbs stress. * **Absorbed a redemption of more than 20% of AUM without a liquidity crunch.** No gating, no suspension, no forced unwind at adverse prices. * **Best month +16.4%. Worst month −10.3%**, in May 2022, alongside the industry-wide contraction of that period. The book recovered without gating. ## One team, three capital structures | Period | Structure | Capital | | --------- | ------------------- | ----------------------------------------------------- | | 2018–2021 | Proprietary trading | Own capital, plus lenders at fixed and variable rates | | 2022–2025 | Licensed fund | External investor capital alongside partners' capital | | 2026– | Axis | Protocol-sourced capital via USDx | The 2022 move into a fund structure was a **licensing decision, not a change of strategy**. Same book, same venues, same risk limits, same people. The continuity is the team: the same capital managers, risk managers, quantitative researchers, traders and engineers have run it throughout. ## Methodology Every figure on this page is computed from the monthly return series published on the [2018–2025 Historical Composite](/susdx-the-rewards-vault/how-axis-earns-yield/historical-track-record/long-run-composite), so the record reconciles against itself. * **Return basis.** Gross, before fees. No net-of-fees figure is published, because that requires a stated fee schedule matched to the period and none is reconcilable to this series. * **Period.** July 2018 to December 2024 for the return series. Volume and market-share figures run to July 2025. * **Compounding.** Annual and cumulative figures are compounded from the monthly series, not annualized from a mean. * **Drawdown basis.** Monthly. A monthly figure does not establish the maximum intraday, daily, or position-level loss, and can conceal losses that recovered before month end. * **Realization.** Historical realized results, not simulated, and not a live onchain protocol result. * **Comparability.** Compare against another record only when period, compounding convention, gross-versus-net treatment and risk-free-rate convention all match. ## Read next * [2018–2025 Historical Composite](/susdx-the-rewards-vault/how-axis-earns-yield/historical-track-record/long-run-composite): the full series, month by month. * [Trading Strategy Overview](/susdx-the-rewards-vault/how-axis-earns-yield/trading-strategies): what the book actually does. * [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield): where sUSDx yield comes from today. # 2018–2025 Historical Composite {% hint style="warning" %} **This is prior trading performance, not onchain protocol results.** It is not a track record of USDx or sUSDx and not a forecast of sUSDx yield. {% endhint %} The full month-by-month series behind the [Track Record](/susdx-the-rewards-vault/how-axis-earns-yield/historical-track-record). ![Monthly return by year](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-6599341f45c669ffb40e3486c376c053073a72c3%2Fmonthly-grid.svg?alt=media) 77 months, July 2018 to December 2024. Compounded, this is **360.7% cumulative**. The May 2022 month is shown rather than smoothed. It is the largest monthly loss in the record, it sits inside the industry-wide contraction of that period, and the book recovered without gating or suspending redemptions. ## Basis of every figure * **Return basis.** Gross, before fees. No net-of-fees figure is published, because that requires a stated fee schedule matched to the period and none is reconcilable to this series. * **Observation frequency.** Monthly. Annual and cumulative figures are compounded from these observations, not annualized from a mean. * **Drawdown basis.** Monthly. Does not establish maximum intraday, daily, or position-level loss. * **Realization.** Historical realized results, not simulated, and not a live onchain protocol result. * **Comparability.** Compare against another record only when period, compounding convention, gross-versus-net treatment and risk-free-rate convention all match. ## Capital structure | Segment | Period | Structure | | ------------- | --------- | ----------------------------------------------------- | | Proprietary | 2018–2021 | Own capital plus lenders at fixed and variable rates | | Licensed fund | 2022–2025 | External investor capital alongside partners' capital | | Axis | 2026– | Protocol-sourced capital | The same core team ran the book across all three. The 2022 transition was a licensing decision, not a change of strategy. ## Coverage The monthly series ends December 2024. Trading continued into July 2025 and is reflected in the volume and market-share figures on the [Track Record](/susdx-the-rewards-vault/how-axis-earns-yield/historical-track-record). The intervening months are not published here pending reconciliation to the same basis as the rest of the series, rather than being estimated. ## Read next * [Track Record](/susdx-the-rewards-vault/how-axis-earns-yield/historical-track-record): the record in context. # How Rewards Reach sUSDx ## Rewards are discretionary Staking is a single, atomic step: you deposit USDx into the Axis Rewards Vault (sUSDx) and receive sUSDx in return, at the current exchange rate, with no further action and no cost to begin accruing. From that point your position accrues whatever rewards the protocol chooses to make available in the vault. That last point is the important one. **Rewards are fully discretionary.** They are best understood as *forward-looking*, a signal of what the protocol is willing to pay for capital, a capital cost it elects to bear, rather than a backward-looking pass-through of whatever the reserves happened to earn. What the vault distributes and what the backing earns are **separate and unbundled**: the reserves may grow or contract with little or no direct relationship to the rewards available in the vault at any given time. This is deliberate. The protocol earns from its trading strategy (see [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield)), but the amount it chooses to pay out as rewards is a discretionary capital-cost decision, not a mechanical redistribution of realized yield. A realized strategy result does not change sUSDx accounting on its own, nothing reaches the vault until USDx rewards are actually **funded** to it, and how much is funded is a decision, not a formula. ![Backing assets are deployed into market-neutral strategies, and realized results grow the reserves. That growth goes one of two ways: it stays in the reserves, deepening over-collateralization so the buffer absorbs a bad period, or it is funded into the rewards vault, where it vests linearly and each sUSDx position comes to represent more USDx. The split is a decision, not a formula.](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-c7a9be8b36e41795f4fb05519058253d3f0f6be3%2Freserve-flywheel.svg?alt=media) ## What the vault does and does not do The vault **does not rehypothecate and does not lend out** the USDx staked into it. The staked USDx simply sits in the vault and accrues rewards as they are funded; holding it is what makes a staker eligible for the protocol's incentive reward distributions. Because the stake is not put at risk to generate the reward, unstaking returns **at least the initial stake plus the share of rewards that accrued while you were staked** (subject to the exchange rate and redemption timing described below). By the same separation, the vault **does not bear the cost of reserve losses**. Negative growth in the reserves is not passed through to USDx or sUSDx holders as a clawback against their positions. This is a statement of how the design is intended to behave, not a guarantee of return, the reserves and their risks are described in [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). ## Comparable designs Reward-bearing vaults where a position accrues value in the underlying asset rather than requiring a manual claim are an established DeFi pattern, see, for example, [Yearn](https://yearn.fi) and [Centrifuge](https://centrifuge.io). ## Three different quantities Because payout is discretionary and unbundled from strategy results, it helps to keep three quantities distinct: | Quantity | Meaning | Included in sUSDx accounting? | | ------------------------ | ----------------------------------------------------------------------------- | ----------------------------- | | Expected strategy return | What a trade or asset is projected to earn | No | | Realized strategy return | What remains after execution, financing, settlement, and valuation or closing | Not by itself | | Distributed vault reward | USDx delivered to the vault and accepted for vesting | Yes | Only the last row moves the vault. An expected opportunity, or even a realized strategy result, does not change sUSDx accounting until USDx rewards are funded to the vault. ## How a funded reward reaches the vault Rewards are delivered to the vault as USDx by the reward manager, which calls `fundRewards` under `REWARD_MANAGER_ROLE`. A funded reward does **not** hit the exchange rate all at once: it **vests linearly** over a configured window, and only the vested portion counts toward vault assets. As rewards vest, each sUSDx comes to represent more USDx and the exchange rate rises smoothly rather than jumping on each funding, so a large deposit cannot front-run a reward and capture it instantly. Your sUSDx balance never changes; each token simply comes to represent more USDx. By design the vesting mechanism only feeds **positive or flat** amounts into the exchange rate, so the intended behaviour is for the USDx-per-sUSDx rate to rise or hold steady rather than step down on each funding. That describes how vesting is built; it is not a promise that the rate cannot fall, that funding will continue, or that USDx's market price is protected. This mechanism determines only how a delivered reward is recognized. It does not verify the strategy's offchain positions, guarantee future transfers, or protect USDx's market price. For the vault mechanics, see [What is sUSDx?](/susdx-the-rewards-vault/susdx). ## Why a quoted APY can differ A strategy estimate, a realized strategy report, and an sUSDx holder result can differ because of costs, timing, reward delivery, vesting, entry and exit time, USDx price changes, and redemption timing (cooldown and servicing). # Stake & Unstake USDx Stake USDx to earn yield, then request redemption and claim to withdraw. {% hint style="info" %} This is a **How-to Guide**. For background on the staking design, see [Architecture](/technical-and-architecture/architecture). For complete function signatures, see [Staking Contracts Reference](/reference/staking-contracts). {% endhint %} **Where does the yield come from?** Staking rewards are not an unexplained deposit. The collateral backing USDx is deployed into strategies whose 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. Realized results are delivered to the vault as USDx rewards and accrue to sUSDx holders. See [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield) for the source and [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency) for the proof surface. **How staking works.** Staking is a direct interaction with a **permissionless** smart contract: you deposit **USDx and receive sUSDx**, the receipt token for your staked position. sUSDx follows **ERC-7540**, an extension of **ERC-4626** that adds **asynchronous redemption**, a pattern also used by protocols such as Centrifuge. To unstake, redemptions pass through an **unstaking / redemption queue** whose parameters, the minimum staking period and cooldown, are set by **policy controlled by governance**. **Lifecycle:** (1) The user deposits USDx into `StakedUSDx` and receives sUSDx shares. (2) The reward manager funds USDx rewards (`fundRewards`); rewards vest linearly over a configured window, so the share exchange rate rises smoothly as vested rewards accrue. (3) To exit, redemption is asynchronous (modeled on ERC-7540): the user calls `requestRedeem` (which burns shares and opens a request), waits the cooldown, the protocol services the request, and the user claims USDx with `withdraw`/`redeem`. A still-pending request can be cancelled. *** ## How to Stake USDx Staking deposits USDx into the vault and returns `sUSDx` shares that appreciate as vested rewards accrue. ### Prerequisites * User must hold USDx * User must approve `StakedUSDx` to spend their USDx * The vault must not have deposits paused (`depositPaused`) * The sUSDx receiver must not carry a restriction that blocks the `DEPOSIT` action (see [Restrictions](#how-restrictions-affect-staking)) ### Deposit by Asset Amount ```solidity // 1. Approve usdx.approve(address(stakedUSDx), amount); // 2. Deposit 1000 USDx, receive sUSDx shares uint256 shares = stakedUSDx.deposit(1000e18, receiverAddress); ``` ### Deposit by Share Amount ```solidity // Mint exactly 1000 sUSDx shares (costs variable USDx) uint256 assetsSpent = stakedUSDx.mint(1000e18, receiverAddress); ``` ### Preview Functions ```solidity // How many shares for 1000 USDx? uint256 shares = stakedUSDx.previewDeposit(1000e18); // How much USDx for 1000 sUSDx? uint256 assets = stakedUSDx.previewMint(1000e18); // Current exchange rate (18 decimals, WAD) uint256 rate = stakedUSDx.exchangeRate(); // Example: 1.05e18 means 1 sUSDx = 1.05 USDx ``` Note: `previewWithdraw`/`previewRedeem` are disabled on the vault because redemption is asynchronous and share-exact, quote a claim from the serviced request, not from a preview. ### Using cast ```bash # Approve $ cast send $USDX "approve(address,uint256)" $STAKED_USDX 1000000000000000000000 \ --private-key $USER_KEY # Deposit $ cast send $STAKED_USDX "deposit(uint256,address)" 1000000000000000000000 $USER_ADDRESS \ --private-key $USER_KEY ``` ### Blocked Conditions | Condition | Cause | | ------------------- | ---------------------------------------------------------------------- | | Deposits paused | The vault has `depositPaused` set | | Receiver restricted | The sUSDx receiver carries a restriction blocking the `DEPOSIT` action | *** ## How to Redeem (Async, ERC-7540) V2 redemption is asynchronous: you open a request, it enters a cooldown (currently **7 days**) and is serviced by the protocol, then you claim. There is no cooldown silo, reserved assets stay inside the vault as tracked liabilities (`pendingRedeemAssets`, then `claimableRedeemAssets`). {% hint style="warning" %} Once you `requestRedeem`, the shares are burned and the reserved USDx is moved out of the vault's active assets into a pending-redemption liability. It earns no further rewards while the request is pending or claimable. {% endhint %} ### Step 1: Request Redemption ```solidity // Burn `shares` of sUSDx and open a redeem request; returns a requestId uint256 requestId = stakedUSDx.requestRedeem(1000e18, controller, owner); ``` This burns the owner's shares, moves the reserved USDx from active vault assets into `pendingRedeemAssets`, and snapshots the request's cooldown (`eligibleAt = requestedAt + cooldown`). A fully restricted owner or controller cannot open a request; a soft-restricted owner may only redeem to themselves. ### Step 2: Wait for Cooldown, Then Servicing The request becomes eligible after the per-request cooldown (`cooldownDuration`, currently **7 days**, snapshotted at request time). Once eligible. An account holding `REDEMPTION_SERVICER_ROLE` services the redemption queue (`serviceRedemptions`), moving your request from `PENDING` to `CLAIMABLE`, this shifts the reserved assets from `pendingRedeemAssets` into `claimableRedeemAssets`. Servicing is performed by the protocol, not by the user. ```solidity // Reserved for requests still in cooldown / awaiting servicing uint256 pending = stakedUSDx.pendingRedeemAssets(); // Serviced and ready to claim uint256 claimable = stakedUSDx.claimableRedeemAssets(); ``` ### Step 3: Claim Once serviced, claim the underlying USDx with the standard ERC-4626 `withdraw`/`redeem`, which draw against your claimable request: ```solidity // Claim by asset amount uint256 sharesSettled = stakedUSDx.withdraw(1000e18, receiver, controller); // Or claim the full serviced request by share amount uint256 assetsReceived = stakedUSDx.redeem(1000e18, receiver, controller); ``` ### Cancel While Pending A request that is still `PENDING` (not yet serviced) can be cancelled. This releases the reserved assets back to the vault and re-mints the burned shares to the owner: ```solidity stakedUSDx.cancelRedeemRequest(requestId, controller); ``` Cancellation is blocked for fully restricted accounts (shares would return to a frozen holder) and while cancellations are paused. ### Using cast ```bash # Request redemption $ cast send $STAKED_USDX "requestRedeem(uint256,address,address)" \ 1000000000000000000000 $CONTROLLER $OWNER --private-key $USER_KEY # Check liabilities $ cast call $STAKED_USDX "pendingRedeemAssets()(uint256)" $ cast call $STAKED_USDX "claimableRedeemAssets()(uint256)" # Claim after the request is serviced $ cast send $STAKED_USDX "redeem(uint256,address,address)" \ 1000000000000000000000 $RECEIVER $CONTROLLER --private-key $USER_KEY # Cancel a still-pending request $ cast send $STAKED_USDX "cancelRedeemRequest(uint256,address)" \ $REQUEST_ID $CONTROLLER --private-key $USER_KEY ``` *** ## How to Check the Exchange Rate The vault exposes the canonical read: how much USDx each sUSDx position is worth. ```solidity uint256 rate = stakedUSDx.exchangeRate(); ``` ```bash $ cast call $STAKED_USDX "exchangeRate()(uint256)" ``` | Condition | Return Value | | ------------------ | --------------------------------------------------- | | `totalSupply == 0` | `1e18` | | `totalSupply > 0` | `(totalAssets * 1e18) / totalSupply`, floor-rounded | `totalAssets` is `accountedAssets`, active principal plus already-vested rewards. The exchange rate rises mechanically as vested rewards accrue into `accountedAssets`; funded-but-unvested rewards and reserved redemption liabilities are excluded, so a large deposit cannot front-run a reward and a redemption request stops earning once it is reserved. *** ## How Restrictions Affect Staking Staking restrictions are driven by `RESTRICTION_ROLE` (held by the Compliance Safe) through per-subject `restrictionStatus` / `blockedActions` fields on `AccountState`, rather than per-staker role constants. Restrictions are action-specific: * A **soft-restricted** owner may still exit, but only to themselves, `requestRedeem` must send the redemption to the owner's own account. * A **fully restricted** owner or controller cannot open a redeem request at all, and cannot be the recipient of a cancelled request's re-minted shares. Restriction status and the specific blocked actions are readable per subject; see [Access Control](/reference/access-control) for the full model. {% hint style="info" %} Rewards vest linearly over a configured window. The vesting duration and the cooldown length are configured parameters of the deployed contract; the cooldown is currently **7 days**. See [What is sUSDx?](/susdx-the-rewards-vault/susdx) for the design and [Reward Distribution](/susdx-the-rewards-vault/reward-distribution) for how realized results reach the vault. {% endhint %} *** ## Common questions **Do I have to stake to earn rewards?** Yes. USDx by itself earns no rewards; rewards accrue to sUSDx, so you must stake USDx to become eligible. **Why is there a cooldown?** The cooldown, currently **7 days**, helps ensure there is sufficient liquidity from the backing to handle potential redemptions or a contraction in USDx supply. **Can I sell instead of waiting through the queue?** Yes, sUSDx can be sold rather than redeemed through the queue, but liquidity is not guaranteed. **Can I ever owe the protocol?** No. Staking never creates an obligation to the protocol. **What are rewards paid in?** USDx. # Backing, Custody & Transparency Every unit of USDx, the **Axis Dollar**, is backed by a portfolio of assets held by the protocol. Backing does not carry a guarantee, but the objective is to preserve value while generating sustainable revenue across all market conditions. That portfolio is diversified across venues and assets, and its composition is attested cryptographically rather than taken on trust. The strategy pages that follow describe how that revenue is generated; this page describes what backs USDx, where it is held, and how you can evaluate it. USDx originates onchain, but its backing does not stay onchain. USDx is backed by a portfolio of **spot assets** that are held at **centralized liquidity venues** (exchanges and trading venues) rather than in onchain custody. When collateral enters the system it is moved out to these venues, where it backs USDx and supports the trading positions that generate yield. The smart contracts implement issuance and redemption controls, while actual backing at any moment depends on the value, composition, location, liquidity, and hedge status of these offchain assets. The backing portfolio is designed to be relatively stable across most market conditions. It typically holds a large allocation of stablecoins, together with assets that require no hedge to hold, and the remainder in assets that require a hedge, held **delta-neutral**, with an offsetting position that removes directional price exposure. Because a substantial share is stablecoins or otherwise hedged, the portfolio's value is intended to move only modestly as markets move. The system is designed to be **over-collateralized** so that this backing exceeds outstanding USDx; live collateralization is only established by the reserve metrics and Proof of Reserves reporting below, not by this description. Where does the yield come from? Backing assets are deployed into market-neutral strategies whose structural edge is cross-venue and cross-asset fragmentation, a durable 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. The transparency evidence below is what lets you assess that activity for yourself rather than take it on trust. {% hint style="warning" %} Token supply and custody routes do not by themselves establish a live collateralization ratio or Proof of Reserves. Use the transparency dashboard for current reserve metrics and linked reporting, once published. {% endhint %} ## Transparency dashboard Use the [Axis Transparency Dashboard](https://app.axis.to/transparency) to view the latest published dashboard metrics and its linked Proof of Reserves reporting. Dashboard values are time-sensitive. Review their timestamp, methodology, and underlying evidence when assessing offchain backing. ## What happens during minting Minting settles through the **primary market** (`USDxMarket`). An eligible participant signs an order specifying the supported collateral asset, collateral amount, and USDx amount. An authorized operator submits the order. If the contract checks pass, collateral is transferred to registered custody addresses and USDx is minted. The contract verifies the order and route. It does not use an external price oracle to decide whether the collateral's current US-dollar value is sufficient for the USDx amount in that order. Registered custody addresses are the on-ledger entry point, not the final resting place. From there, **custody of the collateral is transferred out to the various exchanges and trading venues** where the backing portfolio is held and the hedging positions are run. This is what it means for the backing to sit offchain: once collateral leaves the contract, assessing it depends on the offchain evidence described below rather than on onchain state alone. ## Custody and counterparty controls Because the backing is held at external venues, Axis manages the risk that this creates rather than assuming it away. **Why the backing sits on-venue.** Executing the strategy requires liquidity to be positioned on the venues themselves, and inventory is rebalanced across venues multiple times per day. The nature and frequency of that activity make it necessary to hold assets on-venue today. Axis does **not** currently use off-exchange settlement or off-exchange custody; the backing sits at the venues rather than in a segregated off-exchange arrangement. This is a deliberate trade-off, on-venue positioning is what makes the strategy executable, at the cost of the venue exposure described in [Venue & Counterparty Risk](/risk/venue-counterparty-risk). **Counterparty and venue selection.** Axis actively manages counterparty and venue risk. It trades only on established, reputable venues, draws on long-standing client relationships with those venues, and applies **counterparty scoring** to assess and monitor exposure to each. **Account whitelisting.** All protocol accounts pass **rigorous, regimented whitelisting policies** before they can be used, as a security and operational control over where assets are permitted to move. ## Independent verification Existence and control of the backing can be verified independently rather than taken on trust. Axis works with **Accountable**, which has **read-only access to the exchange accounts** and can independently **attest the reserves and the accounting methodology** used to value them. Independent verification of this kind lets the existence and control of positions be checked by a third party, alongside the onchain and offchain evidence described on this page. ## What is onchain Users can inspect: * USDx supply and token transfers; * deployed contract code and addresses; * supported-asset and registered-custodian configuration; * privileged roles, configured limits, and contract events; * sUSDx vault assets, shares, exchange rate, and redemption request state (pending and claimable). ## Offchain backing evidence Assessing backing also requires offchain evidence for: * current reserve composition and valuation; * beneficial ownership and availability of custodied assets; * open trading positions, hedge ratios, or unrealized profit and loss; * venue, fund, issuer, or counterparty exposures; * whether every asset can be returned within a particular redemption window; * reconciliation between reserves, liabilities, and USDx supply. Refer to [Audit Reports](/backing-reserves-and-transparency/audits) for the smart contract reviews, their scope, and their published reports. ## How to evaluate transparency Evaluate backing using dated reserve composition, liabilities, custody evidence, hedge exposure, collateralization methodology, attestation scope, and reconciliation frequency. Combine the transparency dashboard with onchain supply and contract data; neither view alone captures the entire offchain backing state. Read [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability) for the economic pathway and [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for offchain dependencies. # Audit Reports Axis publishes three independent smart contract reviews. Audit findings are useful evidence about a defined code snapshot, but an audit is not a warranty and does not cover every offchain strategy, custody, venue, operator, or legal risk. Finding counts on this page are taken from the reports. Use the reports themselves as the authoritative source for exact scope, code revisions, severity definitions, dispositions, and auditor status. ## V2 (current) | Auditor | Reviewed | Revision | Findings | | ------------ | --------- | --------- | --------------------------------------------------------------- | | OpenZeppelin | July 2026 | `6db59ec` | 25 total: 0 critical, 2 high, 7 medium, 13 low, 3 informational | {% file src="/files/ZEYGjb0RxxBSM0OMR35Z" %} Contracts in scope: * `USDx` * `USDxMarket` * `MarketConfig` * `StakedUSDx` * `AxisV2Ids` (shared identifier library, not an upgradeable contract) All four in-scope V2 contracts are upgradeable behind proxies. ## V1 (legacy) The V1 contracts are the deprecating private-beta deployment on Plasma. See [Contract Addresses](/reference/contract-addresses). | Auditor | Reviewed | Revision | Findings | | ---------- | ------------ | --------- | -------------------------------------------------------------- | | Plainshift | January 2026 | `98849c5` | 9 total: 0 critical, 0 high, 1 medium, 3 low, 5 informational | | Zellic | August 2025 | `845d765` | 10 total: 2 critical, 1 high, 4 medium, 3 low, 0 informational | {% file src="/files/tUeOu4PbMFdJW5WK9lwn" %} {% file src="/files/TFAakujx1QC45CwRF3iV" %} Contracts in scope: * `AxisUSD` * `AxisUSDMinting` * `SingleAdminAccessControl` * `StakedAxisUSD` * `StakedAxisUSDV2` * `AxisUSDSilo` * `StakingRewardsDistributor` * `AxisUSDRateProvider` Confirm the scope and revision in each report before assuming a deployed contract was reviewed. ## Scope exclusions The reviews cover defined Solidity code and revisions. Zellic explicitly excludes the front end, infrastructure, and key custody. OpenZeppelin's V2 review states that custodian solvency and physical custody, offchain operator policy and pricing, and reentrancy from non-standard tokens are out of scope, and that there is no onchain oracle: settlement trusts the operator-signed minimum output amount. No report audits strategy execution, exchange solvency, custody operations, performance reporting, or legal structure. ## What not to infer These reports should not be summarized as "no outstanding critical or high findings" without reconciling the base revisions, remediation commits, deployed bytecode, and the dispositions recorded in each report. For the V1 contracts, immutable or non-upgradeable characteristics can reduce one category of upgrade risk, but they do not remove privileged-role, configuration, operator, custody, strategy, or deployment risk. The V2 contracts reviewed by OpenZeppelin are upgradeable behind proxies, so upgrade-authority risk applies to them in addition to the above. For the full onchain trust model, see [Security Overview](/backing-reserves-and-transparency/security) and [Access Control](/reference/access-control). # 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) 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) for how those mechanisms work and [Onchain Safety Properties](/backing-reserves-and-transparency/security/onchain-safety-properties) 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) lists the powers and emergency role. [Access Control](/reference/access-control) 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) for basis, execution, funding, and data failures; * [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for venue assessment and concentration controls; * [Custody & Liquidity Risk](/risk/custody-liquidity-risk) for backing availability, redemption, and withdrawal timing; * [Risk Overview](/risk/risk-overview) 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) for the full treatment and [Venue & Counterparty Risk](/risk/venue-counterparty-risk) 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)). * 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) for the reviewed revisions, reported finding counts, and the reports themselves. # 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) for the properties these mechanisms are intended to preserve. [Protocol Administration](/technical-and-architecture/governance) explains who can change caps, roles, assets, custodians, and cooldown parameters. [Audit Reports](/backing-reserves-and-transparency/audits) records the reviewed revisions and reported findings. # Onchain Safety Properties The properties below describe intended contract invariants. A violation would indicate a defect, misconfiguration, or exploit. They do not make claims about offchain asset value, custody, venue solvency, or strategy execution. These onchain invariants are only one half of the trust model: the protocol minimizes trust where it can, but real trust assumptions remain, notably the centralized liquidity needed to scale, which Axis plans to reduce gradually over time. See [Security Overview](/backing-reserves-and-transparency/security) for those offchain trust assumptions and the roles behind them. ## Accounting formulas | Property | Formula or bound | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | sUSDx exchange rate | `exchangeRate() = totalAssets() / totalSupply()` (WAD ratio, floor-rounded; returns `1e18` when supply is zero) | | Total assets | `accountedAssets`, active principal plus already-vested rewards; excludes reserved redemption liabilities and unvested rewards | | Reward vesting | Rewards vest **linearly over a configured window**: `rewardRate` assets per second until `periodFinish`. The live duration is a configured parameter, not a fixed constant. | | Unvested rewards | `unvestedRewards`, funded rewards not yet dripped into `accountedAssets`; excluded from `totalAssets` and the exchange rate until vested | | Vested rewards | Rewards already checkpointed into `accountedAssets` (for the active tranche, funded amount minus `unvestedRewards`) | | Redemption liabilities | `redeemLiabilities = pendingRedeemAssets + claimableRedeemAssets`, carved out of `accountedAssets` so the same USDx is never counted as both active assets and a claim | | Solvency | `assetBalance ≥ requiredAssets`, where `requiredAssets = accountedAssets + pendingRedeemAssets + claimableRedeemAssets + unvestedRewards` | | Settlement capacity | Each settled order stays within its configured per-scope caps (`CapConfig` over `GLOBAL` / `ASSET` / `ROUTE` / `ACCOUNT` / `CHANNEL`) | | Route and channel binding | A settled order matches an enabled `route` and an approved `channel` whose custodian is allowlisted | Solidity integer division rounds down, which is why the reward and share-conversion calculations above floor-round: `convertToAssets` / `convertToShares` are computed against `accountedAssets` with floor rounding, and `previewWithdraw` / `previewRedeem` revert because redemption claims are asynchronous and share-exact. Vault rewards originate offchain, Axis's structural edge in cross-venue and cross-asset fragmentation, and are funded to the vault as USDx via `fundRewards`; see [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield). These onchain invariants govern how funded rewards vest and how the exchange rate moves, not whether returns are generated. ## USDx and minting * Only `MARKET_ROLE` can create USDx, and that role is held by the `USDxMarket` contract, so issuance is only reachable through approved, settled primary market orders, never open user actions. * Root admin authority (`DEFAULT_ADMIN_ROLE`) is intended to sit with the **governance Safe (multisig)** rather than a hot EOA, a deployment/configuration choice verifiable onchain, not enforced by the contract. **Contract upgrades are governed by a separate `TimelockController`**, the owner of each `ProxyAdmin`, so proxy upgrades pass through a timelock delay (set on the `TimelockController`, verifiable onchain), whereas the governance Safe's non-upgrade admin actions are direct and not behind the timelock. The V2 contracts use stock OpenZeppelin `AccessControlUpgradeable` with no `renounceRole` override, so role management follows default OZ semantics: an account can renounce its own roles, including `DEFAULT_ADMIN_ROLE`. There is no onchain guarantee that admin authority cannot be renounced. * Each nonce is single-use per `accountId`, must be non-zero, and is consumed only on successful settlement; an order past its `deadline` cannot settle. * Orders require valid authorization, a direct EIP-712 signature, an accepted delegated signer, or ERC-1271 smart-account validation, and settle only on their declared side (`OrderSide.MINT` or `REDEEM`). * Every settled order stays within its configured per-scope capacity caps; a failed settlement consumes neither the nonce nor the capacity, so a rejected order can be safely retried. * A settled order binds an enabled `route` and an approved `channel`, and the channel's `custodian` is on the allowlist (`isCustodian`). * `EMERGENCY_ROLE` is risk-**down** only: it can pause capacity, disable mint/redeem, and remove hot market roles, but it cannot grant roles, increase risk, or upgrade. ## Rewards vault * The sUSDx exchange rate can only increase over time as rewards vest, excluding rounding. * Deposits are **synchronous** ERC-4626 entries priced at the exchange rate at execution; redemptions are **asynchronous** (ERC-7540) and settle through the redemption queue, not at deposit time. * Rewards vest linearly over a configured window (`rewardRate` until `periodFinish`); the live value is a configured parameter of the deployed contract. A `fundRewards` top-up folds into the *active* vesting window rather than resetting the clock, and is bounded by an optional `maxRewardRate` cap. * Restriction status is enforced per action via a blocked-actions model (`RESTRICTION_ROLE`). A fully restricted owner or controller cannot open a redeem request; a soft-restricted owner may open a request only to exit to itself. Ordinary ERC-20 allowance operations are not blocked by restriction status alone. * Redemption liabilities live **inside the vault** as `pendingRedeemAssets` and `claimableRedeemAssets` buckets. There is no separate escrow contract. Reserved amounts are carved out of `accountedAssets`, so they accrue no further rewards and cannot dilute active holders. * A pending redeem request can be cancelled (`cancelRedeemRequest`), which releases its reserved assets back to `accountedAssets` and re-mints the burned shares to the owner; cancellation is blocked for fully restricted accounts and while cancellations are paused. ## Redemption queue and rewards * Async redemption follows ERC-7540: `requestRedeem` burns the owner's shares and moves assets from `accountedAssets` into `pendingRedeemAssets`, snapshotting `eligibleAt = requestedAt + policy.cooldown` per request (later cooldown changes affect only future requests). * Only `REDEMPTION_SERVICER_ROLE` can service the queue: `serviceRedemptions` scans `PENDING` requests in request-id order within a bounded per-call scan and moves eligible ones to `CLAIMABLE`, shifting reserved assets from the pending to the claimable bucket. Ineligible requests are skipped, but a forward-progress guarantee ensures the first eligible request always advances. * A controller claims the underlying USDx only after its request is `CLAIMABLE`; a submitted request is never treated as claimed until serviced. * Only `REWARD_MANAGER_ROLE` can fund rewards (`fundRewards`), and funding cannot exceed configured reward bounds. * Solvency holds continuously: `assetBalance ≥ requiredAssets`, where `requiredAssets` covers active shares, both reserved redemption buckets, and unvested rewards, so servicing and claims can never spend principal or rewards twice. * Upgrades are owner-gated through a **`TimelockController`** (the `ProxyAdmin` owner) over `TransparentUpgradeableProxy` (no implementation self-upgrades). An upgrade must pass a timelock delay before it can execute; the delay is set on the `TimelockController` and is verifiable onchain. This upgrade authority is distinct from `DEFAULT_ADMIN_ROLE`, which is held by the governance Safe and is not behind the timelock. Role authority itself follows stock OpenZeppelin `AccessControlUpgradeable`, the contracts add no `renounceRole` override, so there is no onchain guarantee that authority over these system contracts cannot be renounced. See [Smart Contract Protections](/backing-reserves-and-transparency/security/smart-contract-protections) for the mechanisms behind these properties, the [Protocol Taxonomy](/usdx-the-synthetic-dollar/usdx) for canonical symbol definitions, and [Core Contracts Reference](/reference/core-contracts) or [Staking Contracts Reference](/reference/staking-contracts) for function-level detail. # Risk Overview Axis combines smart contracts with offchain custody, operators, trading venues, and strategy execution. No single control removes all of these dependencies, and losses or delays are possible. {% hint style="danger" %} USDx can trade below its target, redemption can be delayed or unavailable, strategy activity can lose money, and smart contracts or operational systems can fail. Do not treat USDx or sUSDx as cash, an insured deposit, or a guaranteed-return product. {% endhint %} ## Where the yield comes from sUSDx earns yield from Axis's structural edge in cross-venue and cross-asset fragmentation, a durable, market-neutral yield source that does not rely on any single mechanism: the strategy captures spreads between related assets and across venues. Funding is one component (and can be the larger share in a given period); see the Transparency Dashboard for current attribution. That is also where most of the risk sits. Capturing those spreads means holding positions across venues and counterparties, and the market, execution, venue, and custody risks below all flow from that activity. ## Principal risks The risks below are grouped by where they originate. Within each group the first row is the one that matters most. **Counterparty and custody.** Where Axis depends on someone else holding or honouring something. This is the largest category of risk in the design, because the backing does not stay onchain. | Risk | What can happen | Who is exposed | | -------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------- | | **Venue and counterparty** | A venue or counterparty can halt, default, restrict withdrawals, or fail operationally | Assets or positions held there | | **Custody** | Assets held outside the contracts can be lost, frozen, delayed, or mismanaged | USDx backing and operations | | **Fund and issuer** | A money-market fund, issuer, or instrument can lose value, restrict liquidity, or fail operationally | Collateral-yield assets and strategy capital | **Market and execution.** Where the strategy itself can lose money. | Risk | What can happen | Who is exposed | | -------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------ | | **Market and basis** | Related assets can diverge instead of converge; a spread can widen and a hedge can be imperfect | Strategy capital and, ultimately, protocol users | | **Execution** | Slippage, partial fills, latency, or failed orders can reduce or reverse an expected spread | Strategy capital | | **Collateral** | A supported asset can lose value or liquidity | Minting, redemption, and backing quality | **Liquidity and exit.** Where you may not be able to get out at the price or on the timeline you expect. | Risk | What can happen | Who is exposed | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------- | | **Liquidity and depeg** | USDx can trade away from $1; exits may be expensive, limited, or delayed | USDx and sUSDx holders | | **Redemption delay** | sUSDx exits are asynchronous: a request goes through a 7-day cooldown, then servicing, then a claim, and the reserved assets stop earning vault rewards once redemption is requested | sUSDx holders | **Protocol and administration.** Where the system itself, or the people who control it, can fail. | Risk | What can happen | Who is exposed | | ---------------------- | ------------------------------------------------------------------------------ | --------------------------------------------- | | **Admin and operator** | Privileged keys can be compromised, unavailable, or misused | Issuance, redemption, staking, and parameters | | **Smart contract** | A bug, exploit, integration error, or unexpected token behavior can cause loss | Onchain users and protocol assets | **External.** | Risk | What can happen | Who is exposed | | -------------- | ----------------------------------------------------------------- | ----------------------------- | | **Regulatory** | Access, transfers, custody, or venue operations may be restricted | Users and protocol operations | ## Risks compound These risks are not independent. For example, a venue failure can create an unhedged market position, make collateral unavailable, reduce confidence in redemption, and contribute to a USDx discount at the same time. ## USDx and sUSDx have different exposure USDx holders are exposed to the price-stability, collateral, custody, redemption, and operational system. sUSDx holders retain those risks and also depend on the vault, reward funding, and the asynchronous redemption process. ## Controls reduce risk; they do not eliminate it Axis contracts include signature validation, role separation, multi-scope capacity limits, a risk-down emergency pause authority, asynchronous (ERC-7540) redemption with a cooldown, and published audit reports. These measures can constrain specific failures. They cannot guarantee the value or availability of offchain assets, correct trading execution, continuous liquidity, or a fixed return. Axis does not operate a reserve fund. The backing is instead designed to be over-collateralized against a target over-collateralization level, so that drawdowns, negative reserve growth, and reserve contractions are intended to be absorbed by that buffer rather than passed straight through to holders. This is a design intent sized against reserves, not a guarantee; a large enough loss can exceed the buffer. See [How Axis Manages Risk](/risk/risk-management). Read [How Axis Manages Risk](/risk/risk-management) for the control layers, [Asset Selection](/risk/asset-selection) and [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for the offchain frameworks, [Custody & Liquidity Risk](/risk/custody-liquidity-risk) for asset availability and exit constraints, and [Security Overview](/backing-reserves-and-transparency/security) for contract-level details. # 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), 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), [Venue & Counterparty Risk](/risk/venue-counterparty-risk), and [Market & Trading Risk](/risk/market-trading-risk). ## 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) 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), [Access Control](/reference/access-control), and the [Risk Overview](/risk/risk-overview). # Asset Selection Framework Axis's asset-selection framework defines three fail-closed gates. A candidate must satisfy all three before it is eligible for strategy use; missing, inconsistent, or failed evidence keeps it out of the eligible set. See the full risk control policy: {% file src="/files/XUB4Sl6MyHteUaCxYfMq" %} ![Asset selection framework: a candidate asset must pass readiness, economics, and risk-clearance gates. Passing all three makes it eligible for strategy review; a failed or missing check excludes it.](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-b3180f8287a6711c86c8bbce35cefa7be848d643%2Fasset-selection-framework.svg?alt=media) **Fail-closed rule:** failed or missing evidence at any gate means the asset is excluded. | Gate | Public decision question | If evidence fails | | ------------ | ------------------------------------------------------------------------------------------------------------- | --------------------------- | | 1. Readiness | Can the asset be identified, traded, hedged, transferred and monitored through supported systems? | Exclude the asset | | 2. Economics | Is liquidity observable across venues, and can the opportunity plausibly survive funding and execution costs? | Exclude the asset | | 3. Clearance | Are integrity, structural, compliance, concentration and operational risks within the approved framework? | Exclude or remove the asset | ## Gate 1: Market, hedge, and operational readiness The first gate asks whether the asset has observable multi-venue liquidity, a workable hedge, reliable data and automated monitoring inputs, and operational support for trading and transfers. Identity and compliance checks for relevant counterparties or venues are also part of readiness. ## Gate 2: Liquidity and funding economics The second gate tests whether documented volume, order-book conditions, funding behavior, and expected execution economics can support the intended trade. A visible spread is not enough if it cannot be captured after costs and market impact. ## Gate 3: Exclusion conditions The final gate checks for conditions that should block or remove an asset, including integrity, liquidity, hedge, compliance, or operational failures. Exclusion is fail-closed: the strategy does not rely on an unresolved exception being harmless. ## Evidence and ongoing checks The framework considers evidence such as: * liquidity across more than one venue; * documented volume and funding behavior; * an identified hedge and monitoring path; * KYC or equivalent counterparty onboarding where applicable; * controlled asset-transfer procedures; * data and market-integrity checks; * automated signals that can identify deteriorating conditions. Internal thresholds, alert levels, and escalation triggers can change with market conditions. ## Residual risk An asset can pass every gate and still fail later. Liquidity can disappear simultaneously across venues, the hedge relationship can break, data can become stale, transfers can be blocked, or an issuer, venue, or counterparty can fail. Ongoing monitoring and the ability to exclude an asset reduce exposure but cannot eliminate loss. # Venue & Counterparty Risk Cross-venue arbitrage and other market-neutral strategies depend on venues and counterparties remaining available, solvent, liquid, and operational. Axis's venue-risk framework combines a tiered eligible universe, concentration constraints, continuous monitoring, and staged de-risking. See the full risk control policy: {% file src="/files/WIUsRmi0VDYYv0ePMupb" %} ## Direct venue exposure and exchange failure Exchange failure is a real and possible risk. Axis is transparent that its assets are **directly deposited on the venues themselves**, to run the strategy, liquidity has to sit on-venue rather than in a segregated off-exchange arrangement (see [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency)). If a venue becomes insolvent or freezes withdrawals, the assets held there are exposed. The nature of the strategy does, however, give Axis an unusually close view of its counterparties. Because trading requires **constant deposits and withdrawals**, Axis continuously tests and monitors each venue's withdrawal performance, liquidity, and solvency in the ordinary course of operating, not only through periodic reviews. That flow-level visibility feeds **strict per-venue exposure limits** set through a diligence, counterparty-risk-management, and risk-budgeting process, with continuous monitoring of how capital moves in and out. This continuous monitoring and the strict exposure limits are intended to **reduce** the probability and impact of a venue failure, they cannot eliminate it. Axis does not claim to always be first out of a failing venue, and managing a sudden, total exchange failure is inherently limited: withdrawals can stop without warning, and a large loss at a venue can exceed what monitoring or diversification can protect against. ## Control lifecycle 1. **Assess evidence.** Review security, regulatory status, financial health, reserve evidence, liquidity, operating history, and counterparty protections. 2. **Classify risk.** Assign a venue grade based on the evidence and relative risk. 3. **Apply limits.** Use the grade to determine eligibility and the maximum venue allocation. 4. **Monitor continuously.** Track withdrawal health, access changes, financial distress, liquidity, and operational incidents. 5. **Respond.** Reassess stable venues and reduce or exit exposure when conditions deteriorate. 6. **Reclassify before reuse.** Require a fresh risk decision before returning capital to a venue that was reduced or exited. ## Eligible, monitored, and active venues The venue framework distinguishes a broader classified universe, venues under operational monitoring, and a smaller active set. These categories are not interchangeable: classification does not mean capital is deployed, and monitoring does not mean a live position. ## Eligibility and concentration Venues are grouped into risk tiers that inform eligibility and concentration. The framework is intended to prevent venue selection from being based on yield alone and to limit the effect of any single failure. ### Grade-based venue caps A venue's grade sets the ceiling on how much of total AUM may be allocated to it. The caps are tiered by grade, the stronger the grade, the higher the permitted allocation: * **Grade A** carries the highest per-venue cap. Strongest security, regulatory, custody, reserve, liquidity, and operating profile. * **Grade B** carries a lower cap than Grade A. Strong liquidity and operations with additional compliance or concentration considerations. * **Grade C** carries a materially lower cap, with strategy-specific eligibility and enhanced monitoring for historical, regulatory, or concentration risks. * **Grade D** carries a minimal cap, used only where regulatory transparency or operating history is limited. These are per-venue maximums based on grade; the framework does not define a separate aggregate cap for all venues within the same grade. Most capital is intended for Grade A and B venues, while Grade C and D venues carry minimal exposure. New minting or rebalancing can temporarily move an allocation above its cap. The specific cap levels are illustrative internal targets rather than a published commitment. Venue grades, allocation caps, and operational limits can change as conditions change. ## Monitoring The venue-risk framework calls for continuous monitoring of: * withdrawal performance and transfer availability; * regulatory or access changes; * solvency and financial-distress indicators; * liquidity and market integrity; * operational incidents and abnormal venue behavior. The framework calls for KYC or equivalent onboarding of relevant venues and counterparties. ## De-risking and exit When risk deteriorates, the framework calls for staged de-risking and exit rather than assuming an immediate all-at-once withdrawal is always possible. ## Residual risk Monitoring can detect warning signs but cannot guarantee enough time to exit. Withdrawals can stop without notice, liabilities can be hidden, legal action can be sudden, and multiple venues can fail together. Diversification reduces concentration; it does not transform venue exposure into risk-free custody. # Market & Trading Risk Axis earns yield by capturing basis dislocations that open up across trading venues and across related assets, **its structural edge is cross-venue and cross-asset fragmentation**, a durable, market-neutral yield source that does not rely on any single mechanism, while offsetting directional exposure so the position is not a bet on price direction. Funding is one component (and can be the larger share in a given period); see the Transparency Dashboard for current attribution. Market-neutral arbitrage, capturing price differences while hedging out market direction, is an established institutional trading strategy, not a crypto invention. Its core risk is that the two sides do not behave or execute as expected: the fragmentation that produces the spread can narrow, fail to converge, or move against the position before it is realized. ## Main failure modes ### Basis risk The dislocation between the two legs, the same or related exposure priced differently across venues or assets, can widen, persist, or structurally change instead of converging. Because the return comes from these fragmentation spreads closing, a basis that stays open or inverts is a direct drag on realized yield. ### Execution risk One leg can fill before the other, fill only partially, or execute with more slippage than expected. Latency and failed orders can leave temporary directional exposure. Capturing a cross-venue spread means acting on two or more venues at once, so any leg that lags erodes or reverses the spread the trade was meant to lock in. ### Liquidity risk Displayed liquidity can disappear under stress. A position that appears small relative to normal volume can become expensive or impossible to close when many participants seek the same exit. Fragmentation across venues also means depth is split, so the liquidity available to unwind a leg can be thinner than aggregate figures suggest. ### Financing and carry cost risk Funding rates, borrow costs, fees, and rebates can change while a position is open. These are costs carried against the fragmentation spread, not the source of the return, but they still matter: a positive quoted spread can become negative after realized costs. Because the durable edge is fragmentation across venues and assets rather than any single mechanism, adverse funding is a cost to be managed rather than a collapse of the yield engine. ### Model and data risk Price, volume, funding, and venue data can be delayed, wrong, or incomplete. Automated signals can act on a bad input or fail to capture a regime change, including one where cross-venue and cross-asset relationships that normally hold break down. ## Control layers The risk framework calls for: * pre-trade liquidity and spread analysis across the relevant venues and assets; * identified hedge instruments and multi-venue liquidity; * automated monitoring drivers and integrity checks; * documented volume and spread evidence; * controlled transfer operations; * asset and venue exclusion when required evidence fails; * staged reduction or exit as conditions deteriorate. The exact risk limits and triggers are not public. A control framework can lower the probability or impact of a failure, but it cannot ensure that every hedge remains available or that every exit completes at the expected price. ## What delta-neutral means here Offsetting delta reduces exposure to a broad directional move at a point in time. Delta can change, and the position remains exposed to basis, liquidity, execution, financing, venue, counterparty, and operational risks. The return is earned from fragmentation spreads converging, not from price going a particular direction, and "delta-neutral" should never be read as "lossless." # Custody & Liquidity Risk USDx depends on assets and operations outside the token contracts. Backing assets sit on the trading venues where the strategy runs, while secondary-market liquidity depends on external venues. Onchain controls cannot guarantee that those assets remain available or that USDx can always be exited near $1. ## Custody and collateral The primary market (`USDxMarket`) settles a mint order by routing collateral to a registered custody channel before USDx is minted. Because the strategy requires liquidity positioned on the venues themselves, the backing is held **on-venue** at trading venues; Axis does **not** currently use off-exchange settlement or off-exchange custody (see [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency)). Safety then depends on key management, legal access, operational processes, and each venue's continued availability and solvency, the venue exposure covered in [Venue & Counterparty Risk](/risk/venue-counterparty-risk). A supported collateral asset can also lose value, liquidity, or redemption access. An approved route and channel prove that the contract accepted a settlement path; they do not prove the real-time value or availability of assets held there. The backing is designed to be **over-collateralized** against a target level, so that reserve contractions are intended to be absorbed by that buffer rather than passed straight through to holders, a design intent sized against reserves, not a reserve fund and not a guarantee. What can and cannot be independently verified about this backing is documented separately in [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency). ## USDx liquidity and redemption USDx can trade above or below its $1 target. Secondary-market liquidity can disappear or become expensive during stress. The mint and redemption path can support price alignment, but it relies on authorized operators, available collateral, custody access, and configured capacity limits. Those dependencies can delay or constrain exits. The protocol does not guarantee continuous AMM liquidity or an immediate $1 redemption for every holder. ## sUSDx redemption timing sUSDx adds vault and redemption-process risk. Redeeming sUSDx is **asynchronous** (modeled on ERC-7540), not instant. The cooldown is currently **7 days**. When you `requestRedeem`, the vault burns your sUSDx and moves the corresponding USDx out of active vault assets (`accountedAssets`) into a reserved **pending** liability, where it earns no further vault rewards. The cooldown lives inside the vault as pending and claimable liabilities. There is no separate cooldown-escrow (silo) contract. Once the cooldown elapses, the request must be **serviced** (an account holding the redemption-servicer role marks it claimable), which shifts the reserved USDx from the pending bucket to the **claimable** bucket. Only then can you claim the underlying USDx. A request can be **cancelled while it is still pending**, which restores the burned shares. So exit is not immediate: servicing depends on an operator acting, and the USDx price and market conditions can change between request and claim. Reserved pending and claimable assets are tracked as vault liabilities, but the vault must actually hold enough USDx to honor them. Vault rewards themselves come from Axis's trading results, a market-neutral yield whose structural edge is cross-venue and cross-asset fragmentation, a durable 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. A period with weak or undelivered results simply produces no new rewards, and reward delivery is not guaranteed. See [What is sUSDx?](/susdx-the-rewards-vault/susdx) for the full lifecycle. ## Risks can compound A custodian or venue failure can make assets unavailable, leave a hedge incomplete, reduce redemption capacity, and weaken confidence in USDx at the same time. Diversification and limits can reduce concentration, but they cannot guarantee access during a correlated event. Read [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency) for what can and cannot be independently verified, [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability) for the price-stability path, and [Venue & Counterparty Risk](/risk/venue-counterparty-risk) for venue controls. # System Architecture Design of the Axis smart contract system: how components relate, how funds flow, and how access control works. For design rationale, see [Design Decisions](/technical-and-architecture/design-decisions). For step-by-step integration instructions, see [Guides](/usdx-the-synthetic-dollar/mint-and-redeem). For function signatures, see [Reference](/reference/core-contracts). Every contract symbol on this page traces back to the [Protocol Taxonomy](/reference/core-contracts) as the single source of truth. ## Onchain and offchain components The system splits into two halves. The **onchain** component is the smart contracts described on this page, the `USDx` token, the `USDxMarket` primary market, and the `StakedUSDx` vault, which govern issuance, redemption, and staking. The **offchain** component is everything else: the trading strategy, order execution, custody and settlement operations, and risk management that stand behind the backing. This page covers the onchain contracts; the offchain side is described in [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency) and the Risk section. Every deployed contract is source-verified onchain, so the source can be read directly from the block explorer using the addresses in [Contract Addresses](/reference/contract-addresses). ![Four deployed V2 contracts and the two authorities over them. MarketConfig holds the parameters USDxMarket enforces, USDxMarket is the only holder of MARKET\_ROLE on USDx, and StakedUSDx takes USDx as its underlying asset. A governance Safe is admin over all four, while a separate TimelockController owns the ProxyAdmin so upgrades pass a delay.](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-165d3d148095c6d811ab99890f192cf3ba7c00da%2Fcontract-relationships.svg?alt=media) ## Three-layer design The protocol separates into three layers: **Dollar layer**, `USDx` * Upgradeable ERC-20 synthetic dollar (with `ERC20Permit`); supply is role-gated so only the primary market may mint. **Market layer**, `USDxMarket` * Collateral intake and the mint/redeem lifecycle, settled from signed EIP-712 orders against approved routes, channels, and capacity. **Rewards layer**, `StakedUSDx` (share symbol `sUSDx`) * ERC-4626 vault whose underlying asset is USDx, with an asynchronous ERC-7540 redemption lifecycle. * Rewards are funded directly into the vault via `fundRewards` (held under `REWARD_MANAGER_ROLE`). There is no separate rewards-distributor contract. * Redemption liabilities live inside the vault as `pendingRedeemAssets` / `claimableRedeemAssets`. There is no separate cooldown-escrow (silo) contract. * `exchangeRate()` is a read-only view (USDx assets per share) that external integrations can observe directly on the vault. The contract boundaries limit the direct capabilities of each layer. They do not make the layers economically independent: both the market and the rewards vault depend on USDx, and privileged-role or token failures can affect the system across contract boundaries. ## Contract model and upgradeability Every V2 contract sits behind a `TransparentUpgradeableProxy` with a `ProxyAdmin`; there is no UUPS self-upgrade path in the implementations. Authority uses OpenZeppelin `AccessControlUpgradeable` (`IGovernedAccessControl`) across `USDx`, `USDxMarket`, and `StakedUSDx`. | Contract | Shape | | ------------ | ------------------------------------------------------------------------------------------------- | | `USDx` | Upgradeable ERC-20 (`ERC20Permit`), role-gated mint/burn, bridge, pause, and restriction controls | | `USDxMarket` | EIP-712 order settlement over approved routes/channels; single supply authority on the token | | `StakedUSDx` | ERC-4626 vault + ERC-7540 async redemption; its own ERC-7575 share token (`sUSDx`) | `DEFAULT_ADMIN_ROLE` (admin over every other role) is held by a **geographically-distributed governance Safe (multisig)**, never a hot EOA. **Contract upgrades are governed separately by a `TimelockController`**, the owner of each `ProxyAdmin`, so 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** behind the timelock: risk-**down** changes (pause, cap decrease, restrict) execute immediately via the guardian roles; non-upgrade risk-**up** changes (cap increase, add a route/custodian/asset) require a deliberate direct action by the Safe, which acts seldom; upgrading an implementation additionally passes through the timelock. Granting **and** revoking roles are both gated by `DEFAULT_ADMIN_ROLE`, there is no custom revoke path or `_setRoleAdmin` override, so only the governance Safe can add or remove a role. ## Fund flow ![Minting runs through the primary market: a signed order, an operator settlement against routes and caps, then USDx. The collateral does not stay onchain, it moves out to custody and trading venues. Leaving the rewards vault is asynchronous in four steps: requestRedeem burns the position and reserves the USDx, a cooldown elapses during which the reserved amount earns nothing, a servicer marks the request claimable, and only then does the holder claim.](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-04ebd13c5df45addb368abd682cd0144c196a937%2Fsystem-flow.svg?alt=media) | Path | Trigger | Flow | Outcome | | ---------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------------- | --------------------------------- | | **Mint** | Eligible party signs an EIP-712 mint order | Collateral → custody, USDx → user | User receives USDx | | **Stake** | User deposits USDx | USDx → vault, sUSDx → user | Shares appreciate as rewards vest | | **Redeem** | Eligible party signs an EIP-712 redeem order | USDx burned, collateral → user | User receives collateral | | **Request redemption** | Staker calls `requestRedeem` | Shares burned, assets reserved as `pendingRedeemAssets`; after cooldown + servicing, claimed as USDx | Asynchronous exit from the vault | The value that makes sUSDx positions appreciate comes from Axis's trading engine, whose 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. Realized results are delivered to the vault as USDx rewards. See [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield). {% hint style="warning" %} **Edge case: emergency halt.** An `EMERGENCY_ROLE` holder can pause capacity and disable the mint/redeem paths on the market; token and vault flows can additionally be paused under `PAUSER_ROLE`. These are risk-down authorities only, they cannot grant roles, raise caps, or re-enable expanded operations, which requires a deliberate action by the admin multisig. {% endhint %} ### Mint path 1. An eligible party signs an EIP-712 order binding `accountId`, `routeId`, `channelId`, side, input/output assets and amounts, `deadline`, `nonce`, and `termsHash`. 2. An operator with `MINT_OPERATOR_ROLE` submits it to `USDxMarket.settle`. 3. The market re-runs every pre-trade check (eligibility, route/channel, capacity, signature, nonce), routes collateral to registered custody, and mints USDx to the beneficiary. Supply authority on the token is `MARKET_ROLE`, held only by `USDxMarket`. ### Redeem path 1. An eligible party signs a redeem order. 2. An operator with `REDEEM_OPERATOR_ROLE` submits it for settlement. 3. The market burns the user's USDx (spending an approval) and transfers collateral to the beneficiary. A failed settlement consumes neither the nonce nor the order, so a rejected order can be safely retried. ### Staking and redemption path 1. A user deposits USDx into `StakedUSDx` and receives `sUSDx` shares immediately, priced at the current exchange rate. 2. The reward manager calls `fundRewards` (`REWARD_MANAGER_ROLE`) to add realized yield to the vault. 3. Rewards vest linearly over a configured window; only the vested portion counts toward vault assets, so `exchangeRate()` rises smoothly rather than jumping on each funding. 4. To exit, the staker calls `requestRedeem`, which burns the shares and opens a request subject to a per-policy cooldown. Once eligible, an account with `REDEMPTION_SERVICER_ROLE` calls `serviceRedemptions` to mark it claimable, after which the staker claims (withdraws) the underlying USDx. A still-pending request can be cancelled, which restores the burned shares. ## Access-control model All three V2 contracts use OpenZeppelin `AccessControlUpgradeable` (`IGovernedAccessControl`). Authority is organized by risk direction rather than by contract: privileged actions map to documentation paths (`GOVERNANCE`, `EMERGENCY`, `OPERATIONS`, `COMPLIANCE`, `REWARDS`, `PUBLIC_READ`), each of which resolves to one or more concrete `*_ROLE` constants. `DEFAULT_ADMIN_ROLE`, the admin over every other role, is held only by the governance Safe (multisig); contract upgrades are governed separately by a `TimelockController` (upgrades pass a timelock delay), which is distinct from the Safe's day-to-day admin authority. Axis follows an operator/manager split: `_OPERATOR` roles **execute** approved flows, while `_MANAGER` roles **configure or move** within bounds, so a hot executor never gains configuration power. The role-by-role breakdown, including which function each role gates, is in [Access Control](/reference/access-control). Two behaviours matter at the architecture level. ### Market roles `EMERGENCY_ROLE` is the one-directional emergency brake on the market: it can only reduce risk, never re-enable expanded operations. It has no role-revocation power, revoking a hot market role is gated by `DEFAULT_ADMIN_ROLE`, so only the admin multisig can remove one. ### Vault roles Restrictions freeze actions; they never seize funds, `RESTRICTION_ROLE` can restrict but cannot mint, burn, seize, service redemptions, or move collateral. ## Design decisions Trade-offs and rationale behind EIP-712 order signing, route- and channel-based custody, the configured reward-vesting window, the asynchronous ERC-7540 redemption lifecycle, the restriction model, and the vault solvency invariants. See [Design Decisions](/technical-and-architecture/design-decisions) for the full discussion. ## Contract dependencies | Contract | Immutable dependencies | Mutable dependencies | | ------------ | ----------------------- | ------------------------------------------------------------- | | `USDx` | None | Role holders (incl. `MARKET_ROLE` on `USDxMarket`) | | `USDxMarket` | `USDx` (mint target) | Supported assets, custodians, routes, channels, capacity caps | | `StakedUSDx` | `USDx` (ERC-4626 asset) | Cooldown duration, reward schedule, roles | Governance and upgrade authority sit above all three and are held by distinct authorities, as described under [Contract model and upgradeability](#contract-model-and-upgradeability) above. # Design Decisions Why the protocol is built the way it is: trade-offs, alternatives considered, and the reasoning behind each major design choice. {% hint style="info" %} This is an **Explanation** page. For structural overview, see [System Architecture](/technical-and-architecture/architecture). For function signatures, see [Reference](/reference/core-contracts). {% endhint %} *** ## Why Offchain Order Signing (EIP-712)? Users sign primary market orders offchain; operators submit them onchain to `USDxMarket` for settlement. This provides: * **Operator-submitted execution** -- the mint/redeem operator (`MINT_OPERATOR_ROLE` / `REDEEM_OPERATOR_ROLE`) pays for the settlement submission; users may still need an onchain token approval * **Operator control** -- the market controls execution timing and batching, and re-runs every pre-trade check before state changes * **Replay protection** -- per-account nonce bitmaps and order expiry (`deadline`) prevent reuse The bitmap-based nonce system (`_nonceBitmaps`) packs 256 nonces into a single storage slot per `accountId`, reducing gas cost compared to sequential nonce tracking. Nonces are namespaced per account and consumed only on successful settlement; a cancelled order is invalidated through an order tombstone rather than by consuming its nonce. *** ## Why Route-Based Custody? During minting, a `route` specifies the allowed asset pair and settlement mode, and the signed order binds a concrete `channelId` naming the approved custody path (custodian, adapter, or cross-chain rail). This lets collateral settle across approved custody channels instead of a single hard-coded destination. The market validates the route and channel against policy, but route support alone does not prove diversification or remove custody risk. *** ## Why Configurable Linear Reward Vesting? Realized trading results are delivered to the rewards vault as USDx rewards through `fundRewards()` (gated by `REWARD_MANAGER_ROLE`), which folds the top-up into a **linear vesting schedule** rather than making it available instantly. Where does that reward come from? It is the realized output of strategies whose 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, and [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield) for the model. Vesting rather than an instant credit prevents: * **Front-running** -- depositing just before a reward is delivered, then exiting immediately to capture it * **Price manipulation** -- sudden jumps in the share exchange rate Rewards vest **linearly over a configured window**; the live value is a configured parameter. A top-up recomputes `rewardRate` and extends `periodFinish`, folding into the *active* window rather than resetting the clock, and is bounded by an optional `maxRewardRate` cap. Only vested rewards count toward `accountedAssets`, so the exchange rate rises smoothly as rewards vest rather than jumping on each funding. *** ## Why Asynchronous (ERC-7540) Redemption? `StakedUSDx` uses an **asynchronous redemption** model (modeled on ERC-7540) rather than an instant withdrawal. The lifecycle: 1. A holder calls `requestRedeem()`, which **burns the shares immediately** and moves the reserved USDx out of `accountedAssets` into `pendingRedeemAssets`. The request snapshots its terms, including `eligibleAt = requestedAt + policy.cooldown`. 2. After the cooldown elapses. An account holding `REDEMPTION_SERVICER_ROLE` calls `serviceRedemptions()`, which moves eligible requests from **pending** to **claimable** (`pendingRedeemAssets` → `claimableRedeemAssets`). 3. The controller then claims the underlying USDx. Because a request's assets are carved out of `accountedAssets` and tracked as **in-vault liabilities** (`pendingRedeemAssets` + `claimableRedeemAssets` = `redeemLiabilities`), the redeeming USDx earns no further rewards and cannot dilute active holders, the same USDx is never counted as both active assets and a liability. There is **no separate escrow (silo) contract**; the pending and claimable buckets live inside the vault. A still-pending request can be cancelled with `cancelRedeemRequest()`, which releases the reserved assets and re-mints the burned shares to the owner. The cooldown is configurable up to a `MAX_COOLDOWN_DURATION` of 90 days; the live value is a configured parameter, and later cooldown changes affect only future requests because each request snapshots its own `eligibleAt`. *** ## Why Two-Level Restrictions? Restrictions are a coarse graduated control rather than a single on/off switch, but the granularity stops at two levels. There is no per-action bitmap. `StakedUSDx` tracks two booleans per account, `_restricted` (soft) and `_fullRestriction` (full); there is no `RestrictionState` struct and no per-subject `scope`, `validUntil`, or `evidenceRef` fields. The derived status is one of three values, `CLEAR`, `RESTRICTED`, or `FULL_RESTRICTION`: * **Soft (`RESTRICTED`)** blocks non-exit actions, its `blockedActions` code is `NON_EXIT`. The account cannot deposit or receive transfers, but can still redeem/exit its own position. * **Full (`FULL_RESTRICTION`)** blocks everything, its `blockedActions` code is `ALL`, including claims and exits. `blockedActions` is a single `bytes32` code taking only `BLOCKED_NONE`, `BLOCKED_NON_EXIT`, or `BLOCKED_ALL`. It is not a bitmap of individual actions such as `TRANSFER_IN`, `TRANSFER_OUT`, `DEPOSIT`, `REQUEST_REDEEM`, `CLAIM`, or `CANCEL_REDEEM_REQUEST`, none of those symbols exist in the code, so a subject cannot be blocked from one action while allowed another beyond the soft/full split. The only basis code emitted is `AUTHORITY` (`BASIS_AUTHORITY`); there is no `SANCTIONS`/`LEGAL_ORDER`/`JURISDICTION`/`TERMS`/`ELIGIBILITY` enum onchain. Raw KYC/KYB, sanctions hits, and legal notes stay offchain. A restriction is applied through `addToBlacklist(target, isFullRestriction)` and cleared with `removeFromBlacklist`, both under `RESTRICTION_ROLE`, which spans both the token (`USDx`) and the vault (`StakedUSDx`). The role is distinct from the mint, burn, settlement, upgrade, and redemption-servicing roles. At the token level, `USDx` implements a coarse Circle-compatible binary `blacklist` (also under `RESTRICTION_ROLE`). There is no `IRestrictionManager` interface in the V2 source, the restriction logic lives inline in the contracts. *** ## Why Donation-Attack Resistance? `StakedUSDx` computes share conversions against `accountedAssets` (active principal plus already-vested rewards), using ERC-4626 floor rounding and virtual shares/assets offsets, rather than against the vault's raw USDx balance. This mitigates the "donation attack", an attacker manipulating the exchange rate by transferring assets directly to the vault. Because a direct USDx donation raises the raw `assetBalance` but not `accountedAssets`, it does not move the exchange rate: reserved redemption liabilities and still-unvested rewards are deliberately excluded from the figure that prices shares. The virtual-offset convention further blunts first-depositor rounding manipulation. *** ## Why a Bounded Reward-Manager Role? Reward delivery is separated from the vault's administrative control plane. `REWARD_MANAGER_ROLE` gates **only** `fundRewards`, folding a top-up into the vesting schedule. It does **not** set reward configuration (`setRewardConfig` is `onlyRole(DEFAULT_ADMIN_ROLE)`) and it does **not** pause reward funding (`pauseRewardFunding` is `onlyRole(PAUSER_ROLE)`). Even the funding it can do is bounded: each top-up is checked against the configured `maxRewardRate` cap and reverts while `_rewardPaused` is set. The role is distinct from `DEFAULT_ADMIN_ROLE`, from the redemption servicer, and from the pause/restriction roles. Following the Axis `_OPERATOR` / `_MANAGER` split, this keeps frequent reward top-ups on a narrowly-scoped role rather than requiring the admin key for routine yield delivery. The separation limits the reward manager to the contract's defined capabilities; it does not remove operator, admin, or key-management risk. # Protocol Administration Axis has **no formal onchain governance today**: there is no token-holder voting and no onchain proposal system. Administrative authority is a **governance Safe (multisig)**, and **contract upgrades are governed by a separate `TimelockController`**, upgrades pass through a timelock delay before they can execute. Axis V2 contracts use OpenZeppelin `AccessControl` roles, and authority is exercised through privileged roles, with the root admin (`DEFAULT_ADMIN_ROLE`) held by the governance Safe. The Safe is not itself behind the timelock; the timelock governs upgrade authority, not the Safe's day-to-day admin actions. This page describes contract capabilities, not the identity, signing threshold, or operating procedure of current role holders. Current role assignments should be verified onchain once published. ## Admin authority and risk direction The root admin role, `DEFAULT_ADMIN_ROLE`, which grants and revokes every other role, is held by the **governance Safe (multisig)**, never a hot EOA. The Safe is a geographically-distributed **3-of-5** signer set spread across stakeholders inside and outside the Axis Labs team. It acts seldom and out of the ordinary course. Upgrade authority is held separately, as set out below. {% hint style="warning" %} **Contract upgrades are governed by a `TimelockController`**: an upgrade must pass a timelock delay before it can execute. The delay is set on the `TimelockController` and is verifiable onchain. `DEFAULT_ADMIN_ROLE` is held by the governance Safe (a **3-of-5** signer set), which is **not** itself behind the timelock, the Safe's day-to-day admin actions execute directly, while the upgrade path is delayed by the timelock. The exact signer set is verifiable onchain. {% endhint %} Authority is organized by **risk direction**: * **Risk-up changes.** Cap increases, adding a route, custodian, or collateral asset, or granting a role, require a deliberate action by the governance Safe, which acts seldom. Upgrading an implementation is additionally delayed: it passes through the `TimelockController`. Non-upgrade admin actions carry no automatic delay window; the control is that only the seldom-acting Safe can make them. * **Risk-down changes.** Pausing, decreasing a cap, revoking a hot role, or applying a restriction, may execute immediately through the guardian roles. This asymmetry lets the protocol tighten risk without delay while confining every risk-increasing change to the multisig. ## Powers by contract The roles below are OpenZeppelin `AccessControl` roles. Their common admin is `DEFAULT_ADMIN_ROLE`, held by the protocol multisig; changes made under that admin follow the risk-direction rule above. For the full role-by-role breakdown, including which function each role gates, see [Access Control](/reference/access-control). ### USDx (token) USDx has no `Ownable` owner. Supply and control powers are role-gated. `MARKET_ROLE` is the only role that can mint, and it is held by the `USDxMarket` contract, so all issuance flows through approved primary market orders, never a hot minting key. `BRIDGE_ROLE` is defined but not granted at launch; granting it is itself an admin-multisig, separately audited action. Any holder may burn its own balance through the ERC-20 burn path, and an approved spender may burn within its allowance. There is no owner-only ability to seize or destroy a third party's funds, restricted funds are frozen, never seized. ### USDxMarket (primary market) `EMERGENCY_ROLE` is the V2 successor to the V1 "Gatekeeper" role, renamed to reflect its risk-down-only scope. Operators can only *execute* pre-authorized orders, they cannot change what may trade, add custody paths, or raise caps. Adding a supported asset, custodian, or route, or increasing a cap, is a risk-up change taken by the admin multisig. Per-order capacity is governed by scoped `CapConfig` limits (global, asset, route, account, channel), enforced in the market rather than by a single per-block cap. ### StakedUSDx (vault) Redemption is asynchronous (ERC-7540): a holder calls `requestRedeem`, an operator with `REDEMPTION_SERVICER_ROLE` calls `serviceRedemptions` after the request's cooldown has elapsed, and the holder then claims through `withdraw`/`redeem`. Reserved redemption assets are tracked inside the vault as pending and claimable liabilities. There is no separate cooldown-escrow (silo) contract. `setCooldownDuration` may set the cooldown from 0 to 90 days; a change affects only future requests, because each request snapshots its own eligibility time. Rewards are added through `fundRewards` under `REWARD_MANAGER_ROLE`, which folds a top-up into the active vesting window rather than resetting it; there is no separate rewards-distributor contract. The admin can rescue non-USDx tokens but cannot rescue USDx or exempt itself from restrictions. ## Emergency authority Emergency powers are intentionally one-way and risk-down only. `EMERGENCY_ROLE` on the market, the V2 successor to the V1 "Gatekeeper" role, can pause capacity, disable mint and redeem, and remove hot market roles, but it cannot grant roles, raise caps, or restore operations. `PAUSER_ROLE` can halt token and vault transfers. The **Compliance** function holds `RESTRICTION_ROLE` (a separate role) to freeze, never seize, addresses. Restoring normal operation is an admin-multisig action, not an emergency one. Because each power maps to a specific role and function, the trust model is reviewable onchain. ## Upgrades All V2 contracts use the transparent proxy pattern with a `ProxyAdmin`; there is no UUPS self-upgrade role in the implementations. Every `ProxyAdmin` is owned by the `TimelockController`, so an upgrade is a risk-up action that must pass the delay before it can execute, and no implementation can upgrade itself. ## Trust implications Privileged roles can materially affect issuance, redemption, custody routing, address restrictions, reward funding, and withdrawal timing. The risk-direction rule and the operator/manager split limit how far any single hot role can reach, an executor cannot reconfigure the system, and a risk-increasing change can be made only by the admin multisig, but the protocol still depends on the security, availability, and honest behavior of the multisig and the privileged accounts behind it. See [Access Control](/reference/access-control) for the complete permission matrix, [Security Overview](/backing-reserves-and-transparency/security) for the trust boundaries, and [Onchain Safety Properties](/backing-reserves-and-transparency/security/onchain-safety-properties) for the invariants these roles must preserve. # Core Contracts Reference Technical reference for the V2 **core** contracts: `USDx` (the token) and the **market contract**, `USDxMarket` + `MarketConfig`. Axis is a market protocol, not a stablecoin-minting protocol: `USDxMarket` is a **market contract, not a minting contract**, it exposes buy/sell (market-order) settlement of USDx, the set of supported assets, EIP-712 signature verification, and the per-block max-mint / max-redeem limits. Minting and redemption are simply the buy and sell sides of that market. For design rationale, see [Architecture](/technical-and-architecture/architecture). For the yield-token vault and its ERC-7540 staking functions, see [Staking Contracts](/reference/staking-contracts). For the full role map, see [Access Control](/reference/access-control). For at-launch addresses, see [Contract Addresses](/reference/contract-addresses). Terminology follows the canonical Protocol Taxonomy. All three contracts are upgradeable behind `TransparentUpgradeableProxy` (transparent proxy + `ProxyAdmin`); each implementation disables its initializers in the constructor and exposes a one-shot `initialize` that runs once behind the proxy and grants `DEFAULT_ADMIN_ROLE`. Supply, settlement policy, and capacity accounting are split across the three contracts so that no single surface holds both execution and configuration authority. *** ## USDx **Verified source:** [read on Etherscan](https://etherscan.io/address/0xa1fA7777974312f7d801A8880714a218F76233f8#code) **Inherits:** `Initializable`, `IUSDx`, `ERC20PermitUpgradeable`, `AccessControlUpgradeable` The Axis Dollar: an upgradeable ERC-20 (with `ERC20Permit`) synthetic dollar with role-gated supply, bridge, pause, and restriction controls. Every balance-changing path, transfer, mint, burn, funnels through `_update`, the single enforcement point for pause and blacklist checks. Supply changes are approved primary market or bridge flows, never open user actions. Issuer: Coordinate Origin Limited. 18 decimals (ERC-20 default). ### Roles Role identifiers are defined once protocol-wide and exposed as public constants on the token. | Constant | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MARKET_ROLE` | Primary market supply authority, the only role that can call `mint`. Held by the `USDxMarket` contract so all issuance flows through settled orders. The only live launch supply authority. | | `BRIDGE_ROLE` | Cross-chain supply authority for `bridgeMint` / `bridgeBurn`. Defined in code but **intentionally not granted at initialization**, no live holder at V2 launch. | | `RESTRICTION_ROLE` | Sets and clears the blacklist via `blacklist` / `unBlacklist`. Can restrict but never mint, burn, or seize. | | `PAUSER_ROLE` | Emergency pause/unpause of all token balance changes via `pause` / `unpause`. | | `DEFAULT_ADMIN_ROLE` | Admin over every other role (grant/revoke). Granted to the governance `admin` at `initialize`. See [Access Control](/reference/access-control) for the launch key model. | ### State Variables | Variable | Type | Description | | -------------- | -------------------------- | ---------------------------------------------------------- | | `_paused` | `bool` | Global pause flag (read via `paused()`). | | `_blacklisted` | `mapping(address => bool)` | Per-account restriction flag (read via `isBlacklisted()`). | ### Functions #### `initialize` ```solidity function initialize(address admin) external initializer ``` Sets token metadata (name `"USDx"`, symbol `"USDx"`, `ERC20Permit` name `"USDx"`) and grants `DEFAULT_ADMIN_ROLE` to `admin`. Runs exactly once behind the proxy. **Reverts:** `ZeroAddress()`, `admin == address(0)`. *** #### `mint` ```solidity function mint(address to, uint256 amount) external onlyRole(MARKET_ROLE) ``` Mint `amount` USDx to `to`. Only callable by the `MARKET_ROLE` holder (`USDxMarket`). Routes through `_update`, so it reverts while paused or when `to` is blacklisted. **Reverts:** `ZeroAddress()`, `to == address(0)`; plus `_update` guards (`OperationPaused`, `RestrictedAddress`). **Events:** ERC-20 `Transfer(address(0), to, amount)`. *** #### `burn` ```solidity function burn(uint256 amount) external ``` Destroys `amount` USDx from the caller's own balance. Permissionless on the caller's balance, redemption burns are effected by the market spending an approval via `burnFrom`. Routes through `_update`. *** #### `burnFrom` ```solidity function burnFrom(address from, uint256 amount) external ``` Spends the caller's allowance over `from`, then burns `amount` USDx from `from`. Used by `USDxMarket` to settle redemptions. Rejects a blacklisted spender before spending the allowance. **Reverts:** `RestrictedAddress(spender)`, caller is blacklisted; `ZeroAddress()`, `from == address(0)`; plus `_update` guards. *** #### `transferFrom` ```solidity function transferFrom(address from, address to, uint256 value) public override(ERC20Upgradeable, IERC20) returns (bool) ``` Standard ERC-20 `transferFrom`, additionally rejecting a blacklisted spender (`msg.sender`) before delegating to the base implementation. **Reverts:** `RestrictedAddress(spender)`, caller is blacklisted; plus `_update` guards. *** #### `bridgeMint` ```solidity function bridgeMint(address to, uint256 amount) external onlyRole(BRIDGE_ROLE) ``` Cross-chain supply primitive: mints `amount` USDx to `to` on this chain. Moves supply between chains without changing global supply, each chain's `totalSupply()` is local only; global supply is reconciled offchain. `BRIDGE_ROLE` has no live holder at launch. **Reverts:** `ZeroAddress()`, `to == address(0)`. **Events:** `BridgeMint(msg.sender, to, amount)`. *** #### `bridgeBurn` ```solidity function bridgeBurn(uint256 amount) external onlyRole(BRIDGE_ROLE) ``` Cross-chain supply primitive: burns `amount` USDx from the bridge caller. **Events:** `BridgeBurn(msg.sender, msg.sender, amount)`. *** #### `blacklist` / `unBlacklist` ```solidity function blacklist(address account) external onlyRole(RESTRICTION_ROLE) function unBlacklist(address account) external onlyRole(RESTRICTION_ROLE) ``` Set or clear `account`'s restriction flag. Circle-compatible adapter, enforced centrally in `_update`: a blacklisted address is blocked from sending, receiving, minting, and burning, and cannot be a spender. Deliberately omits USDT-style seizure, funds are frozen, never taken. **Reverts:** `ZeroAddress()`, `account == address(0)`. **Events:** `Blacklisted(account)` / `UnBlacklisted(account)`. *** #### `pause` / `unpause` ```solidity function pause() external onlyRole(PAUSER_ROLE) function unpause() external onlyRole(PAUSER_ROLE) ``` Halt or restore all USDx balance changes. While paused, `_update`, `approve`, and `permit` all revert. **Events:** `Paused(msg.sender)` / `Unpaused(msg.sender)`. *** #### `paused` / `isBlacklisted` ```solidity function paused() external view returns (bool) function isBlacklisted(address account) external view returns (bool) ``` Read the pause flag and per-account restriction flag. *** #### `approve` / `permit` / `nonces` Standard `ERC20` / `ERC20Permit` surface. `approve` and `permit` additionally revert while the token is paused (`_requireNotPaused`). `nonces` returns the permit nonce for `owner`. *** #### `_update` (internal) ```solidity function _update(address from, address to, uint256 value) internal override ``` The single balance-change guard for every transfer, mint, and burn. Reverts `OperationPaused()` while paused, and `RestrictedAddress(from)` / `RestrictedAddress(to)` if either party is blacklisted, before delegating to the base ERC-20 update. ### Events | Event | Parameters | | --------------- | -------------------------------------------------- | | `Blacklisted` | `address account` | | `UnBlacklisted` | `address account` | | `Paused` | `address account` | | `Unpaused` | `address account` | | `BridgeMint` | `address caller`, `address to`, `uint256 amount` | | `BridgeBurn` | `address caller`, `address from`, `uint256 amount` | (Plus standard ERC-20 `Transfer` / `Approval`.) ### Errors | Error | Trigger | | ---------------------------- | ------------------------------------------------------- | | `ZeroAddress()` | Zero address where a non-zero one is required | | `RestrictedAddress(address)` | A blacklisted party in a transfer, mint, burn, or spend | | `OperationPaused()` | Any balance change, `approve`, or `permit` while paused | *** ## USDxMarket **Verified source:** [read on Etherscan](https://etherscan.io/address/0x5aE365Ac83638418c4c30555d32F9A91ccAEf58C#code) **Inherits:** `Initializable`, `IUSDxMarket`, `AccessControlUpgradeable` The market contract, not a minting contract: it validates signed EIP-712 market orders and settles them exactly once, executing the buy side (mint) or sell side (redeem) of USDx against approved routes, channels, and capacity limits. Order validation, nonce use, cap checks, and asset movement are sequenced so a failed settlement consumes neither a nonce nor capacity. `USDxMarket` holds `MARKET_ROLE` on `USDx` (to mint / `burnFrom`) and `SETTLEMENT_MANAGER_ROLE` on `MarketConfig` (to consume capacity); it reads all routing, whitelist, and capacity policy from `MarketConfig`. ### Roles | Constant | Description | | ------------------------- | ------------------------------------------------------------------------------------------------------------- | | `MINT_OPERATOR_ROLE` | May `settle` orders whose `side == MINT`. Execution authority only. | | `REDEEM_OPERATOR_ROLE` | May `settle` orders whose `side == REDEEM`. Execution authority only. | | `SETTLEMENT_MANAGER_ROLE` | May `cancelOrder` (tombstone an order hash). Manage-vs-execute is deliberately split from the operator roles. | | `DEFAULT_ADMIN_ROLE` | Admin over the operator/manager roles; granted at `initialize`. | Operators execute pre-authorized orders; they cannot change what an order means. Delegation and cancellation are separated from execution. ### State Variables | Variable | Type | Description | | ------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------- | | `usdx` | `IUSDx` | The USDx token contract. | | `marketConfig` | `IPrimaryMarketConfig` | Policy/capacity registry (`MarketConfig`). | | `_orders` | `mapping(bytes32 => OrderRecord)` | Per-order-hash lifecycle: `{bool settled; bool cancelled; bytes32 proofId}`. | | `_nonceBitmaps` | `mapping(bytes32 => mapping(uint256 => uint256))` | Nonce bitmap keyed per `accountId` (not per signer). | | `_delegatedSigners` | `mapping(address => mapping(address => SignerStatus))` | `signer => source => status`. | ### Types ```solidity struct Order { bytes32 accountId; // Approved primary market account the order settles for bytes32 routeId; // Allowed side + asset-pair market bytes32 channelId; // Concrete approved settlement path (custodian/destination) address signer; // Source account authorizing the order OrderSide side; // MINT or REDEEM address inputAsset; // Asset paid in (collateral for MINT, USDx for REDEEM) address outputAsset; // Asset paid out (USDx for MINT, collateral for REDEEM) uint256 inputAmount; // Amount paid in uint256 minOutputAmount; // Amount paid out (settlement uses this exact value) address receiver; // Recipient of the output uint256 deadline; // Timestamp after which the order is invalid uint256 nonce; // Single-use, non-zero, tracked in the accountId bitmap bytes32 termsHash; // Accepted-terms version bound into the order } struct Signature { SignatureType signatureType; // EIP712 bytes signatureBytes; } enum OrderSide { MINT, REDEEM } enum SignatureType { EIP712 } enum SignerStatus { REJECTED, PENDING, ACCEPTED } ``` The EIP-712 type string is fixed in `ORDER_TYPEHASH`; the domain is `EIP712Domain(name="USDxMarket", version="1", chainId, verifyingContract)`. {% hint style="info" %} **Units:** capacity and block limits meter USDx notional (18-decimal wei), `minOutputAmount` on a MINT, `inputAmount` on a REDEEM. Collateral amounts use the collateral token's native decimals. `settle` pays out exactly `minOutputAmount`; there is no partial fill. {% endhint %} ### Functions: Settlement #### `settle` ```solidity function settle(Order calldata order, Signature calldata signature, bytes calldata settlementData) public returns (bytes32 proofId) ``` Executes a valid signed order exactly once. Re-runs the full precheck (`_checkSettlement`), enforces the side-appropriate operator role, marks the nonce used, records the settlement proof, consumes capacity, and moves assets. Emits `OrderSettled` plus the side event. **Authorization:** requires `MINT_OPERATOR_ROLE` when `side == MINT`, else `REDEEM_OPERATOR_ROLE`. Reverts `AccessControlUnauthorizedAccount` otherwise. **Order of operations (all-or-nothing):** 1. `_checkSettlement`, order shape, status (not settled/cancelled), nonce unused, signature, whitelist, `accountId` match, token pause/blacklist, route/channel, block limits, and multi-scope capacity. Any failure reverts via `_revertForReason` before state changes. 2. Operator role check. 3. Mark `order.nonce` used in the `order.accountId` bitmap (irreversible on success). 4. Record proof: `proofId = keccak256(orderHash, address(this), chainId, block.number)`; set `_orders[orderHash] = {settled: true, proofId}`. 5. `marketConfig.consumeCapacity` and `consumeBlockCapacity`. 6. **MINT:** transfer `inputAmount` of `inputAsset` from `signer` to the channel `destination`, then `usdx.mint(receiver, minOutputAmount)`. **REDEEM:** `usdx.burnFrom(signer, inputAmount)`, then transfer `minOutputAmount` of `outputAsset` to `receiver`. **Events:** `OrderSettled(...)`; then `Mint(msg.sender, signer, receiver, inputAsset, inputAmount, minOutputAmount)` or `Redeem(msg.sender, signer, receiver, outputAsset, minOutputAmount, inputAmount)`. {% hint style="info" %} Signer authorization accepts a direct EOA / ERC-1271 signature from `order.signer`, an accepted delegated ECDSA signer, or an encoded smart-account delegate signature, checked in that order. Delegation is an onchain registry (`REJECTED` / `PENDING` / `ACCEPTED`), not just `ecrecover`. {% endhint %} *** #### `mint` / `redeem` ```solidity function mint(Order calldata order, Signature calldata signature, bytes calldata settlementData) external function redeem(Order calldata order, Signature calldata signature, bytes calldata settlementData) external ``` Thin side-guarded wrappers over `settle`: `mint` reverts `InvalidOrder()` unless `side == MINT`, `redeem` unless `side == REDEEM`, then delegate to `settle` (which enforces the operator role and all checks). *** #### `checkSettlement` ```solidity function checkSettlement(Order calldata order, Signature calldata signature, bytes calldata) public view returns (SettlementCheck memory) ``` Non-mutating preview of whether an order can settle under current policy, routing, nonce, signature, and capacity. Returns `{allowed, reasonCode, orderHash, routeId, channelId, availableNotionalAmount, requiredNotionalAmount}`. `settlementData` is ignored by the preview. Execution re-runs every check before state changes. *** #### `cancelOrder` ```solidity function cancelOrder(Order calldata order) external onlyRole(SETTLEMENT_MANAGER_ROLE) ``` Tombstones an unsettled order hash so it can never settle. Cancellation does **not** consume the nonce; the order is invalidated via `_orders[orderHash].cancelled`. Signature verification is not part of cancellation. **Reverts:** `InvalidNonce()`, the order is already settled or cancelled. **Events:** `OrderCancelled(orderHash, order.accountId)`. ### Functions: Delegation Delegation is a two-step process: the source account initiates, and the delegate confirms. A delegate cannot sign until it has accepted. ```solidity function setDelegatedSigner(address signer) external // source initiates -> PENDING function confirmDelegatedSigner(address source) external // delegate accepts -> ACCEPTED function removeDelegatedSigner(address signer) external // source revokes -> REJECTED ``` **Reverts:** `InvalidAddress()`, zero signer; `SignerNotInitiated()`, confirming a relationship that is not `PENDING`. **Events:** `DelegatedSignerInitiated(signer, source)`, `DelegatedSignerAdded(signer, source)`, `DelegatedSignerRemoved(signer, source)`. ### Functions: Verification (view) | Function | Returns / behavior | | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `hashOrder(Order)` | EIP-712 typed-data hash over `DOMAIN_SEPARATOR()` and the order struct hash. | | `verifyOrder(Order, Signature)` | Order hash if currently valid; reverts via `_revertForReason` otherwise. | | `verifyNonce(bytes32 accountId, uint256 nonce)` | `(slot, bitmap, bit)` if the nonce is non-zero and unused; reverts `InvalidNonce()` otherwise. | | `isNonceUsed(bytes32 accountId, uint256 nonce)` | `true` if the nonce bit is set. | | `orderState(bytes32 orderHash)` | `(settled, cancelled, proofId)`. | | `proofOfOrder(bytes32 orderHash)` | The linked `proofId` (the full receipt is reconstructed offchain from `OrderSettled`). | | `checkMint(Order, Signature)` / `checkRedeem(Order, Signature)` | `OrderCheck{valid, code, orderHash, signer, nonceUsed, availableBlockCapacity}` for the matching side. | | `DOMAIN_SEPARATOR()` / `eip712Domain()` | The EIP-712 domain over name `USDxMarket`, version `1`, chain id, and this contract. | {% hint style="info" %} **Nonce bitmap:** each `uint256` slot tracks 256 nonces, keyed per `accountId`. Slot index `nonce >> 8`, bit `1 << (nonce & 0xff)`. Nonces are non-sequential and single-use; the bit is set only on successful settlement, and the flip is irreversible. {% endhint %} ### Functions: Registry reads (proxied to `MarketConfig`) `route`, `channel`, `isRouteEnabled`, `isChannelEnabled`, `isSupportedAsset`, `getSupportedAssets`, `getCustodians`, `isCustodian`, `isWhitelisted`, `signerAccount`, `checkChannel`, `cap`, `capUsage`, `checkCapacity`, `maxCapacity`, `getCurrentBlockCapacity`, `getMintingState`, `getUserLimit`, `getUserBlockCapacity`, all read policy from `marketConfig`. `delegatedSigner(signer, source)` reads the market's own delegation registry. ### Events | Event | Parameters | | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------- | | `OrderSettled` | `proofId`, `orderHash`, `accountId`, `routeId`, `channelId`, `destination`, `channelHash`, `settlementHash` | | `Mint` | `caller`, `signer`, `receiver`, `inputAsset`, `inputAmount`, `outputAmount` | | `Redeem` | `caller`, `signer`, `receiver`, `outputAsset`, `outputAmount`, `inputAmount` | | `OrderCancelled` | `orderHash`, `accountId` | | `DelegatedSignerInitiated` / `DelegatedSignerAdded` / `DelegatedSignerRemoved` | `signer`, `source` | ### Errors | Error | Trigger | | ----------------------------------------------------------- | ---------------------------------------------------------------------------------- | | `InvalidUSDxAddress()` | Zero USDx address in `initialize` | | `InvalidAddress()` | Zero config/admin/signer address | | `InvalidOrder()` | Malformed order or `mint`/`redeem` side mismatch | | `InvalidSignature()` | Signer is not the account, an accepted delegate, or a valid ERC-1271 signer | | `SignatureExpired()` | `block.timestamp > order.deadline` | | `InvalidNonce()` | Nonce used/zero, or order already settled/cancelled | | `NotWhitelisted()` | Signer/receiver not whitelisted, `accountId` mismatch, or a restricted token party | | `InvalidRoute()` | Route disabled, side/asset mismatch, or amount below route minimum | | `InvalidChannel()` | Channel disabled, channel/route mismatch, or custodian not approved | | `CapacityExceeded(bytes32 code)` | A global/asset/route/account/channel cap is exceeded | | `MaxMintPerBlockExceeded()` / `MaxRedeemPerBlockExceeded()` | Same-block circuit breaker hit | | `SignerNotInitiated()` | Confirming a delegation that is not `PENDING` | *** ## MarketConfig **Verified source:** [read on Etherscan](https://etherscan.io/address/0xce2cF8B00FCb5946F495ebD15ff9F0001E024D46#code) **Inherits:** `Initializable`, `IPrimaryMarketConfig`, `AccessControlUpgradeable` The policy and capacity registry `USDxMarket` reads during settlement. Admins configure routes, channels, caps, whitelists, and signer→account bindings; the market holds `SETTLEMENT_MANAGER_ROLE` and is the only expected capacity consumer. Configuration follows the risk-direction rule, risk-**down** changes (pause capacity, disable mint/redeem) may execute immediately via `EMERGENCY_ROLE`; risk-**up** changes (re-enable, raise caps, add routes/channels) require `DEFAULT_ADMIN_ROLE`. ### Roles | Constant | Description | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | Full configuration authority: routes, channels, caps, whitelist, signer accounts, block limits, re-enabling flows. | | `SETTLEMENT_MANAGER_ROLE` | May `consumeCapacity` and `consumeBlockCapacity`. Held by `USDxMarket` so external callers cannot move cap usage. | | `EMERGENCY_ROLE` | Risk-down only: `pauseCapacity` and disabling mint/redeem via `setMintRedeemEnabled`. Cannot re-enable or raise limits. | ### State Variables | Variable | Type | Description | | --------------------------------------- | ----------------------------- | ------------------------------------------ | | `mintEnabled` / `redeemEnabled` | `bool` | Global mint/redeem settlement switches. | | `maxMintPerBlock` / `maxRedeemPerBlock` | `uint256` | Same-block USDx notional circuit breakers. | | `mintedPerBlock` / `redeemedPerBlock` | `mapping(uint256 => uint256)` | Per-block-number usage counters. | Internal mappings hold routes, channels, caps, cap usage, supported assets, custodians, the whitelist, signer→account bindings, and per-cap pause flags. ### Types ```solidity enum CapScope { GLOBAL, ASSET, ROUTE, ACCOUNT, CHANNEL } // five dimensions a cap can throttle enum WindowType { NONE, BLOCK, FIXED } // lifetime, per-block, or fixed timestamp bucket enum SettlementMode { CUSTODY, ADAPTER, CROSS_CHAIN } // how a route settles ``` A **route** (`RouteState`) defines a side, input/output asset pair, `SettlementMode`, minimum amounts, and an enabled flag, *what* may trade. A **channel** (`ChannelState`) binds a route to a concrete custodian and destination with its own enabled flag and `channelHash`, *where* it settles. A **cap** (`CapConfig`) sets a notional `cap`, `WindowType`, and `windowSize` for a `CapKey` (scope + subject). ### Functions: Initialization ```solidity function initialize(address usdx, address admin, uint256 maxMintPerBlock_, uint256 maxRedeemPerBlock_) external initializer ``` Enables mint and redeem, sets the per-block limits, grants `DEFAULT_ADMIN_ROLE` to `admin`, and registers `usdx` as a supported asset. **Reverts:** `InvalidAddress()`, zero `usdx` or `admin`. ### Functions: Configuration (`DEFAULT_ADMIN_ROLE`) | Function | Effect | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `setRoute(RouteState)` | Register/update a route; auto-registers its input/output assets. Emits `RouteSet`. | | `setChannel(ChannelState)` | Register/update a channel on an existing route with an approved custodian/destination; auto-registers the custodian. Emits `ChannelSet` (and `CustodianAdded`). | | `setChannelStatus(bytes32 channelId, bool enabled)` | Enable/disable a channel. Emits `ChannelStatusSet`. | | `setWhitelist(address account, bool allowed)` | Allow/deny an account as signer or receiver. Emits `WhitelistSet`. | | `setSignerAccount(address signer, bytes32 accountId)` | Bind/clear the `accountId` a signer may use. Emits `SignerAccountSet`. | | `setCap(CapKey, CapConfig)` | Configure a global/asset/route/account/channel cap (fixed windows require non-zero `windowSize`). Emits `CapSet`. | | `unpauseCapacity(CapKey)` | Restore a paused cap. Emits `CapacityUnpaused`. | | `setMaxMintPerBlock` / `setMaxRedeemPerBlock` | Update the same-block circuit-breaker limits. Emits `MaxMintPerBlockChanged` / `MaxRedeemPerBlockChanged`. | ### Functions: Emergency (risk-down) ```solidity function pauseCapacity(CapKey calldata key) external // DEFAULT_ADMIN_ROLE or EMERGENCY_ROLE function setMintRedeemEnabled(bool mintEnabled_, bool redeemEnabled_) external ``` `pauseCapacity` disables a configured cap immediately (emits `CapacityPaused`). `setMintRedeemEnabled` lets `EMERGENCY_ROLE` turn flows **off** immediately, but **re-enabling** a disabled flow requires `DEFAULT_ADMIN_ROLE`, an emergency holder that tries to risk up reverts `AccessControlUnauthorizedAccount`. ### Functions: Capacity accounting (`SETTLEMENT_MANAGER_ROLE`) ```solidity function consumeCapacity(CapacityRequest calldata request) external returns (bytes32 consumptionId) function consumeBlockCapacity(OrderSide side, uint256 amount) external ``` Called by `USDxMarket` during `settle` to record usage across every enabled cap scope and the same-block counter after validation passes. Restricted so no external caller can move cap usage. ### Functions: Reads `route`, `channel`, `isRouteEnabled`, `isChannelEnabled`, `isSupportedAsset`, `getSupportedAssets`, `getCustodians`, `isCustodian`, `isWhitelisted`, `signerAccount`, `getCurrentBlockCapacity`, `cap`, `capUsage`, `checkChannel`, `checkCapacity`, `maxCapacity`. `checkCapacity` walks the caps in scope order (global → asset → route → account → channel) and returns the first failing reason code with the tightest remaining availability. {% hint style="info" %} `getUserLimit` and `getUserBlockCapacity` are present for interface compatibility and currently return zeroed structs, per-user limits are not applied at launch; throughput is governed by the block limits and the five cap scopes. {% endhint %} ### Events `RouteSet`, `ChannelSet`, `ChannelStatusSet`, `CustodianAdded`, `WhitelistSet`, `SignerAccountSet`, `CapSet`, `CapacityConsumed`, `CapacityPaused`, `CapacityUnpaused`, `MaxMintPerBlockChanged`, `MaxRedeemPerBlockChanged`, `AssetAdded`, `AssetRemoved`. ### Errors | Error | Trigger | | ---------------------------------------------------- | --------------------------------------------------------------------- | | `InvalidAddress()` | Zero address where non-zero required | | `InvalidRoute()` | Malformed route (zero id or asset) | | `InvalidChannel()` | Channel with no matching route, zero custodian, or zero destination | | `InvalidAssetAddress()` | Zero asset in the supported-asset set | | `InvalidAmount()` | Invalid cap key/window, or capacity consumed without passing checks | | `AccessControlUnauthorizedAccount(address, bytes32)` | Caller lacks the required role (including emergency risk-up attempts) | # Staking Contracts Reference Technical reference for `StakedUSDx`, the V2 rewards vault. For design rationale, see [Architecture](/technical-and-architecture/architecture). For usage instructions, see [Stake & Unstake](/susdx-the-rewards-vault/stake-and-unstake). Terminology follows the Protocol Taxonomy (the V2 single source of truth) rather than being redefined here. V2 collapses the V1 staking system into a **single contract**. The V1 layout, a base vault (`StakedAxisUSD`), a cooldown subclass (`StakedAxisUSDV2`), a separate escrow (`AxisUSDSilo`), and an external distributor (`StakingRewardsDistributor`), no longer exists. In V2 there is **no silo**: redemption liabilities are held in-vault as pending/claimable buckets. There is **no separate distributor**: rewards are funded directly into the vault by a `REWARD_MANAGER_ROLE` holder. Withdrawals are **async (ERC-7540)** rather than a synchronous cooldown-then-unstake flow. *** ## StakedUSDx **Verified source:** [read on Etherscan](https://etherscan.io/address/0xEB892628D1E58BC475A6dCB7F5dBC4F591632AA4#code) **Inherits:** `Initializable`, `ERC4626Upgradeable`, `AccessControlUpgradeable`, `IStakedUSDx` An upgradeable ERC-4626 rewards vault. Users deposit **USDx** (the asset) and receive **sUSDx** (the share, ERC-20 name/symbol `"Staked USDx"` / `"sUSDx"`). Shares appreciate as funded rewards vest linearly into vault accounting. Exits are asynchronous: a holder calls `requestRedeem`, waits out a cooldown, a servicer makes the request claimable, and the holder then claims. The vault is its own ERC-7575 share token, `share()` returns `address(this)`, and implements the ERC-7540 async-redeem interfaces (`IERC7540Redeem`, `IERC7540Operator`). Deployed behind a `TransparentUpgradeableProxy` with a governance-owned `ProxyAdmin`; the implementation disables initializers in its constructor and is set up once via `initialize`. ### Roles | Role | Constant | Authority | | -------------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------- | | `DEFAULT_ADMIN_ROLE` | `bytes32(0)` | Admin over every other role; configures rewards, redemption controls, and policies | | `REWARD_MANAGER_ROLE` | `keccak256("REWARD_MANAGER_ROLE")` | Funds rewards via `fundRewards` | | `REDEMPTION_SERVICER_ROLE` | `keccak256("REDEMPTION_SERVICER_ROLE")` | Services the redemption queue (pending → claimable) | | `PAUSER_ROLE` | `keccak256("PAUSER_ROLE")` | Pauses deposits, reward funding, and each redemption sub-flow | | `RESTRICTION_ROLE` | `keccak256("RESTRICTION_ROLE")` | Sets/clears soft and full restrictions; redistributes shares and requests off frozen accounts | At `initialize(asset_, admin, rewardDuration_)`, the `admin` address is granted all five roles. See the taxonomy for the intended production custody of each role at launch. ### Constants | Constant | Value | Description | | ------------------------------ | ------------------------- | ------------------------------------------------------ | | `MAX_COOLDOWN_DURATION` | `90 days` | Upper bound for the redemption cooldown | | `DEFAULT_REDEMPTION_POLICY_ID` | `bytes32("DEFAULT")` | Id of the always-enabled default redemption policy | | `REQUEST_ID` | `uint256` (starts at `1`) | Public monotonic counter; next request id to be minted | | `WAD` | `1e18` | Fixed-point scale for `exchangeRate` (internal) | | `MAX_SERVICE_SCAN_REQUESTS` | `256` | Per-call scan bound in `serviceRedemptions` (internal) | ### Accounting model sUSDx is priced against `accountedAssets`, active principal plus already-vested rewards, **not** the raw USDx balance. Unvested rewards and reserved redemption liabilities are deliberately excluded from the share price so servicing, claims, and vesting can never spend the same USDx twice. | Read | Meaning | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `totalAssets()` | `accountedAssets` including rewards vested up to now; drives ERC-4626 conversions | | `accountedAssets()` | Active principal + vested rewards backing sUSDx | | `pendingRedeemAssets()` | USDx reserved for `PENDING` requests (shares already burned, value moved out of `accountedAssets`) | | `claimableRedeemAssets()` | USDx reserved for serviced `CLAIMABLE` requests, awaiting claim | | `exchangeRate()` | 18-decimal USDx-per-sUSDx (`totalAssets · 1e18 / totalSupply`, floor); returns `1e18` when supply is 0 | | `getVaultState()` | Full snapshot: supply, assets, both liability buckets, `redeemLiabilities`, `requiredAssets`, `assetBalance`, `exchangeRate`, `cooldown`, `solvent` | Solvency invariant: `assetBalance >= requiredAssets`, where `requiredAssets = accountedAssets + pendingRedeemAssets + claimableRedeemAssets + unvestedRewards`. `redeemLiabilities = pendingRedeemAssets + claimableRedeemAssets`. `decimals()` is `18`. `convertToShares`/`convertToAssets` use floor rounding against `accountedAssets`. `previewWithdraw()` and `previewRedeem()` **always revert** (`OperationNotAllowed`) because claims are async and share-exact rather than previewable. ### Deposit (stake) Synchronous ERC-4626 entry, USDx in, sUSDx out immediately. | Function | Access | Description | | ------------------------------------------- | -------- | ------------------------------------------------------------------------------------------- | | `deposit(uint256 assets, address receiver)` | external | Pull USDx, checkpoint rewards, credit `accountedAssets`, mint shares | | `mint(uint256 shares, address receiver)` | external | Same, denominated in shares | | `maxDeposit` / `maxMint` | view | Return `0` when deposits are paused or the receiver is restricted, else `type(uint256).max` | Deposits revert while `depositPaused` is set or when the caller or receiver is restricted. ### Reward funding & vesting Rewards are funded **directly into the vault**, there is no external distributor. A `REWARD_MANAGER_ROLE` holder transfers USDx in and folds it into a linear vesting schedule. | Function | Access | Description | | ----------------------------------------------------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------- | | `fundRewards(uint256 assets, bytes32 sourceRef)` | `REWARD_MANAGER_ROLE` | Checkpoint vested rewards, pull `assets`, increment `unvestedRewards`, recompute `rewardRate`, set `periodFinish` | | `setRewardConfig(uint256 duration, uint256 maxRate, bool paused)` | `DEFAULT_ADMIN_ROLE` | Set vesting duration, optional `maxRewardRate` cap, and funding-pause; reschedules active rewards | | `pauseRewardFunding()` | `PAUSER_ROLE` | Pause funding and freeze the active vesting schedule | | `rewardConfig()` / `rewardState()` | view | Report authority/duration/maxRate/paused, and live `unvestedRewards`/`rewardRate`/`periodFinish` | Behavior: `fundRewards` reverts if reward funding is paused, `assets` or `rewardDuration` is zero, or `totalSupply()` is zero. A top-up **folds into the active vesting window** (it does not reset the clock, see `_activeRewardDuration`) and is rejected if the resulting `rewardRate` would exceed a non-zero `maxRewardRate`. Vested rewards are materialized into `accountedAssets` on each checkpoint (deposit, request, or fund); unvested rewards stay outside the share price until they drip in. After `periodFinish`, `rewardRate` drops to zero and any remainder is treated as fully vested. Emits `RewardsFunded(funder, assets, sourceRef, rewardRate, periodFinish)` and `RewardConfigUpdated(authority, duration, maxRate, paused)`. ### Async redemption lifecycle (ERC-7540) Exits are a three-step async flow. Shares are burned up front at request time; USDx moves through the in-vault pending and claimable liability buckets and is transferred out only at claim. ``` requestRedeem ──▶ PENDING ──serviceRedemptions──▶ CLAIMABLE ──withdraw/redeem──▶ CLAIMED (burn shares, (cooldown, (REDEMPTION_ (release reserved reserve assets) awaiting service) SERVICER_ROLE) USDx to receiver) ``` **1, Request.** `requestRedeem(uint256 shares, address controller, address owner)` burns the owner's shares, moves the corresponding assets from `accountedAssets` to `pendingRedeemAssets`, and records a `RedemptionState` (shares, `assetsReserved`, `requestedAt`, `eligibleAt = requestedAt + policy.cooldown`, `policyId`, `status = PENDING`). Returns a monotonic `requestId`. Fully restricted owners/controllers cannot open requests; a soft-restricted owner may only exit to their own controller. Reverts if requests are paused, on zero inputs, if the caller is not the owner/controller or their approved operator, if the owner's balance is short (`MinSharesViolation`), or if `shares` exceed the policy's `maxRequestShares`. Emits `RedeemRequest`. **2, Service.** A `REDEMPTION_SERVICER_ROLE` holder moves eligible pending requests to `CLAIMABLE`, shifting reserved USDx from `pendingRedeemAssets` to `claimableRedeemAssets`. This is the in-vault replacement for V1's silo transfer. | Function | Access | Description | | ------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `serviceRedemptions(uint256 maxShares)` | `REDEMPTION_SERVICER_ROLE` | Batched scan in request-id order; services eligible requests up to `maxShares` (soft cap) and `MAX_SERVICE_SCAN_REQUESTS` (256) scanned per call | | `serviceRedeemRequest(uint256 requestId, address controller)` | `REDEMPTION_SERVICER_ROLE` | Service one specific eligible request by id and controller | `serviceRedemptions` skips requests still in cooldown but carries a **forward-progress guarantee**: the first eligible request in a batch is always serviced, so a single oversized request can never permanently stall the queue (`maxShares` is a soft batch cap, not a per-request maximum, per-request size is bounded by `policy.maxRequestShares`). Both forms revert if servicing is paused and emit `RedemptionsServiced(serviceId, requestsServiced, sharesMadeClaimable, assetsReserved)`. **3, Claim.** In this async vault `withdraw` and `redeem` are **claim-only**, they release already-serviced (`CLAIMABLE`) assets rather than exiting live shares (which were burned at request time). | Function | Access | Description | | ---------------------------------------------------------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | `redeem(uint256 shares, address receiver, address controller)` | controller or approved operator | Share-exact claim (floor rounding across serviced lots); returns assets | | `withdraw(uint256 assets, address receiver, address controller)` | controller or approved operator | Asset-denominated claim; partial lots round shares up and may revert, use `redeem` for share-exact partials | | `maxRedeem(controller)` / `maxWithdraw(controller)` | view | Controller's total claimable shares / assets; return `0` when claims are paused or the controller is fully restricted | `withdraw(maxWithdraw(controller))` (every lot consumed in full) always succeeds; some intermediate asset amounts below the max may revert on per-lot share rounding. Claims revert while claims are paused, on zero inputs, or on restriction violations (fully restricted controller/receiver/owner; soft-restricted parties may only settle to themselves). Both emit `Withdraw(sender, receiver, controller, assets, shares)`. **Cancel.** `cancelRedeemRequest(uint256 requestId, address controller)` cancels a still-`PENDING` request: it sets status `CANCELLED`, releases reserved assets back to `accountedAssets`, and re-mints the burned shares to the owner. Blocked when cancellations are paused or when the controller/owner is fully restricted (shares would return to a frozen holder). Emits `RedeemRequestCancelled`. **Operators.** `setOperator(address operator, bool approved)` lets a controller authorize an operator to act on its redemption requests and claims; `isOperator(controller, operator)` reads the flag. Emits `OperatorSet`. **Request reads:** `pendingRedeemRequest(requestId, controller)`, `claimableRedeemRequest(requestId, controller)`, `getRedeemRequest(controller)` (aggregate `RedeemRequestState`), `redemptionState(requestId, controller)` (full `RedemptionState`). ### Redemption controls & policies Cooldown, servicing bounds, and pause flags are global controls; per-account overrides ride on named policies. | Function | Access | Description | | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------- | | `setRedemptionControls(cooldown, maxServiceBatchShares, requestPaused, claimPaused, servicePaused, cancelPaused, serviceAuthority)` | `DEFAULT_ADMIN_ROLE` | Set global cooldown, batch cap, all pause flags, and service-authority metadata | | `setCooldownDuration(uint256 duration)` | `DEFAULT_ADMIN_ROLE` | Update the default cooldown (≤ `MAX_COOLDOWN_DURATION`) while preserving other controls | | `setRedemptionPolicy(bytes32 policyId, RedemptionPolicy policy)` | `DEFAULT_ADMIN_ROLE` | Create/update a named policy (`cooldown`, `maxRequestShares`, `enabled`); default policy cannot be disabled | | `setAccountRedemptionPolicy(address account, bytes32 policyId)` | `DEFAULT_ADMIN_ROLE` | Assign an enabled policy to an account, or clear to the default | | `pauseRedeemRequests` / `pauseRedeemClaims` / `pauseRedemptionServicing` / `pauseRedeemCancellations` | `PAUSER_ROLE` | Pause each redemption sub-flow independently | | `redemptionControls()` / `redemptionPolicy(policyId)` / `accountRedemptionPolicy(account)` | view | Read current controls, a policy, or an account's assigned policy | A request snapshots its `eligibleAt` from the policy in force at request time, so later cooldown changes affect only future requests. The cooldown is configurable up to `MAX_COOLDOWN_DURATION` (90 days); the current value is **7 days**. Emits `RedemptionControlsUpdated`, `RedemptionPolicyUpdated`, `AccountRedemptionPolicyUpdated`, `CooldownDurationUpdated`, and `RedemptionPauseUpdated`. ### Restrictions Two tiers, **soft** (blocks entry and non-self exit) and **full** (freezes the account), gated by `RESTRICTION_ROLE`. Enforcement is centralized in the `_update` share-transfer hook plus per-action checks. | Function | Access | Description | | ------------------------------------------------------------------------------ | ------------------ | ---------------------------------------------------------------------------------- | | `addToBlacklist(address target, bool isFullRestriction)` | `RESTRICTION_ROLE` | Apply soft or full restriction; emits `RestrictionUpdated` | | `removeFromBlacklist(address target, bool)` | `RESTRICTION_ROLE` | Clear all restriction flags | | `redistributeLockedAmount(address from, address to)` | `RESTRICTION_ROLE` | Move all liquid shares off a fully restricted account to an unrestricted recipient | | `redistributeRedeemRequest(uint256 requestId, address controller, address to)` | `RESTRICTION_ROLE` | Relocate an in-flight pending/claimable request away from a frozen account | `getAccountState(account)` reports `shareBalance`, `assetsValue`, both liability buckets, `restrictionStatus` (`CLEAR` / `RESTRICTED` / `FULL_RESTRICTION`), `blockedActions` (`NONE` / `NON_EXIT` / `ALL`), and `restrictionBasis`. ### Admin & introspection | Function | Access | Description | | --------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `setDepositPause(bool paused)` | `DEFAULT_ADMIN_ROLE` | Set the deposit pause flag; emits `DepositPauseUpdated` | | `pauseDeposits()` | `PAUSER_ROLE` | Emergency deposit pause | | `rescueTokens(address token, uint256 amount, address to)` | `DEFAULT_ADMIN_ROLE` | Rescue unrelated tokens or surplus USDx; reverts on the share token (`InvalidToken`) and cannot dip into `requiredAssets` | | `share()` | view | Returns `address(this)` (ERC-7575 vault-is-share) | | `supportsInterface(bytes4)` | view | Advertises ERC-7540 (`IERC7540Operator`, `IERC7540Redeem`), ERC-7575, `IRedemptionManager`, `IRewardManager`, `IVaultShareToken`, `IStakedUSDx` | ### Types ```solidity enum RedemptionStatus { NONE, PENDING, CLAIMABLE, CLAIMED, CANCELLED } struct RedemptionState { uint256 requestId; address controller; address owner; uint256 shares; uint256 assetsReserved; uint256 requestedAt; uint256 eligibleAt; bytes32 policyId; RedemptionStatus status; } struct RedeemRequestState { // per-controller aggregate uint256 pendingShares; uint256 pendingAssets; uint256 claimableShares; uint256 claimableAssets; } struct RedemptionPolicy { uint256 cooldown; uint256 maxRequestShares; bool enabled; } struct RewardState { uint256 accountedAssets; uint256 unvestedRewards; uint256 rewardRate; uint256 periodFinish; uint256 lastUpdated; } ``` ### Events | Event | Source | Parameters | | -------------------------------- | -------------------- | ------------------------------------------------------------------------ | | `Deposit` / `Withdraw` | ERC-4626 | Standard deposit and claim events | | `RedeemRequest` | ERC-7540 | `controller`, `owner`, `requestId`, `sender`, `shares` | | `OperatorSet` | ERC-7540 | `controller`, `operator`, `approved` | | `RewardsFunded` | `IRewardManager` | `funder`, `assets`, `sourceRef`, `rewardRate`, `periodFinish` | | `RewardConfigUpdated` | `IRewardManager` | `authority`, `duration`, `maxRate`, `paused` | | `RedemptionsServiced` | `IRedemptionManager` | `serviceId`, `requestsServiced`, `sharesMadeClaimable`, `assetsReserved` | | `RedeemRequestCancelled` | `IRedemptionManager` | `requestId`, `controller`, `owner`, `sharesReturned`, `assetsReleased` | | `RedemptionControlsUpdated` | `IRedemptionManager` | cooldown, batch cap, four pause flags, service authority | | `RedemptionPolicyUpdated` | `IRedemptionManager` | `policyId`, `cooldown`, `maxRequestShares`, `enabled` | | `AccountRedemptionPolicyUpdated` | `IRedemptionManager` | `account`, `policyId` | | `RedemptionPauseUpdated` | `IRedemptionManager` | `pause` (which flag), `paused` | | `CooldownDurationUpdated` | `StakedUSDx` | `previousDuration`, `newDuration` | | `RestrictionUpdated` | `StakedUSDx` | `target`, `status`, `basis`, `authorityRef` | | `LockedAmountRedistributed` | `StakedUSDx` | `from`, `to`, `shares` | | `RedeemRequestRedistributed` | `StakedUSDx` | `requestId`, `from`, `to`, `shares`, `assets`, `status` | | `DepositPauseUpdated` | `StakedUSDx` | `paused` | | `Rescue` | `StakedUSDx` | `token`, `to`, `amount` | ### Errors | Error | Trigger | | ------------------------- | ------------------------------------------------------------------------------ | | `InvalidZeroAddress()` | Zero address parameter | | `InvalidAmount()` | Zero amount, zero reward duration, over-policy request, or over-surplus rescue | | `OperationNotAllowed()` | Paused flow, restriction violation, disabled preview, or unauthorized caller | | `MinSharesViolation()` | Redeem request exceeds the owner's share balance | | `InsufficientClaimable()` | Claim exceeds the controller's serviced/claimable balance | | `InvalidToken()` | `rescueTokens` targeting the share token | | `InvalidCooldown()` | Cooldown greater than `MAX_COOLDOWN_DURATION` | *** ## Interfaces `StakedUSDx` composes several V2 interfaces, each a frozen review surface: | Interface | Role | | ------------------------------------- | ------------------------------------------------------------------------------ | | `IStakedUSDx` | Top-level vault ABI (composes the below) | | `IRewardManager` | `fundRewards`, `rewardConfig`, `rewardState`, reward events | | `IRedemptionManager` | Async redemption lifecycle, controls, policies, and events | | `IAsyncRedeemVault` | Marker `is IERC7540Redeem`, the async-redeem surface | | `IVaultShareToken` | Accounting reads (`accountedAssets`, `requiredAssets`, `redeemLiabilities`, …) | | `IERC7540Redeem` / `IERC7540Operator` | ERC-7540 async-redeem and operator standard surfaces | # Access Control Reference Technical reference for the V2 role model. Every V2 contract uses standard OpenZeppelin `AccessControlUpgradeable` (surfaced as `IGovernedAccessControl`, `grantRole` / `revokeRole` / `hasRole` / `getRoleAdmin`). There is no bespoke single-admin base and no gatekeeper: authority is expressed as named `*_ROLE` constants, all administered by `DEFAULT_ADMIN_ROLE`, which is held by the **protocol multisig** rather than a hot key. For design rationale, see [Architecture](/technical-and-architecture/architecture). For the public trust model, see [Protocol Administration](/technical-and-architecture/governance). The role vocabulary SSOT is the Protocol Taxonomy (Authority, Governance & Upgrade section). Role constants are defined once protocol-wide and re-exported by each contract; `DEFAULT_ADMIN_ROLE = bytes32(0)`. *** ## Governance model (at launch) At launch, `DEFAULT_ADMIN_ROLE` on every V2 contract is held by the **governance Safe (multisig)**, a geographically-distributed **3-of-5** multisig whose signers are spread across stakeholders inside and outside the Axis Labs team. It is the admin over every other `*_ROLE`, the only authority that can grant or revoke roles. Upgrade authority is held separately: every `ProxyAdmin` is owned by a **`TimelockController`**, so contract upgrades pass through a timelock delay. No hot EOA holds `DEFAULT_ADMIN_ROLE`. {% hint style="warning" %} **Contract upgrades are governed by a `TimelockController`**: an upgrade must pass a timelock delay before it can execute. The delay is set on the `TimelockController` and is verifiable onchain. `DEFAULT_ADMIN_ROLE` is held by the governance Safe (a **3-of-5** signer set), which is **not** itself behind the timelock, the Safe's non-upgrade admin actions execute directly, while proxy upgrades are delayed by the timelock. The exact signer set is published and verifiable onchain. {% endhint %} Authority is organized by **risk direction**: * **Risk-up** changes (grant a role, add a route / channel / custodian / asset, raise a cap) require a deliberate action by the **governance Safe**. Upgrading an implementation is additionally delayed, it passes through the `TimelockController`. Non-upgrade risk-up changes carry no automatic delay window; the control is that they can be made only by the Safe, which acts seldom and out of the ordinary course. * **Risk-down** changes (pause, disable mint/redeem, revoke a hot role, decrease a cap, set a restriction) may execute **immediately** via the dedicated guardian roles below, they do not depend on the admin multisig. Risk direction is not a stored field; it falls out of which role and path a call belongs to. This split lets the protocol tighten instantly in an emergency while every risk-increasing or meaning-changing action is confined to the seldom-acting admin multisig. ### Upgrade authority Every V2 proxy is a `TransparentUpgradeableProxy` with its own `ProxyAdmin`. Upgrade power is **owner-gated**, not a role, `ProxyAdmin.owner()` is a **`TimelockController`**. There is deliberately no `PROXY_ADMIN_ROLE` and no UUPS self-upgrade path in any implementation. Because upgrades are risk-up, they pass through the timelock: an upgrade must clear a timelock delay before it can execute. The delay is set on the `TimelockController` and is verifiable onchain. This upgrade authority is distinct from `DEFAULT_ADMIN_ROLE` (the governance Safe), which is not behind the timelock, the Safe holds day-to-day admin, the timelock holds upgrade authority. *** ## Roles by contract ### `USDx`: the synthetic dollar All balance-changing paths funnel through `_update`, the single enforcement point for pause and restriction checks. | Role | Gates | Capability | | ------------------ | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MARKET_ROLE` | `mint(to, amount)` | Primary market issuance. The **only** live launch supply authority on `USDx`; held by the `USDxMarket` contract so all issuance flows through approved orders. | | `BRIDGE_ROLE` | `bridgeMint`, `bridgeBurn` | Cross-chain supply movement without changing global supply. Defined in code but **not granted at launch**, no live holder; granting it is an admin-multisig action, separately audited. | | `PAUSER_ROLE` | `pause`, `unpause` | Emergency pause/unpause of all token flows. Risk-down guardian. | | `RESTRICTION_ROLE` | `blacklist`, `unBlacklist` | Circle-compatible token-level restriction (freeze, never seize). Held by the Compliance function and intentionally kept outside the admin path for urgent execution. | USDx ships no separate `MINTER_ROLE` / `BURNER_ROLE`: `burn` / `burnFrom` act on the caller's own balance or a spent allowance, and issuance is reachable only via `MARKET_ROLE`. ### `USDxMarket` / `MarketConfig`: the primary market Authority is split by side and by execute-vs-configure. `MINT_OPERATOR_ROLE` / `REDEEM_OPERATOR_ROLE` and `SETTLEMENT_MANAGER_ROLE` live on `USDxMarket`; `SETTLEMENT_MANAGER_ROLE` and `EMERGENCY_ROLE` live on `MarketConfig`. | Role | Gates | Capability | | ------------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MINT_OPERATOR_ROLE` | `settle` (MINT side) | Execute signed/approved mint orders. Executes pre-authorized orders; cannot change what supply means. | | `REDEEM_OPERATOR_ROLE` | `settle` (REDEEM side) | Execute signed/approved redeem orders. | | `SETTLEMENT_MANAGER_ROLE` | `cancelOrder`, route/channel/settlement config | Configure and move within approved settlement paths, and tombstone order hashes. Routine moves immediate; policy expansion (new routes/channels) is an admin-multisig action. | | `EMERGENCY_ROLE` | `pauseCapacity`, disable mint/redeem, remove hot market roles | Risk-**down** only guardian on the market. Cannot increase risk or upgrade. Distinct from token/vault `PAUSER_ROLE`. This is the V2 successor to the V1 "Gatekeeper" role. | The `_OPERATOR` / `_MANAGER` naming is a protocol-wide discipline: `_OPERATOR` roles **execute** approved flows, `_MANAGER` roles **configure/move** within bounds, so a hot executor never gains configuration power. ### `StakedUSDx`: the rewards vault Vault-specific roles, plus the shared `PAUSER_ROLE` and `RESTRICTION_ROLE` (which also operate on the vault). `DEFAULT_ADMIN_ROLE` governs vault config (cooldown, deposit pause, reward config, `rescueTokens`). | Role | Gates | Capability | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `REDEMPTION_SERVICER_ROLE` | `serviceRedemptions`, `serviceRedeemRequest` | Move eligible `PENDING` ERC-7540 redeem requests to `CLAIMABLE`, services the redemption queue. Permissioned and pausable; distinct from the `DEFAULT_ADMIN` control plane. | | `REWARD_MANAGER_ROLE` | `fundRewards`, reward config within bounds | Fund rewards and pause reward funding within bounds; cannot exceed reward bounds. | | `PAUSER_ROLE` *(shared)* | `pauseDeposits`, `pauseRedeemRequests`, `pauseRedeemClaims`, `pauseRedemptionServicing`, `pauseRedeemCancellations`, `pauseRewardFunding` | Risk-down guardian across every vault flow. | | `RESTRICTION_ROLE` *(shared)* | `addToBlacklist`, `removeFromBlacklist`, `redistributeLockedAmount`, `redistributeRedeemRequest` | Set/clear restriction status and relocate a fully restricted account's shares or redeem request to an unrestricted recipient. Can restrict but never mint, burn, seize, settle, upgrade, or service redemptions. | *** ## Permission matrices These tables answer one question: on a given contract, which role may call which function. Two authorities are deliberately absent from them, because they are protocol-wide rather than per-contract: **granting or revoking roles**, and **upgrading an implementation**. Both are in the [privileged-function matrix](#privileged-function-matrix) below, together with whether a timelock applies. ### USDx (token) | Action | Admin (multisig) | Market | Bridge | Pauser | Restriction | | ------------------------------- | ---------------- | ------ | ------------------------ | ------ | ----------- | | `mint()` | ❌ | ✅ | ❌ | ❌ | ❌ | | `bridgeMint()` / `bridgeBurn()` | ❌ | ❌ | ✅ (unassigned at launch) | ❌ | ❌ | | `pause()` / `unpause()` | ❌ | ❌ | ❌ | ✅ | ❌ | | `blacklist()` / `unBlacklist()` | ❌ | ❌ | ❌ | ❌ | ✅ | ### USDxMarket / MarketConfig | Action | Admin (multisig) | Mint Op | Redeem Op | Settlement Mgr | Emergency | | --------------------------------------- | ---------------- | ------- | --------- | ----------------- | --------- | | `settle()` MINT | ❌ | ✅ | ❌ | ❌ | ❌ | | `settle()` REDEEM | ❌ | ❌ | ✅ | ❌ | ❌ | | `cancelOrder()` | ❌ | ❌ | ❌ | ✅ | ❌ | | Set routes / channels / caps (expand) | ✅ | ❌ | ❌ | ✅ (within bounds) | ❌ | | `pauseCapacity()` / disable mint-redeem | ❌ | ❌ | ❌ | ❌ | ✅ | | Remove hot market roles | ✅ | ❌ | ❌ | ❌ | ✅ | ### StakedUSDx (vault) | Action | Admin (multisig) | Redemption Servicer | Reward Mgr | Pauser | Restriction | | ------------------------------------------------------------ | ---------------- | ------------------- | ---------- | ------ | ----------- | | `serviceRedemptions()` | ❌ | ✅ | ❌ | ❌ | ❌ | | `fundRewards()` | ❌ | ❌ | ✅ | ❌ | ❌ | | Pause any vault flow | ❌ | ❌ | ❌ | ✅ | ❌ | | `addToBlacklist()` / `removeFromBlacklist()` | ❌ | ❌ | ❌ | ❌ | ✅ | | `redistributeLockedAmount()` / `redistributeRedeemRequest()` | ❌ | ❌ | ❌ | ❌ | ✅ | | Set cooldown / deposit pause / reward config / rescue tokens | ✅ | ❌ | ❌ | ❌ | ❌ | {% hint style="danger" %} `redistributeLockedAmount()` and `redistributeRedeemRequest()` move a fully restricted account's shares or redeem request to an unrestricted recipient and cannot be canceled after execution. Both are gated by `RESTRICTION_ROLE`, require a non-restricted destination, and are the compliance recovery path for frozen positions, offsetting a move requires new authorized actions. {% endhint %} *** ## Privileged-function matrix The table below summarizes which authority controls each privileged function, and whether any timelock delay applies. Two authorities are distinct: **contract upgrades** are governed by a **`TimelockController`** (the owner of every `ProxyAdmin`), so an upgrade must clear a timelock delay before it can execute; the **governance Safe** holds `DEFAULT_ADMIN_ROLE` and is **not** behind the timelock, so its non-upgrade admin actions execute directly (the control there is that only the seldom-acting Safe can take them). Risk-down guardian actions are immediate by design. The timelock delay is set on the `TimelockController` and is verifiable onchain. | Privileged function | Controlling authority | Timelock delay | | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------ | | Grant / revoke any role | Governance Safe (`DEFAULT_ADMIN_ROLE`) | None (Safe action, not behind timelock) | | Upgrade an implementation | `TimelockController` (owns `ProxyAdmin`) | **Yes, passes the timelock delay** (set onchain) | | Add asset / route / channel / custodian, raise a cap | Governance Safe (`DEFAULT_ADMIN_ROLE`); routine moves within bounds via `SETTLEMENT_MANAGER_ROLE` | None (Safe action, not behind timelock) | | Grant `BRIDGE_ROLE` | Governance Safe (unassigned at launch) | None (Safe action, not behind timelock) | | `pause` / `unpause` token or vault | `PAUSER_ROLE` (guardian) | Immediate (risk-down) | | `pauseCapacity` / disable mint-redeem / remove hot market roles | `EMERGENCY_ROLE` (guardian) | Immediate (risk-down) | | `blacklist` / restriction set-clear | `RESTRICTION_ROLE` (Compliance) | Immediate (risk-down) | *** ## Role definitions > ### MARKET\_ROLE > > **Contract:** `USDx` **Scope:** Primary market issuance, the only role that can call `mint`, and the only live launch supply authority on the token. Held by the `USDxMarket` contract so all issuance flows through approved orders. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capability:** `mint(address to, uint256 amount)` > ### BRIDGE\_ROLE > > **Contract:** `USDx` **Scope:** Cross-chain supply movement via `bridgeMint` / `bridgeBurn`, moving USDx between chains without changing global supply. Defined in code but **not granted at launch**, no live holder; granting it is an admin-multisig action, separately audited. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capabilities:** `bridgeMint(address, uint256)`, `bridgeBurn(uint256)` > ### PAUSER\_ROLE > > **Contract:** `USDx` + `StakedUSDx` **Scope:** Risk-down emergency authority to pause/unpause token and vault flows. Distinct from the market `EMERGENCY_ROLE`. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capabilities:** `USDx.pause` / `unpause`; `StakedUSDx.pauseDeposits`, `pauseRedeemRequests`, `pauseRedeemClaims`, `pauseRedemptionServicing`, `pauseRedeemCancellations`, `pauseRewardFunding` > ### RESTRICTION\_ROLE > > **Contract:** `USDx` + `StakedUSDx` **Scope:** Set/clear restriction status across the token and vault; freeze, never seize. Held by the **Compliance** function and intentionally kept outside the admin path for urgent execution. Can restrict but never mint, burn, seize, settle, upgrade, service redemptions, or move collateral. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capabilities:** `blacklist` / `unBlacklist`; `addToBlacklist`, `removeFromBlacklist`, `redistributeLockedAmount`, `redistributeRedeemRequest` > ### MINT\_OPERATOR\_ROLE / REDEEM\_OPERATOR\_ROLE > > **Contract:** `USDxMarket` **Scope:** Operations authority to execute signed/approved mint (resp. redeem) orders via `settle`. Executes pre-authorized orders; cannot change supply meaning or configure the market. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capability:** `settle(Order, Signature, bytes)` on the respective side > ### SETTLEMENT\_MANAGER\_ROLE > > **Contract:** `USDxMarket` + `MarketConfig` **Scope:** Configure settlement (routes, channels, caps) and move collateral through approved settlement paths; tombstone order hashes via `cancelOrder`. Routine moves are immediate; policy expansion is an admin-multisig action. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capability:** `cancelOrder(Order)`, settlement configuration > ### EMERGENCY\_ROLE > > **Contract:** `MarketConfig` **Scope:** Risk-**down** only guardian on the market, pause capacity, disable mint/redeem, remove hot market roles. Cannot increase risk or upgrade. Distinct from token/vault `PAUSER_ROLE`. Successor to the V1 "Gatekeeper" role. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capabilities:** `pauseCapacity`, disable mint/redeem > ### REDEMPTION\_SERVICER\_ROLE > > **Contract:** `StakedUSDx` **Scope:** Make approved async (ERC-7540) redemption requests claimable, services the redemption queue. Permissioned and pausable; distinct from the `DEFAULT_ADMIN` control plane. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capabilities:** `serviceRedemptions(maxShares)`, `serviceRedeemRequest` > ### REWARD\_MANAGER\_ROLE > > **Contract:** `StakedUSDx` **Scope:** Fund rewards, set reward config, and pause reward funding within bounds; cannot exceed reward bounds. **Admin:** `DEFAULT_ADMIN_ROLE` (protocol multisig) **Key capability:** `fundRewards(uint256 assets, bytes32 sourceRef)` *** ## Key constraints * `DEFAULT_ADMIN_ROLE` is held only by the **governance Safe** (a **3-of-5** multisig) at launch, never a hot EOA. It is the admin over every other role, and it acts seldom. * **Contract upgrades are governed by a `TimelockController`** (the owner of every `ProxyAdmin`): an upgrade must pass a timelock delay before it can execute. The delay is set on the `TimelockController` and is verifiable onchain. This upgrade authority is separate from the governance Safe, the Safe holds day-to-day admin (`DEFAULT_ADMIN_ROLE`) and is not itself behind the timelock. Non-upgrade risk-up changes (role grants, cap increases, new routes/channels/custodians/assets) are direct Safe actions with no enforced delay; risk-down changes (pause, cap decrease, revoke hot role, restrict) execute immediately via guardian roles. * Upgrades are owner-gated through `ProxyAdmin` (owner = `TimelockController`), not a role; there is no `PROXY_ADMIN_ROLE` and no UUPS self-upgrade. * `BRIDGE_ROLE` has no live holder at launch; granting it is an admin-multisig action, separately audited. * `RESTRICTION_ROLE` can freeze but never seize funds, and cannot mint, burn, settle, upgrade, or service redemptions. * Operators (`*_OPERATOR_ROLE`) execute approved flows but never gain configuration authority (`*_MANAGER_ROLE`). # Contract Addresses Official deployment addresses for Axis Protocol. {% hint style="info" %} This is a **Reference** page. For design rationale, see [Architecture](/technical-and-architecture/architecture). For interaction instructions, see [Mint & Redeem](/usdx-the-synthetic-dollar/mint-and-redeem). {% endhint %} {% hint style="danger" %} **Security Warning:** Only interact with the addresses listed on this official page. Be wary of addresses shared in Discord DMs or Telegram groups. Always verify the address in your wallet's confirmation screen before signing a transaction. {% endhint %} {% hint style="info" %} **V2 · Ethereum · live.** The audited (OpenZeppelin) V2 contracts are deployed on Ethereum mainnet. The official Ethereum mainnet addresses are listed on this page. Do not trust any address not listed here. {% endhint %} *** ## Address Format All addresses use EIP-55 mixed-case checksums. If your wallet or tooling normalizes to lowercase, verify the checksum matches before interacting. *** ## Ethereum Mainnet: Canonical V2 **Status:** Deployed · **Version:** V2 · **Chain:** Ethereum · **Chain ID:** `1` V2 is the **canonical deployment of USDx on Ethereum**. The contracts below are the canonical V2 set; their official Ethereum addresses are published in this table below. No onchain address is authoritative unless it appears here. Treat any address not listed on this page as unofficial. The V2 contracts are upgradeable. Every protocol address below is a **proxy** address, and integrations should use these proxy addresses rather than any implementation address. | Contract | Role | Address | | -------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | `USDx` | Axis Dollar (synthetic dollar token) | [`0xa1fA7777974312f7d801A8880714a218F76233f8`](https://etherscan.io/address/0xa1fA7777974312f7d801A8880714a218F76233f8) | | `USDxMarket` | Primary market: mint and redeem settlement | [`0x5aE365Ac83638418c4c30555d32F9A91ccAEf58C`](https://etherscan.io/address/0x5aE365Ac83638418c4c30555d32F9A91ccAEf58C) | | `MarketConfig` | Market parameters and configuration | [`0xce2cF8B00FCb5946F495ebD15ff9F0001E024D46`](https://etherscan.io/address/0xce2cF8B00FCb5946F495ebD15ff9F0001E024D46) | | `StakedUSDx` | Axis Rewards Vault (staked USDx) | [`0xEB892628D1E58BC475A6dCB7F5dBC4F591632AA4`](https://etherscan.io/address/0xEB892628D1E58BC475A6dCB7F5dBC4F591632AA4) | {% hint style="danger" %} **Check the whole address, not the first few characters.** The V2 `USDx` token on Ethereum (`0xa1fA7777...33f8`) and the legacy V1 `AxisUSD` token on Plasma (`0xA1FA7777...8387`) share their first eight hex characters. Wallets that abbreviate an address to a short prefix will show the same leading digits for both. Verify the full 40-character address, and check that you are on the right chain, before you sign. {% endhint %} {% hint style="info" %} `RewardManager` and `RedemptionManager` are **not** separate deployed contracts. They are interfaces (`IRewardManager`, `IRedemptionManager`) that `StakedUSDx` implements in-vault: reward funding/vesting and the async-redemption lifecycle live inside `StakedUSDx.sol`, so there is no standalone address for either. See [Staking Contracts Reference](/reference/staking-contracts). {% endhint %} ### Governance, upgrade authority & operators `DEFAULT_ADMIN_ROLE` over the V2 contracts is held by a **governance Safe** (multisig), being finalized to a **3-of-5** signer set. **Upgrade authority is separate: a `TimelockController`** owns the proxy-upgrade path, so contract upgrades pass through a timelock delay. Mint and redeem orders are settled by KMS-secured operator wallets. The deployer retains no ongoing authority. For the full role map, see [Access Control](/reference/access-control). | Component | Role | Address | | -------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | Governance Safe | `DEFAULT_ADMIN_ROLE` (admin over all roles) (finalizing to 3-of-5) | [`0xdeB538917b1C1AE6B81550a6C42A66d818cc6d6D`](https://etherscan.io/address/0xdeB538917b1C1AE6B81550a6C42A66d818cc6d6D) | | `TimelockController` | Upgrade authority: proxy upgrades pass the timelock | [`0xd6BB04711E41aa41b9130Ad41eE6884755914c0b`](https://etherscan.io/address/0xd6BB04711E41aa41b9130Ad41eE6884755914c0b) | | Mint operator | Settles signed mint orders (KMS-secured) | [`0xDEca86926d2AEc9C3B0eEEB54AAcfDe6d0249370`](https://etherscan.io/address/0xDEca86926d2AEc9C3B0eEEB54AAcfDe6d0249370) | | Redeem operator | Settles signed redeem orders (KMS-secured) | [`0xde195DeCA3b698584Aa106cDEA77bBAb0EDcAb03`](https://etherscan.io/address/0xde195DeCA3b698584Aa106cDEA77bBAb0EDcAb03) | | Deployer | No ongoing authority | [`0x12dDC1D11605A78761c1c8475F0B487e3375CE63`](https://etherscan.io/address/0x12dDC1D11605A78761c1c8475F0B487e3375CE63) | ### Accepted collateral & custody | Item | Address | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------- | | USDC (accepted deposit) | [`0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`](https://etherscan.io/address/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48) | | USDT (accepted deposit) | [`0xdAC17F958D2ee523a2206206994597C13D831ec7`](https://etherscan.io/address/0xdAC17F958D2ee523a2206206994597C13D831ec7) | | Custodian (deposit) | [`0x0D0491260f18281CA59EF110F907fA69dA0FF519`](https://etherscan.io/address/0x0D0491260f18281CA59EF110F907fA69dA0FF519) | *** ## Other Chains Token contracts on chains other than Ethereum are **not yet deployed**. No addresses are published for other chains at this time; any address claimed for USDx on another chain is unofficial. *** ## Legacy: V1 · Plasma (private beta) {% hint style="warning" %} **Legacy: V1 on Plasma, private beta.** The addresses below are the V1 deployment on Plasma. V1 is the deprecating private-beta deployment and serves existing beta holders only. New users should follow the V2 flow on Ethereum. {% endhint %} **Status:** Deployed (deprecating) Addresses link to Plasmascan. | Contract | Role | Address | | --------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | `AxisUSD` | V1 token | [`0xA1FA77779e6866fa3eF48FC0720657E042158387`](https://plasmascan.to/address/0xA1FA77779e6866fa3eF48FC0720657E042158387) | | `AxisUSDMinting` | V1 mint and redeem | [`0xa4B199087d34A03718eF2c80c8103c711a990cD9`](https://plasmascan.to/address/0xa4B199087d34A03718eF2c80c8103c711a990cD9) | | `StakedAxisUSDV2` | V1 staked AxisUSD vault | [`0x13A099765B34b3aAFedb8698CF7fd418E7730012`](https://plasmascan.to/address/0x13A099765B34b3aAFedb8698CF7fd418E7730012) | | `AxisUSDSilo` | Staking silo | [`0xa17Da86D6EfDa0cfa1B2b2209426c7Fce0d8125d`](https://plasmascan.to/address/0xa17Da86D6EfDa0cfa1B2b2209426c7Fce0d8125d) | | `StakingRewardsDistributor` | Staking rewards distribution | [`0x59d8F09032d859F8731EfA4aC837978D5E8467F1`](https://plasmascan.to/address/0x59d8F09032d859F8731EfA4aC837978D5E8467F1) | | `AxisUSDRateProvider` | Rate provider | [`0x24891F7852021413D4AcB0641994d045eEaDc9bE`](https://plasmascan.to/address/0x24891F7852021413D4AcB0641994d045eEaDc9bE) | {% hint style="warning" %} Always verify addresses against the tables above. Do not copy addresses from unofficial sources or unverified code snippets. {% endhint %} # FAQ ## Is this a stablecoin? No. USDx is **the Axis Dollar**, a **synthetic dollar**, not a stablecoin. It is dollar-denominated and backed by a portfolio of assets held by the protocol, but it is not a bank deposit, not an insured product, and not a conventional collateralized stablecoin. Its backing is an actively-managed trading portfolio, so USDx **carries risk** and can lose value, and it is not designed as a payments instrument. See [What is USDx?](/usdx-the-synthetic-dollar/usdx). ## Is this a hedge fund? No. Axis is a **protocol**, not a fund. You are not buying an interest in a fund, a share class, or a managed account. You hold USDx, a synthetic dollar, and you can stake it for sUSDx to become eligible for rewards. There is no subscription, no fund interest, and no claim on a manager's book; you interact directly with onchain contracts. See [What is Axis?](/start-here/what-is-axis). ## Why should I care? Global assets, crypto, commodities, tokenized equities, and increasingly traditional assets, trade across many venues, currencies, and jurisdictions, and that liquidity is **fragmented**. As more of the world's assets move onchain, someone has to make those markets and move liquidity to where it is needed. That is what Axis does. See [Size of the Opportunity](/start-here/market-context). ## How do I use it? Three steps: 1. **Get USDx.** Acquire USDx on the secondary market, or, if you are an approved counterparty, mint it directly on the [USDx Primary Market](/usdx-the-synthetic-dollar/mint-and-redeem). 2. **Stake for sUSDx.** Stake USDx to receive sUSDx and become eligible for the protocol's reward distributions, holding USDx alone earns nothing. 3. **Earn rewards.** sUSDx grows in USDx terms as rewards accrue, with no rebasing and no manual claim required. See [Stake & Unstake USDx](/susdx-the-rewards-vault/stake-and-unstake). ## What are the risks? Participation can result in partial or total loss. USDx backing is an actively-managed trading portfolio exposed to market, liquidity, execution, funding, venue, counterparty, custody, smart contract, and operational risk, and delta-neutral does not mean risk-free. Read the [Risk Overview](/risk/risk-overview) and the [Disclosures](/resources-and-legal/compliance) before interacting. ## Who's behind it? Axis is built by a team with years of experience across leading firms in trading, stablecoins, and onchain markets, including experience at Circle, Tether, Alphanonce, QCP, hedge funds, Ondo, yield protocols, and leading centralized and decentralized exchanges. ## Where can I access it? Access to Axis interfaces is restricted in Belarus, Cuba, the Democratic Republic of the Congo, Iran, Libya, Myanmar, North Korea, Russia, Somalia, South Sudan, Sudan, Syria, the United States, and Yemen. USDx and sUSDx are **not offered to US persons**. They are also not offered anywhere that offering them would be unlawful. Availability also depends on the interface or service used, the applicable terms, and local law. See [Disclosures](/resources-and-legal/compliance). ## What can I do with USDx? USDx is built for onchain use. Its reserves are actively managed to stay liquid, which supports its adoption across DeFi, building onchain liquidity, integrating with onchain oracles, and serving as collateral in DeFi lending markets. The goal is for USDx to be a productive, dollar-denominated building block wherever onchain markets need liquidity. ## What is the opportunity? Tokenized and capital markets are enormous, and as they grow they will be **fragmented** across venues, currencies, and jurisdictions. Someone has to provide the liquidity that ties those markets together and lets capital move to where demand is. That is the role Axis is built to fill. See [Size of the Opportunity](/start-here/market-context). ## Who backs Axis? Axis is backed by Galaxy, OKX, FalconX, CMT Digital, and Steakhouse. # Eligibility & Onboarding This page describes who can apply for direct access to the [USDx Primary Market](/usdx-the-synthetic-dollar/mint-and-redeem), what the review covers, and the steps an applicant goes through. It sits alongside the [Disclosures](/resources-and-legal/compliance), which set out the restrictions that apply to Axis interfaces, and it does not replace the terms of any interface or service. ## Two different questions Interface access and eligibility for the primary market are separate decisions, and both apply. * **Interface access** is restricted in the jurisdictions listed in [Disclosures](/resources-and-legal/compliance). USDx and sUSDx are not offered to US persons, and they are not offered anywhere that offering them would be unlawful. * **Eligibility for the primary market** is an account-level review. It applies to parties that want to mint or redeem USDx directly with the protocol, rather than acquire USDx on the secondary market. Anyone can hold USDx. Minting and redeeming directly requires an approved account. ## Where we accept applications We accept applications from counterparties outside the jurisdictions where access to Axis interfaces is restricted. Those restrictions apply to the primary market as well, and [Disclosures](/resources-and-legal/compliance) lists them. We do not currently accept applications from: * the United States, or from US persons; * any jurisdiction subject to sanctions, or from any party that is itself the subject of sanctions. Applications from the EU and EEA are reviewed individually under enhanced due diligence, which requires more evidence of ownership and control than the standard review. Eligibility is assessed for each applicant and each interface rather than by country alone. Which entity makes a given interface or service available to you is identified in the terms presented at that interface. Accepting an application is not a promise of access, and where we accept applications can change as regulation and our arrangements change. ## Who can apply **Entities** apply for business verification: the legal entity, its ownership and control, and the people authorised to act for it. **Individuals** apply on the same basis and are additionally assessed against the accredited investor criteria set out in the onboarding form. We do not offer direct access to the primary market to retail participants at this stage. ## What we ask for, and when We ask for information in stages, and we do not ask for documents until your jurisdiction and profile have been confirmed as eligible. 1. **Expression of interest.** The entity or individual, the jurisdiction, and the intended use of USDx. No documents. 2. **Verification.** Documents, described below, and screening. This stage is carried out by an independent compliance provider engaged by Axis. 3. **Agreement and wallet approval.** Signed terms, and the wallet address recorded as permitted to mint and redeem. **Entities.** Certificate of incorporation or registration, constitution or equivalent governing document, certificate of incumbency, register of directors, register of shareholders, a certified ownership and control structure chart traced to natural persons holding 25% or more, the list of authorised signatories, proof of business address, and tax self-certification. **Individuals.** Government-issued identification, proof of residential address, and evidence of accredited investor status or a signed declaration. **Both.** Source of funds and source of wealth, and screening against sanctions, politically exposed person and adverse media lists. ## The process | Stage | What happens | Typical time | | ---------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------- | | Expression of interest | You tell us who you are, where you are established, and how you intend to use USDx | First response within 2 business days | | Verification | Documents reviewed and screening completed by the compliance provider | 3 business days once documents are complete | | Wallet approval | The wallet address permitted to mint and redeem is recorded | 1–2 business days | | Agreement | Terms reviewed and signed | 1–2 business days | The whole process usually takes about two weeks. Verification is the longest stage where documentation is incomplete, and incomplete or uncertified documents are the most common cause of delay. ## Minimum Direct participation currently has a minimum initial amount of US$1,000,000. Acquiring USDx on the secondary market has no minimum. ## What approval covers Approval is specific to the verified entity and to the wallet address recorded at onboarding. It does not extend to a different entity, a different wallet, or a different purpose. We screen on an ongoing basis, and access can be suspended or withdrawn if circumstances change. See [Access Control](/reference/access-control) for the onchain permissions that govern minting and redemption. ## How to apply Email with the entity or individual name, the jurisdiction, and the intended use of USDx. We will confirm eligibility and send the onboarding form and verification steps. Before applying, read the [Risk Overview](/risk/risk-overview) and the [Risk Disclosure](/resources-and-legal/risk-disclosure). Participation can result in partial or total loss. # Brand Assets Logos for Axis, USDx, sUSDx, and Coordinates. These are the official marks. Please use them as supplied rather than redrawing or recolouring them. ## Axis The wordmark is the default. Use the icon on its own only where the wordmark will not fit legibly, such as an avatar, a favicon, or a token list. ![Axis wordmark](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-a4303f266cb849b99b3b4bae0e965bfc2796b759%2Faxis-wordmark-light.svg?alt=media) ![Axis icon](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-1ac4856c7938876d31eb927a50cb52afe45ba9cf%2Faxis-icon.svg?alt=media) Reversed versions of both, for dark backgrounds, are in the downloads below. ## Tokens | | Mark | Token | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | -------------------------- | | ![USDx](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-50dba086a934fbe556d5216e18b38173ed5bc48c%2Fusdx.svg?alt=media) | USDx | The Axis Dollar | | ![sUSDx](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-dcc16e5a0cd3e08f38d3fdefd134f8a3f6003b31%2Fsusdx.svg?alt=media) | sUSDx | The rewards vault position | | ![Coordinates](https://2477139792-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1qpxd00p4nKGSXWm7QiH%2Fuploads%2Fgit-blob-85a36b2faf09e2180a2d41176d5f49abb7b80a3d%2Fcoordinates-gold.svg?alt=media) | Coordinates | The Axis rewards points | ## Downloads All marks are SVG, so they scale to any size without loss. **Axis wordmark** {% file src="/files/7xhx1CWja9SCzmUi1sAq" %} {% file src="/files/ezQeZ0CR4bNZFMgtpAF9" %} **Axis icon** {% file src="/files/lOgw8tKuGrQ9f9E7mbBV" %} {% file src="/files/QPWPztsW26qS0mQGQgqC" %} **Tokens and points** {% file src="/files/S39mY0LiwYr1TG40Cp8C" %} {% file src="/files/89iFXB998fwVHXTdSKXJ" %} {% file src="/files/RVT1zmxQXBunxe2dFhfK" %} ## Using the marks * Keep clear space around a mark of at least the height of the icon. * Do not stretch, rotate, recolour, add effects to, or reconstruct any mark. * Do not place a mark on a background that leaves it hard to read. Use the reversed version instead. * Do not use an Axis mark to imply a partnership, endorsement, or listing that does not exist. For a format not provided here, get in touch rather than improvising. # Disclosures This documentation explains the Axis protocol and its technical design. It is not legal, tax, investment, or accounting advice, and it does not replace the terms that govern access to any Axis interface or service. ## No guarantee USDx and sUSDx are not bank deposits and are not described here as insured products. Axis does not guarantee: * that USDx will trade at exactly $1; * a fixed or minimum sUSDx return; * continuous minting, redemption, trading, or withdrawal; * the availability or value of collateral; * that software, custodians, venues, counterparties, or operators will perform without failure. sUSDx yield is variable and is earned, not promised: it comes from Axis's structural edge in cross-venue and cross-asset fragmentation, a durable, market-neutral 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. See [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield) for where the yield originates. ## Eligibility and local law Eligibility for the USDx Primary Market is set out in [Eligibility & Onboarding](/resources-and-legal/eligibility-and-onboarding). Holding USDx is not restricted in the same way, but availability can depend on the interface or service used, applicable terms, and local law. Users are responsible for reviewing the terms presented by the relevant access point and obtaining professional advice where appropriate. ## Restricted jurisdictions Access to Axis interfaces is restricted in Belarus, Cuba, the Democratic Republic of the Congo, Iran, Libya, Myanmar, North Korea, Russia, Somalia, South Sudan, Sudan, Syria, the United States, and Yemen. USDx and sUSDx are **not offered to US persons**. They are also not offered anywhere that offering them would be unlawful. Access may be further restricted by the terms of the relevant interface or service. ## Protocol controls At launch, the V2 contracts will include role-based controls and address-restriction functionality. Authorized roles will be able to restrict addresses, change supported assets, custodians, and settlement routes, adjust primary-market capacity caps, configure the redemption cooldown and servicing, and disable minting and redemption. These powers create administrative and censorship risks even when used for security or compliance purposes. Redemption of sUSDx is designed as an asynchronous (ERC-7540) flow, request, servicing by an operator, then claim, rather than an instant withdrawal, so a request may remain pending until it is serviced. See [Access Control](/reference/access-control) for the exact contract permissions. ## Risk disclosure The full statement is set out in the [Risk Disclosure](/resources-and-legal/risk-disclosure), which covers the nature of USDx and sUSDx, technology, platform changes, regulatory, jurisdiction, and further risks. Participation can result in partial or total loss. Review the [Risk Overview](/risk/risk-overview), [How USDx Targets $1](/usdx-the-synthetic-dollar/peg-stability), [How Axis Earns Yield](/susdx-the-rewards-vault/how-axis-earns-yield), and [Security Overview](/backing-reserves-and-transparency/security) before interacting. Any performance figures published for the V1 private beta or earlier strategy composites are **legacy history**. They describe a different, prior deployment, are not part of the V2 protocol disclosed here, and are not indicative of V2 results. ## Documentation status Protocol parameters, supported assets, contract state, and access conditions can change, and the parameters above are set by the protocol. Verify current onchain state and the terms of the interface you use; do not rely on an example or historical statement as a guarantee of current availability. # Risk Disclosure The purpose of this Risk Disclosure Statement (this "Risk Disclosure") is to describe certain risks associated with accessing or using the Axis Platform, the Axis Protocol, USDx, sUSDx and any related products or services. This Risk Disclosure should be read together with any other agreements or policies made available in connection with the Platform. Terms used in this Risk Disclosure are defined in [Defined terms](#defined-terms) below. Where a Terms of Use is published, that document and its definitions will govern. While this Risk Disclosure describes a number of key risks, it does not identify every risk that may arise in connection with the Platform, the Protocol or Digital Assets generally. Additional risks, whether known or unknown, may arise over time as technology, markets and regulatory frameworks evolve. Before using the Platform, you should carefully consider whether doing so is appropriate in light of your financial circumstances, risk tolerance and investment objectives. By accessing or using the Platform, you acknowledge that you have read this Risk Disclosure, understand that the Platform involves financial, technological and regulatory risks, and accept those risks. ## Defined terms * **Platform** means the Axis Protocol together with the interfaces, applications and services made available in connection with it. * **Protocol** or **Axis Protocol** means the onchain smart contracts implementing USDx, the USDx primary market and the sUSDx rewards vault. * **Services** means the services made available through the Platform. * **Digital Assets** means cryptographic tokens and assets recorded on a blockchain, including USDx and sUSDx. * **Applicable Law** means the laws, regulations, rules and regulatory guidance applicable to you, to the Company or to the Platform. * **Company** means the entity that makes the relevant interface or service available to you, as identified in the terms presented at that interface. USDx is issued by **Coordinate Origin Limited**, a British Virgin Islands company. The Axis software is developed by **Coordinate Labs Pte Ltd**, a Singapore company. Which entity makes a given interface or service available to you is identified in the terms presented at that interface. ## Nature of USDx and sUSDx USDx is not legal tender, a bank deposit, electronic money or stored value, and is not insured or guaranteed by any government, central bank or deposit protection scheme. Although the Axis Protocol facilitates the minting and redemption of USDx, this mechanism is not intended to, and does not, guarantee that USDx will always maintain parity with the U.S. dollar. sUSDx is a protocol token that represents your proportional interest in staked USDx together with any rewards accrued in accordance with the Protocol. Holding sUSDx does not entitle you to a fixed or guaranteed rate of return, and the Protocol does not promise or guarantee any minimum, fixed or projected rewards. Past reward levels are not indicative of future performance. The availability of primary minting and redemption is subject to the Protocol's eligibility, operational and compliance requirements. In addition, the availability and pricing of USDx and sUSDx on secondary markets will depend on market participants and liquidity. The Company does not guarantee the availability of primary minting or redemption at all times or the existence of an active or liquid secondary market. ## Technology risks The Platform and the Axis Protocol rely on blockchain networks, smart contracts and other technology that may be subject to bugs, vulnerabilities, cyberattacks or other technical failures. Although the Company seeks to maintain the security and reliability of the Platform, interruptions, delays or unexpected outcomes may occur. The Platform also depends on third-party infrastructure and other service providers that are outside the Company's control. Disruptions affecting such third parties may impact the availability or operation of the Platform. Transactions recorded on a blockchain are irreversible once confirmed. You should carefully review all transaction details before authorising any transaction through the Platform. By accessing or using the Platform, you acknowledge and accept the technological risks associated with blockchain networks, smart contracts and decentralised systems, and understand that such risks may affect the availability, functionality and operation of the Platform or the Protocol. ## Platform changes The Company may, from time to time, implement upgrades, modifications or other changes to the Platform or the Protocol to improve functionality, address security concerns, comply with Applicable Law or respond to changing market conditions. Such changes may alter the operation of the Protocol, affect the availability of certain features or require temporary suspension of Services. References to planned or future functionality should not be relied upon as a commitment that such functionality will be made available. While the Company will endeavour to minimise disruption where reasonably practicable, it cannot guarantee uninterrupted access to the Platform or that any upgrade or modification will be free from unintended consequences. ## Regulatory and legal risks The regulatory treatment of digital assets continues to evolve and may differ across jurisdictions. Changes in applicable laws, regulations, regulatory guidance or governmental actions may affect the availability, operation or use of the Platform, the Axis Protocol, USDx, sUSDx or the Services. To comply with applicable legal or regulatory requirements, the Company may modify, suspend or discontinue certain Services, impose additional eligibility or compliance requirements, or restrict access to the Platform in certain jurisdictions. You are responsible for ensuring that your access to and use of the Platform complies with the laws applicable to you, including any tax, reporting or other legal obligations arising from your use of the Platform. ## Jurisdiction risk Access to the Platform and certain Services may be restricted or unavailable in particular jurisdictions. Changes to your place of residence, domicile, tax residency, citizenship or Applicable Laws may affect your eligibility to access or use the Platform or certain Services. Where necessary to comply with Applicable Laws or regulatory requirements, the Company may restrict, suspend or terminate your access to the Platform or any Service. You are solely responsible for ensuring that your access to and use of the Platform remains lawful at all times. The jurisdictions in which access is currently restricted are listed under [Restricted jurisdictions](/resources-and-legal/compliance#restricted-jurisdictions). ## Further risks The following risks are additional to those described above. **Risk of loss.** Interacting with USDx, sUSDx and the Axis Protocol carries a risk of financial loss, including the partial or total loss of any assets you deposit, stake or hold. You should only participate with assets you can afford to lose entirely, and you are solely responsible for your own decisions. **Loss of value.** The value of USDx and sUSDx can fall as well as rise, and can fall to zero. USDx is backed by an actively-managed portfolio of assets and is not a promise of a fixed value. USDx may trade below its target, its backing may decline in value, and sUSDx rewards are discretionary, variable and not guaranteed. **Liquidity and redemption.** There may be limited or no liquidity to buy or sell USDx or sUSDx when you wish to, and no guaranteed price or depth on any market. Primary-market minting and redemption are available only to approved counterparties, and secondary-market and unstaking exits depend on available liquidity, capacity, servicing and prevailing market conditions. Redemptions may be delayed, queued, throttled or unavailable. **Market forces.** Prices, funding rates, spreads and trading opportunities are driven by market forces outside the Company's control. Volatility, dislocation, correlation breakdowns and adverse moves can reduce or reverse expected returns and can impair the value of the backing. A market-neutral or delta-neutral posture reduces a defined directional exposure at a point in time; it does not eliminate risk. **Financial crime.** Digital Assets can be associated with fraud, theft, scams, market manipulation, money laundering and other financial crime. Compliance, screening and address-restriction controls may be applied, and access may be restricted, suspended or reversed as a result. You are responsible for complying with all laws applicable to you. **Absence of control.** You may have little or no control over, and no recourse in respect of, elements of the system on which the Protocol depends, including centralised venues, custodians, counterparties, operators and third-party infrastructure. Privileged roles can restrict addresses, change supported assets, custodians and settlement routes, adjust capacity and cooldown parameters, and pause minting and redemption, which creates administrative and censorship risk. **Third-party risk.** The Platform relies on third parties, including trading venues, custodians, counterparties, wallet and infrastructure providers, auditors and attestation providers, whose failure, insolvency, misconduct, error or withdrawal of service could result in loss. Third-party services are outside the Company's control and are not guaranteed. **Taxation.** You are solely responsible for determining and meeting any tax obligations arising from acquiring, holding, staking, transferring or disposing of USDx, sUSDx or rewards. The tax treatment of Digital Assets is uncertain and varies by jurisdiction. Obtain independent professional advice. ## Acknowledgement By accessing or using the Platform, you acknowledge that: * you have read and understood this Risk Disclosure; * you understand that the use of the Platform, the Axis Protocol and Digital Assets involves financial, technological and regulatory risks; * you have independently assessed whether the Platform and the Services are appropriate for you; and * you accept the risks described in this Risk Disclosure. The information provided in this Risk Disclosure is not a substitute for any professional advice. None of the information provided in this Risk Disclosure constitutes a recommendation that any of our products or services is suitable for any person. You further acknowledge and agree that this Risk Disclosure is neither an offer nor a solicitation to deal in any of our products or services, and you are not relying on any investment, financial, trading advice or recommendation, or any other type of advice or recommendation (whether written or oral) of Axis.