> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ix.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance

> Who controls what in IX RWA — roles, upgrade authority, emergency controls, and the path to multisig / timelock governance.

IX RWA has **no ambient owner**. Every privileged action is a named, least-privilege role, and the authority to change code or parameters is explicit and on-chain. This page is the single reference for who can do what, and how that control decentralizes on the way to mainnet.

## Roles & permissions

| Role                     | Held by (testnet)                                                      | Can                                                                                   |
| ------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| `DEFAULT_ADMIN_ROLE`     | Protocol admin                                                         | Set fee params, fee recipient, reserve/oracle pointers, register/retire assets, pause |
| `ORACLE_UPDATER_ROLE`    | AttestorRegistry (intended sole updater; EOA path revoked pre-mainnet) | Write cohort values into the NAV oracle                                               |
| `ATTESTOR_ROLE`          | EconomicsFeeder (testnet) → real attestors (mainnet)                   | Submit an attested reserve value + evidence hash                                      |
| `REVENUE_DEPOSITOR_ROLE` | EconomicsFeeder                                                        | Accrue revenue into NAV (`notifyRevenue`)                                             |
| `KEEPER_ROLE`            | Keeper / feeder                                                        | Process the redemption queue; quarantine assets on a bad/stale feed                   |
| `SPENDER_ROLE`           | Vault + keeper                                                         | Pull from the smoothing reserve to cover a shortfall                                  |
| `UPGRADER_ROLE`          | Protocol admin → multisig/timelock                                     | Authorize UUPS implementation upgrades                                                |

Roles are separated by design: the key that feeds revenue cannot upgrade contracts, the keeper that processes redemptions cannot move NAV, and no single key holds everything.

## Upgrade authority

Core contracts are **UUPS proxies**: implementations can be upgraded without changing addresses or migrating balances, and every `_authorizeUpgrade` is gated by `UPGRADER_ROLE`.

```mermaid theme={null}
flowchart LR
    P[Propose upgrade] --> TL[Timelock delay]
    TL --> MS[Multisig / governance approval]
    MS --> EX[Execute upgrade via UPGRADER_ROLE]
    EX --> PX[Proxy points at new implementation]
```

On testnet, upgrade authority is held by the protocol admin for iteration speed. At the audited **Phase-2 redeploy**, `UPGRADER_ROLE` and `DEFAULT_ADMIN_ROLE` move to a **multi-signature wallet behind a timelock**, so upgrades require multiple signers and a public delay before they can execute. The governance-hardening test suite exercises exactly this: an upgrade **reverts without the timelock** and **succeeds only via the timelock after its delay**, the deployer **renounces** its standalone control, and the multisig can pause and set parameters.

## Emergency controls

| Control              | Effect                                                        | Who       |
| -------------------- | ------------------------------------------------------------- | --------- |
| **Pause**            | `Pausable` halts deposits, mints, and redemptions             | Admin     |
| **Oracle staleness** | A stale feed auto-blocks pricing (`NavStale`) until refreshed | Automatic |
| **Quarantine**       | A bad/diverging asset is dropped from NAV until healthy       | Keeper    |
| **Oracle bounds**    | A single NAV update can't move a cohort beyond `maxBps`       | Automatic |

These are containment tools, not backdoors: none of them can move user funds to an arbitrary address, and all are visible on-chain.

## Parameter changes

Fee parameters (entry, exit, management, reserve floor) and pointers (oracle, reserve, fee recipient) are admin-settable, bounded (bps capped at 100%), and emit events (`ParamsSet`, `FeeRecipientSet`, `ReserveSet`). The streaming management fee is settled at the old rate **before** any change, so parameter updates never apply retroactively. See [Fees & terms](/protocol/fees-and-terms).

## Decentralization path

<Steps>
  <Step title="Now (testnet)">
    Single protocol-admin key for fast iteration; all actions on-chain and event-logged.
  </Step>

  <Step title="Phase-2 (audited mainnet)">
    Admin and upgrader roles move to a multisig behind a timelock; the deployer renounces standalone control; the AttestorRegistry becomes the sole NAV writer.
  </Step>

  <Step title="Beyond">
    Progressive decentralization of attestation and parameter governance as the asset base and operator set grow.
  </Step>
</Steps>

<Warning>
  Governance arrangements described for mainnet (multisig, timelock, role renouncement) are the **target end-state**. On testnet the protocol admin retains direct control for iteration. See the [roadmap](/why-ix-rwa#roadmap).
</Warning>