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

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.