> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usecompassai.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Authority & upgrade model
> How Compass ships new venue support without taking custody — a bounded upgrade authority that owners can revoke at any time.
> Compass's Diamond is upgradeable, but the upgrade authority is cryptographically bounded: it can only *add* new venue facets, never replace or remove anything, and the user can revoke it permanently at any moment.
This page covers the upgrade model. For the Diamond's facet structure, see
[Diamond account](/contracts/diamond-account). For the trust assumptions
this model creates, see [Trust & security model](/overview/trust-security).
## The problem
A smart account for autonomous DeFi has a tension at its center:
* If the account is **never upgradeable**, every new venue (new lending
protocol, new chain integration) requires the user to deploy a new
account and migrate funds. This is painful and most users won't do it.
* If the account is **freely upgradeable by anyone other than the owner**,
it's not really the user's account — the upgrader can swap in malicious
facets and drain it.
Compass takes neither extreme. The Diamond is upgradeable, but the
upgrade authority is **bounded in code** to what it can change, and the
user holds an unconditional veto.
## Who the authority is
The upgrade authority is a **Compass-team-controlled multisig**. It has
exactly one purpose: deploying new venue facets to user accounts so they
can route to newly supported protocols without each user having to
re-deploy.
The authority is **not**:
* A custodian. It has no path to USDC.
* An owner. It cannot change ownership of any account.
* A general upgrader. It cannot modify any existing facet behavior.
What the authority is, precisely, is the answer to one question:
*"When Compass adds a new venue, how do existing users gain access without
re-deploying their account?"*
## What the authority can do — Add-only
The authority's powers are restricted to a single operation:
> **Register new function selectors against new facet addresses, via the
> `DiamondCut` facet, in `Add` mode only.**
In ERC-2535 terminology, `DiamondCut` supports three operations:
| Operation | What it does | Available to authority? |
| :---------- | :--------------------------------------------------------------- | :---------------------: |
| **Add** | Register new selectors that don't currently exist on the Diamond | ✅ Yes |
| **Replace** | Point an existing selector to a different facet implementation | ❌ No |
| **Remove** | Unregister an existing selector | ❌ No |
`Replace` and `Remove` are restricted to the owner. The authority cannot
call them, period — the Security facet's authority check reverts.
## What the authority cannot touch — Core facets
Even within `Add`, the authority cannot register selectors that conflict
with the **core set** of facets. These are the facets whose selectors are
permanently reserved:
| Core facet | Why it's protected |
| :--------------- | :----------------------------------------------------------------------------- |
| **Security** | Modifying session-key logic is the most dangerous possible upgrade. |
| **Ownership** | Modifying owner logic would let the authority change the user. |
| **DiamondCut** | Modifying the upgrade gate would let the authority escalate itself. |
| **DiamondLoupe** | Modifying introspection would let the authority hide what it added. |
| **Account4337** | Modifying ERC-4337 validation would let the authority bypass all checks above. |
The authority check enforces this by rejecting any `Add` operation whose
selectors overlap with the reserved set. The reserved set is itself
defined at construction time and is **immutable** — even the authority
cannot extend it (which would let it un-protect a facet).
## What the authority cannot do — Hard limits
Combining the rules above, the authority **cannot**:
* Move USDC from any account.
* Change ownership of any account.
* Replace or remove any existing facet, including venue facets.
* Modify Security, Ownership, DiamondCut, Loupe, or Account4337 logic.
* Extend its own permissions.
* Bypass a user's `userRevokeUpgradeAuthority` revocation.
These are not policy promises. They are call-graph restrictions enforced
on every `diamondCut` call by the Security facet.
## The owner's veto — `userRevokeUpgradeAuthority`
The owner of any account can permanently disable the upgrade authority on
that account, at any time, with a single transaction:
```text theme={null}
SecurityFacet.userRevokeUpgradeAuthority()
↑ onlyOwner
```
Effect:
* The `upgradeAuthorityRevoked` flag in Diamond storage is set to `true`.
* All future `diamondCut` calls signed by the authority revert at the
authority check.
* The Diamond reverts to **plain EIP-2535 behavior**: only the owner can
upgrade, using the standard `DiamondCut` permissions.
* The revocation is **irreversible**. Once revoked, the upgrade authority
cannot be re-granted on this account — even by the owner. To regain the
convenience of authority-shipped venues, the owner would have to deploy
a new account.
The irreversibility is deliberate. A "revoke and re-grant" function would
create a social-engineering attack surface — an attacker convincing an
owner to "just temporarily re-grant" defeats the entire point. Once an
account is upgrade-frozen, it stays that way.
## What revocation costs the user
Revoking the authority has one practical consequence: when Compass adds
support for a new venue, that venue's facet will not be available on a
revoked account. The owner can still:
* Use all existing facets (venues, Gateway, session keys).
* Withdraw, rebalance, and operate normally.
* Manually add new facets themselves, signing the `diamondCut` calls
with their owner key.
The trade-off is **convenience for sovereignty**. Most users will leave
the authority enabled because the bounded design makes it safe enough.
Users who want zero ongoing trust in the Compass team have the explicit
exit path.
## How the authority is operated
The authority multisig is operated by the Compass team for the purpose of
shipping venue facet additions. Operational properties:
* **Multi-signer.** Single team-member compromise is insufficient to
initiate an `Add`.
* **Per-account scope.** An authority `diamondCut` targets one specific
Diamond at a time. There is no global upgrade that affects all accounts
simultaneously.
* **Observable.** Every `diamondCut` call is an on-chain transaction.
Users can monitor their own account or subscribe to alerts.
The exact multisig configuration (number of signers, threshold) and the
list of signers are published alongside the contract addresses on
testnet. Both will be re-evaluated for mainnet.
## How this maps to the trust model
The upgrade authority is the answer to *"how does Compass evolve without
taking custody?"*. The bounded design lets the team ship improvements
without ever holding user funds or being able to drain them. The owner
veto means even the bounded design is optional — a user who doesn't want
*any* authority can opt out without leaving the product.
In the language of [Trust & security model](/overview/trust-security):
* Trusting Compass with the upgrade authority is an **operational** trust
decision — you're betting the team won't try to add selectors that
would conflict with the reserved set (which would just revert anyway).
* Not trusting Compass with the upgrade authority is a **one-transaction
decision** — call `userRevokeUpgradeAuthority` and the question
permanently goes away.
Both are valid. The design exists so users don't have to pick between
"never upgrade" and "trust us forever."
## Next steps
The facet structure the authority operates on.
The separate permission system for the agent's runtime calls.
The complete trust picture, in plain language.
Back to the three-layer architecture.