# Accounting and PPS Protection

A critical challenge for multi-protocol yield aggregators is maintaining an accurate and manipulation-resistant Price Per Share (PPS). This page explains the risks associated with "Auto-Accrual" accounting and how IPOR Fusion's architecture provides robust protection against these attack vectors.

### The Pitfalls of Auto-Accrual Accounting

Some early vault designs utilized an "Auto-Accrual" model. In this model, the vault automatically updates its `totalAssets()` on every transaction (deposit, withdrawal, or transfer) by looping through and querying every integrated market.

While this ensures that yield is always "up-to-date," it introduces major vulnerabilities:

1. **Intra-block PPS Manipulation**: Since `totalAssets()` updates on every "touch," an attacker can donate assets to an underlying strategy, observe an immediate rise in the vault's PPS, and exploit this higher valuation (e.g., by borrowing against the inflated shares) all within the same block.
2. **The "Weakest Link" Problem**: The entire vault's security is tied to its most manipulable strategy. If a single integrated market can be manipulated, the entire vault's accounting is affected instantly.
3. **PPS Inflation via Donation**: Anyone can artificially pump the PPS by directly transferring assets to external protocols the vault uses, causing immediate and uncontrolled revaluation of all vault shares.

### The Fusion Solution: Explicit Reporting

IPOR Fusion solves these issues by decoupling user transactions from yield accrual. The `PlasmaVault` uses an **Explicit Reporting** model.

#### 1. Cached Balances instead of Live Loops

In a PlasmaVault, the `totalAssets()` call does **not** loop through integrated markets on-the-fly. Instead, it aggregates:

* The direct `IERC20(asset).balanceOf(vault)` (idle assets).
* **Cached values** from storage (`PlasmaVaultLib.getTotalAssetsInAllMarkets()`).
* Optionally, pending rewards.

Because the market balances are cached, an external donation to an external protocol or a change in interest rates does not affect the vault's PPS until those balances are explicitly updated and written to storage. Conversely, a direct donation to the vault contract itself is visible but protected by mathematical safeguards.

#### 2. Controlled Balance Updates

Balance updates in Fusion are deliberate and triggered only by authorized operations or roles via `_updateMarketsBalances()`:

* **Alpha Strategy Execution**: Whenever an Alpha executes a strategy via `execute()`, the vault automatically updates the balances of all affected markets at the end of the transaction. This ensures that the vault's accounting reflects the new position state immediately after a deliberate change.
* **Instant Withdrawals**: If an instant withdrawal requires the vault to source liquidity from external markets, the system triggers a balance update for those markets to reflect the exit and ensure accurate share pricing for the redeeming user.
* **Alpha-Driven Reporting**: For passive yield (interest accrual), accounts with the `UPDATE_MARKETS_BALANCES_ROLE` (Alphas) periodically trigger balance refreshes. This is asynchronous to user deposits, eliminating intra-block manipulation vectors.

#### 3. Oracle-Based Isolation

Unlike designs that rely on raw balances of LP tokens or receipt tokens, Fusion's **Balance Fuses** return values converted through the `PriceOracleMiddleware`. Manipulating a raw balance in an external protocol does not translate 1:1 to the vault's `totalAssets` unless the oracle price also reflects that change.

### Additional Safeguards

#### Redemption Delay (Withdraw Delay)

To further neutralize flash loan attacks and sandwiching, Fusion vaults utilize a **Redemption Delay**. Configured via the `IporFusionAccessManager`, this delay enforces a minimum time (e.g., 24 hours) that must pass between a deposit and the subsequent ability to withdraw or redeem those shares. This ensures that capital is "at risk" and prevents attackers from entering and exiting the vault within the same block or price window.

See also: [Managing Redemption Delays](/build-on-fusion/atomists/curating-a-fusion-vault/managing-redemption-delays.md)

#### Mathematical Safeguards (Virtual Offsets)

For direct donation attacks on the vault contract itself, Fusion implements ERC-4626 virtual offsets. The internal share calculation uses a multiplier and an offset to prevent "inflation attacks":

$$shares = assets \cdot \frac{supply + 10^k}{totalAssets + 1}$$

Where $$10^k$$ represents the `_SHARE_SCALE_MULTIPLIER` (typically 100). This makes the cost of manipulating the PPS via small-scale donations prohibitively expensive.

### Comparison of Accounting Models

| **Aspect**              | **Auto-Accrual**                   | **Explicit (IPOR Fusion)**         |
| ----------------------- | ---------------------------------- | ---------------------------------- |
| **Yield Accrual**       | Automatic, every transaction       | Triggered (Alpha, Withdraw)        |
| **PPS Update**          | Per-transaction, via loops         | Per-operation/reporting            |
| **Donation Protection** | Vulnerable                         | **Resistant**                      |
| **Flash Loan Exploit**  | Possible                           | **Prevented (via Delay & Cache)**  |
| **Security Scope**      | Weakest link across all strategies | Isolated via Oracles & Triggers    |
| **Withdrawal Safety**   | Vulnerable to intra-block swings   | **Protected via Redemption Delay** |

### Implementation Summary

By utilizing **cached balances**, **operation-specific triggers**, and a **redemption delay**, Fusion ensures that the vault's accounting is a product of verified protocol state rather than side effects of user actions. This architecture makes the Fusion Vault significantly more robust against sophisticated MEV and price manipulation attacks.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ipor.io/build-on-fusion/developer-guide/accounting-and-pps-protection.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.