Pause Functionality

What pausing a vault does, who can trigger it, and its effect on in-flight operations.

Introduction

The pause functionality in IPOR Fusion serves as an emergency security mechanism designed to instantly halt specific smart contract operations. It is a defensive tool used to protect vault assets and prevent malicious state mutations during critical events, such as suspected exploits, severe oracle failures, or extreme market volatility.

The Circuit Breaker Concept

In decentralized finance, a circuit breaker acts as a fail-safe that stops execution when abnormal conditions are detected. When the pause function is triggered in IPOR Fusion, it immediately closes access to critical operational functions on the affected contract. This freezes state-changing operations—such as strategy execution or market balance updates—preventing any further asset movement or configuration changes until the threat is assessed and resolved.

What is a Target Contract?

To understand how pausing works in IPOR Fusion, it is essential to understand the concept of a target contract.

Because IPOR Fusion uses a modular, factory-based architecture, the protocol consists of many independent deployments rather than a single monolithic system. A target contract refers to any specific smart contract governed by the IporFusionAccessManager.

Most commonly, a target contract is an individual PlasmaVault instance. However, it can also refer to supporting infrastructure, such as a specific WithdrawManager, FeeManager, or RewardsClaimManager. When a pause is initiated, the Access Manager "closes" the route to that specific target contract, effectively halting its operations.

Design Philosophy: Isolation and Immediacy

The design of the pause mechanism is built on two core principles:

  1. Risk Isolation: Unlike monolithic protocols that require a global freeze, IPOR Fusion's pause mechanism is localized. Pausing one target contract (e.g., PlasmaVault A) strictly halts operations for that specific vault. It does not disrupt PlasmaVault B, nor does it affect the broader FusionFactory deployment infrastructure. This isolation ensures that unrelated vaults and unaffected strategies can continue operating normally.
  2. Immediate Execution: Because pausing is strictly a defensive maneuver, it is designed to be executed instantly. While typical structural or configuration changes in IPOR Fusion are subject to execution delays (timelocks) to protect users, emergency pauses bypass these delays to mitigate market anomalies, ongoing attacks, or critical failures immediately.

Technical Mechanism

AccessManager Integration

In IPOR Fusion, the pause state is not handled by a traditional, standalone Pausable modifier residing on the vault itself. Instead, it is centrally managed by the IporFusionAccessManager, which extends OpenZeppelin's standard AccessManager.

This architectural choice consolidates security controls. By moving the pause logic to the Access Manager layer, the protocol ensures that the ability to freeze a contract is cryptographically tied to the exact same system that governs role hierarchies, execution delays, and access control. Only accounts granted the GUARDIAN_ROLE (Role ID: 2) have the authority to trigger this defensive state.

The updateTargetClosed() Function

To initiate a pause, an authorized Guardian calls the updateTargetClosed() function directly on the IporFusionAccessManager.

Vaults created with Fusion Factory v9 can also be paused through PlasmaVaultPauser, a small contract that holds the Guardian role. Its owner whitelists an account for one vault; that account can then pause that vault once. The pauser can only close a vault, never reopen it: reopening stays with a Guardian account calling updateTargetClosed(vault, false).

function updateTargetClosed(address target, bool closed) external
  • target: The address of the specific smart contract to be paused (e.g., the PlasmaVault).
  • closed: A boolean flag. Setting this to true initiates the pause; setting it to false removes the pause.

When closed is set to true, the Access Manager acts as a firewall. It instantly begins reverting any incoming calls to functions on the target contract that are protected by the restricted modifier. This effectively blocks strategy execution via execute(), market balance updates, and administrative configurations, locking down the contract's state.

Execution Timing

IPOR Fusion heavily utilizes time-locked operations; structural changes typically require an execution delay to give depositors a window to react. However, because pausing is an emergency defensive maneuver, it must bypass these standard timelocks to be effective against active threats.

During the initialization of a vault ecosystem, the IporFusionAccessManagerInitializerLibV1 explicitly configures the GUARDIAN_ROLE with a zero-day execution delay (executionDelay: 0). Because of this, when a Guardian calls updateTargetClosed(), the transaction does not need to be scheduled in the queue—it is executed and enforced in the very same block.

Operational Impact

When a Guardian triggers a pause on a target contract, the effects are immediate and strictly scoped to functions utilizing the restricted modifier on that specific address.

Halted Operations

