Risk & administration

Two administrators, shared approval

The current design requires two distinct administrator wallets. Either can immediately pause new risk. Upgrades, recovery activation, each recovery transfer, key rotation and resuming new risk require approval from both. There is no execution timelock.

One administrator records an expiring approval for the exact calldata, value, chain, contract and current governance nonce. The other executes it. Execution consumes the approval and advances the nonce. A key rotation also needs the other administrator. This is contract-enforced shared administration, not token-holder governance. Losing either key can prevent jointly authorized operations.

What an upgrade can change

Modules use UUPS upgradeable proxies. Initialization happens atomically, and implementation contracts reject direct initialization. Upgrade authorization checks both administrators’ approval and requires the replacement implementation to identify the same module type.

That module check reduces accidental cross-module upgrades. It does not prevent both administrators from approving new code that changes economic rules or fund handling. Storage compatibility and new behavior require review for every upgrade.

Risk pause and recovery are different states

A risk pause blocks new commitments such as deposits, borrowing, offers, reserve contributions, swaps and staking. Existing exits remain available where each module’s operational, price and transfer conditions allow them.

Recovery requires a nonzero reason hash and records its activation time. It halts normal financial operations. The current code has no ordinary resume function; an upgrade would be needed to restore operations.

Recovery includes user assets

After recovery activation, both administrators must approve each transfer of assets held by the relevant module to a selected valid recipient. This includes supplier principal, borrower collateral, reserve backing, staked tokens and earned fees, as well as native ETH and supported NFTs.

There is no user-fund exemption or treasury-only restriction. These powers apply to the live Serevin staking campaign and to Serevin modules when activated. They do not give Serevin control over positions held directly in Morpho contracts.

The lending market freezes an accounting reference and stops interest accrual in recovery. The reserve records its balance and supply. Historical records do not constitute a guaranteed reimbursement, a funded recovery plan or an automatic distribution.

Other dependencies

Contract correctness is one part of the system. Asset issuers can impose transfer restrictions; prices can be unavailable; collateral can gap; execution venues can lack depth; a sequencer outage can interrupt transactions; and a compromised administrator can exercise broad powers.

Local tests cover specific implementation behavior; they do not replace an independent security audit. The funded staking campaign and direct Morpho interface are released with separate deployment and read-only monitoring evidence. Other financial modules still need their own approved release. Monitoring runs are periodic and may be interrupted; continuous hosted coverage, verified external alert delivery and independent contract review remain incomplete.