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. For the public trust model, see Protocol Administration. 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.

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.

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 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	✅	❌	❌	❌	❌

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.

---

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