SerevinSerevinDocumentation
The guide/Controls & reference
Current control model

Risk & administration

Both admins must approve upgrades and recovery of held funds. Either can immediately pause new risk.

In this chapter

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 were deliberately selected for the current design and must remain visible before any real deposit is enabled.

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 are not an independent security audit or evidence that a mainnet deployment is operational. Production integration, monitoring, incident handling and independent review remain incomplete.

This guide describes the current source implementation. Production terms and verified deployment addresses will be published before real transactions are enabled.