Who can change the rules after you deposit into DeFi?

Start with the power, then find the account

For this example I used Steakhouse USDC on Ethereum, the V1 vault from the earlier review. I recorded the reads at finalized block 26,290,448 on 28 October 2026, with hash 0x10c8a38ab940946fe87de9aecb891a2ae585c8e5329e2f596ecd86458ac5245a.

The first pass returned:

I’d inspect the deployed role checks, including inherited permissions and the accounts that can replace each role holder.

Morpho’s V1 role reference describes the owner as inheriting curator, allocator and guardian capabilities. The map needs to include the owner’s inherited powers alongside the accounts explicitly assigned those roles. This article explains the documented V1 model. I haven’t independently matched every permission to this deployment’s bytecode.

The owner has owners of its own

I’d ask how those keys are held, who can approve a transaction and whether the same operator controls several of them. Some answers require information from the team. A blockchain query can’t establish that signers are independent or that their devices are securely managed.

I’d also check alternate execution paths. Safe’s account documentation explains that enabled modules can execute under their own authorization rules. I’d check those modules before treating the owner threshold as the account’s only approval route.

For this owner address, getModulesPaginated returned an empty array and the end-of-list sentinel at the recorded block. I haven’t verified the account’s singleton code, guard, fallback handler or full signature behavior, so I wouldn’t describe the entire account as reviewed. I’d repeat this account-level work for the curator and guardian too.

What could actually change for the money?

Imagine the treasury chose the vault because it was comfortable with a particular set of lending markets. Reallocation within permitted markets can change the position’s concentration and available liquidity.

Morpho’s V1 allocation guide describes reallocating within configured boundaries. Its role reference also describes the curator’s ability to decrease caps immediately and propose increases through the timelock. I’d record those as separate actions. A role name alone doesn’t describe which changes can happen quickly.

For example, Morpho’s V1 role reference explicitly says the curator cannot pause withdrawals. I’d trace the actual restrictions and possible causes of a failed withdrawal, including liquidity, separately.

Seven days for which action?

The vault returned a seven-day timelock. The next question is which changes must wait.

Morpho’s V1 tutorial describes immediate curator replacement and delayed guardian replacement when a guardian already exists. The exact deployed rules and pending changes still need inspection. I’d put an action and its applicable delay on every line of the map, then trace who can change the authority or the delay itself.

For a treasury, the response window starts when someone notices the proposal. I’d assign an alert owner, decide who can approve an exit and check whether the position could be withdrawn before the change becomes executable. The monitoring guide follows that operational path. For an implementation change, the audit-to-deployment guide explains how to establish which code is running.

Removing access needs a second check

I’d verify that the address lost its permission, inspect any changes it already made and check whether it holds another role or controls another authorized account. If several roles point to the same operator, rotating one address may leave another route open.

Recovery also needs someone who can still act. I’d confirm who can revoke access, whether that account remains available during an incident, and what the team should do about pending proposals. The signer-security article covers the related problem of removing a compromised process’s signing access.

Reading permissions and watching them change

For this vault, I’d keep the block-specific reads separate from the service that watches later changes. I’d choose between managed monitoring options by testing the permissions in our map.

Tool or system	Where it helps	What I would verify
Foundry Cast	Inspecting role holders and their controlling accounts	Read owner, threshold and module state using the actual contract version. Keep raw results with the block.
Safe	Operating an onchain multisig account	Inspect existing modules and guards as well as signers. Verify that replacing one owner removes the intended authority.
Hypernative	Monitoring role and control changes	Configure the actual contracts and account dependencies. Test both an approved rotation and an unexpected grant.
Cyvers	An alternative contract and wallet monitoring workflow	Demonstrate the same changes and escalation path. Confirm coverage of this permission design.

Cast helps establish the state. Safe describes one account’s authorization arrangement. I’d compare Hypernative and Cyvers through a pilot that includes an alternative execution path, rather than judge them by the number of alerts advertised.

The protocol administrator and monitoring owner need to reconcile the map after every authority change. The dated reads earlier in this article don’t establish the rest of the account configuration or a monitoring deployment.

Put the permissions into a usable map

I’d bring a map with a plain-English sentence for each important action: this account can make this change, under these conditions, after this delay. Alongside it I’d list who controls the account, what was verified and which questions still need an answer.

The allocator list, remaining account configuration, human control of keys and complete deployed permission model are still open in this review.

The control-map template gives you a place to record that work. If your team needs to understand who can change a protocol you’re using, get in touch about a DeFi security review.