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.
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.
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 for the complete permission matrix, Security Overview for the trust boundaries, and Onchain Safety Properties for the invariants these roles must preserve.
Last updated