For a standard PlasmaVault target, pausing the contract halts the following core operations:

  • Strategy Execution: The ALPHA_ROLE can no longer call the execute() function. This prevents the vault from interacting with external protocol fuses (e.g., supplying, borrowing, or swapping assets).
  • Market Accounting: The updateMarketsBalances() function is blocked, freezing position valuations and preventing performance fee minting based on potentially manipulated oracle data.
  • Governance & Configuration: The ATOMIST_ROLE and OWNER_ROLE cannot alter the vault's state. Operations such as adding or removing fuses, granting market substrates, and updating fee configurations are temporarily frozen.
  • Withdrawal Management: If the WithdrawManager is the paused target, the ALPHA_ROLE is blocked from calling releaseFunds(), halting the progression of scheduled withdrawals.

User Impact

In IPOR Fusion, standard ERC4626 user functions are mapped to the PUBLIC_ROLE or WHITELIST_ROLE within the Access Manager. Consequently, these functions are protected by the restricted modifier and are strictly halted when the vault is paused:

  • Deposits and Minting: Users cannot add funds or mint new shares (deposit(), mint(), depositWithPermit()) while the vault is paused.
  • Withdrawals and Redemptions: Instant withdrawals (withdraw(), redeem()) and scheduled redemptions (redeemFromRequest()) are blocked. This ensures that during a suspected exploit or severe oracle failure, malicious actors cannot drain assets from the vault.
  • Share Transfers: If share transfers were previously enabled via enableTransferShares(), the transfer() and transferFrom() functions will revert, locking the vault shares to their current owners until the pause is lifted.

Unaffected Systems

A paused target contract does not equate to a complete system shutdown. The following operations remain unaffected:

  • Read-Only State Queries: Users, external protocols, and UI interfaces can still safely query read-only functions such as totalAssets(), balanceOf(), and the standard ERC4626 preview functions.
  • Isolated Vault Infrastructure: Because pausing is localized to the specific target contract address, other PlasmaVault instances deployed from the same FusionFactory remain fully operational.
  • Independent Managers: If only the PlasmaVault is paused, users may still theoretically initiate new withdrawal requests via WithdrawManager.requestShares(), though they will be unable to finalize the redemption on the vault until it is unpaused.

The Pause Lifecycle

The pause lifecycle involves three distinct phases: triggering the freeze, managing the paused state, and securely resuming normal operations.

Triggering a Pause

A pause is strictly a reactive security measure. The workflow for initiating a pause is as follows:

  1. Detection: A threat is detected. This could be an anomaly identified by off-chain monitoring systems, an alert from an integrated protocol regarding an ongoing exploit, or severe deviations in oracle price feeds.
  2. Authorization: An account or multisig holding the GUARDIAN_ROLE (Role ID: 2) verifies the threat.
  3. Execution: The Guardian calls IporFusionAccessManager.updateTargetClosed(targetContractAddress, true).
  4. Enforcement: The transaction executes immediately (due to the 0-day delay), and the Access Manager begins reverting all restricted calls to the target contract.

State Resolution

While a target contract is paused, its internal state is frozen, but the external environment (e.g., market prices, integrated protocol states) continues to evolve.

  • Pending Operations: If there are time-locked operations scheduled in the IporFusionAccessManager queue (e.g., a pending fee configuration change initiated by an ATOMIST), these operations remain in the queue. If their execution time arrives while the target is paused, the execution will revert. However, once the target contract is unpaused, these pending operations can be successfully executed, provided they have not been explicitly canceled by the Guardian.
  • Veto Power: During the paused state, the GUARDIAN_ROLE retains the authority to call AccessManager.cancel(). This allows the Guardian to actively clear malicious or compromised operational transactions from the timelock queue while the vault remains safely frozen.

Resuming Operations

Unpausing a target contract requires careful assessment to ensure the threat has been neutralized and the vault state remains solvent.

  1. Assessment: The vault's operating team (typically the Owner, Atomist, or Guardian) evaluates the incident, verifies that external protocols are secure, and confirms that price oracles are reporting accurate data. Because IPOR Fusion vaults are isolated and independently managed, this assessment responsibility lies strictly with the individual vault's administrators, not the Fusion DAO or the core development team.
  2. Execution: An account holding the GUARDIAN_ROLE calls IporFusionAccessManager.updateTargetClosed(targetContractAddress, false).
  3. Resumption: The Access Manager lifts the restriction, allowing users to withdraw funds, Alphas to execute strategies, and normal ERC4626 operations to resume.

Because unpausing restores access to potentially vulnerable operations, it should only be executed once the root cause of the initial threat has been fully resolved or mitigated via governance actions (e.g., removing a compromised fuse).

Last updated