> For the complete documentation index, see [llms.txt](https://docs.ensemble.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ensemble.io/safety/governance-and-roles.md).

# Governance and roles

Who can change settings, submit maintenance, and authorize upgrades.

The people who hold administrative keys can change fees, limits, and other settings. Upgrade keys can replace contract code. Review those powers as part of the vault's risk, alongside its market exposure.

## Who can do what

A contract's owner and a maintenance caller have different powers. These are the relevant roles in the recorded production contract revision:

| Role                      | Powers                                                                                             |
| ------------------------- | -------------------------------------------------------------------------------------------------- |
| User or approved operator | Deposit or redeem under current checks; hold and transfer shares when transfers are enabled        |
| Vault owner               | Change supported vault settings and perform gated recovery actions                                 |
| VaultAdmin owner          | Call its owner-only wrappers to administer vaults it owns                                          |
| CircuitBreaker owner      | Configure supported routes, action limits, fee exemptions, and conduits                            |
| Proxy upgrade authority   | Replace the implementation behind a proxy                                                          |
| Maintenance caller        | Request permissionless capital movement, rebalancing, confirmation, or an eligible emergency close |

VaultAdmin can be the owner recorded by a vault. The account that owns VaultAdmin then controls its owner-only calls. Check each ownership relationship rather than assuming all contracts have the same owner. The vault, VaultAdmin, and CircuitBreaker do not expose a separate guardian role in this revision.

## Settings and upgrades

Owner changes must satisfy the checks in the implementation currently deployed. Those checks can bound fees, leverage, execution policy, portfolio transitions, and emergency actions.

An upgrade can change the implementation and its rules, including accounting and access control. The current implementation's bounds are not a guarantee about future code. Review signer controls and the actual ownership and upgrade authority before transacting.

## Maintenance and emergency actions

Ordinary maintenance is permissionless when its on-chain conditions are met. An automated caller cannot choose arbitrary accounting outcomes or bypass those conditions.

`emergencyClose()` also has eligibility checks, with a specific owner cleanup path for permanent emergency state. Emergency capital recovery and enabling emergency withdrawals use privileged owner actions. See [Emergency controls](/safety/emergency-controls.md).

## Changes you can verify

Ownership transfers, parameter changes, pauses, and upgrades are on-chain actions. Read their receipts, events, and current state to establish what changed.

An earlier deployment record can identify the initial arrangement, but ownership and implementation may change afterward. Use [Contract addresses](/protocol-transparency/contract-addresses.md) to identify the production contracts, then check current owners and proxy implementations before relying on them.