> 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/reference/access-control.md).

# 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.md). For the public trust model, see [Protocol Administration](/technical-and-architecture/governance.md). 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`).


---

# 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/reference/access-control.md?ask=<question>&goal=<endgoal>
```

`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.