> For the complete documentation index, see [llms.txt](https://docs.axis.to/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.axis.to/technical-and-architecture/governance.md). # 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.md). ### 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.md) for the complete permission matrix, [Security Overview](/backing-reserves-and-transparency/security.md) for the trust boundaries, and [Onchain Safety Properties](/backing-reserves-and-transparency/security/onchain-safety-properties.md) for the invariants these roles must preserve. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.axis.to/technical-and-architecture/governance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.