Skip to main content

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.

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. For the trust assumptions this model creates, see Trust & security model.

​
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:
OperationWhat it doesAvailable to authority?
AddRegister new selectors that don’t currently exist on the Diamond✅ Yes
ReplacePoint an existing selector to a different facet implementation❌ No
RemoveUnregister 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 facetWhy it’s protected
SecurityModifying session-key logic is the most dangerous possible upgrade.
OwnershipModifying owner logic would let the authority change the user.
DiamondCutModifying the upgrade gate would let the authority escalate itself.
DiamondLoupeModifying introspection would let the authority hide what it added.
Account4337Modifying 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: 
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:
  • 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

Diamond account

The facet structure the authority operates on.

Session keys

The separate permission system for the agent’s runtime calls.

Trust & security model

The complete trust picture, in plain language.

System overview

Back to the three-layer architecture.