> For the complete documentation index, see [llms.txt](https://docs.ipor.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipor.io/build-on-fusion/developer-guide/pause-functionality.md).

# 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`.

```
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).