Managing Redemption Delays

A critical decision for any Atomist when curating a Fusion vault is whether to implement a Redemption Delay. While this feature is a powerful security tool, it introduces significant trade-offs regarding how the vault interacts with the broader DeFi ecosystem.

What is a Redemption Delay?

A redemption delay is a mandatory waiting period enforced between a user's deposit and their ability to withdraw or transfer their shares. In IPOR Fusion, this can be configured from 0 seconds (disabled) up to a maximum of 7 days.

When enabled, the vault records the timestamp of a user's last deposit. Any attempt to withdraw, redeem, or transfer shares before the delay period has passed will result in an AccountIsLocked revert.

The redemption delay parameter is set during the vault creation process in the Fusion Factory. Once the vault is created, this value is immutable. Atomists cannot change the delay period later, so careful consideration of the integration trade-offs is required before deployment.

The Security Motivation: Breaking Atomicity

In DeFi, an atomic transaction is a sequence of operations that must all succeed or fail together within a single block. Flash loan attacks rely entirely on this property: an attacker borrows funds, manipulates a vault's share price, and repays the loan—all in one block.

By requiring even a 1-second delay, the vault forces the user to wait at least until the next block. This makes flash loan attacks impossible because the loan cannot be repaid in the same transaction it was taken.

Pros and Cons at a Glance

Feature	Pros	Cons
Security	Hard protection against flash loans and price manipulation.	Does not prevent "sandwich attacks" that span across blocks.
Integrations	Simple to understand for retail users.	Breaks "Money Lego" composability; causes issues with Zaps and Liquidators.
User Experience	Prevents "in-and-out" gaming of the vault.	Can be frustrating for users expecting instant liquidity.

Integration Issues with DeFi Protocols

Implementing a redemption delay, even one as short as 1 second, can cause "silent" failures for other protocols treating your Fusion Vault as a building block.

1. Zaps and Aggregators

Many DEX aggregators and "Zap" contracts bundle multiple actions. A user might swap ETH to USDC and deposit into your vault in one click. If the Zap contract needs to "pull back" a tiny amount of shares for fee coverage or slippage adjustment in the same transaction, the entire sequence will fail.

2. Liquidation Friction and Collateral Utility

If a lending protocol accepts your vault shares as collateral, a redemption delay creates a major risk. During a liquidation, the protocol needs to seize and redeem those shares for the underlying asset immediately to cover debt. If the vault enforces a delay, the liquidation fails, potentially leading to bad debt for the lending protocol.

While bad debt is a risk for the lender, the indirect consequence for the Fusion vault is reduced collateral utility. Risk managers at lending protocols are likely to reject vault shares with redemption delays or apply much higher "haircuts" (lower LTVs), making your vault less attractive for power users and institutional integrators.

3. Yield Optimizers and Bots

Automated rebalancing bots often deposit into a vault and immediately check solvency or re-calculate a strategy. If these bots need to move funds out in the same block (common in volatile markets), they will get stuck in a revert loop.

The Alternative: On-boarding and Off-boarding Contributions

If your goal is to protect the vault from manipulation without breaking its composability, consider using On-boarding and Off-boarding Contributions (Deposit and Withdrawal fees).

In IPOR Fusion, these are shares minted or burned during the entry/exit process.

How Fees Protect the Vault

Instead of a time-based lock, you can implement a small fee (e.g., 0.1%). This "tax" on atomicity makes flash loan attacks and sandwich attacks economically unviable because the cost of the fee typically exceeds the potential profit from the manipulation.

• Composability stays intact: Zaps and Liquidators can still interact with the vault instantly.

• Protection remains: Flash loaners are deterred by the upfront cost.

Recommendation for Atomists

• For Private/Curated Vaults: If you expect your vault to be used primarily by retail users through a frontend, a short redemption delay (e.g., 1 hour) is a robust security measure.

• For Ecosystem Building Blocks: If you want your vault to be used as collateral in lending markets or included in yield aggregators, set the Redemption Delay to 0 and utilize On-boarding/Off-boarding Contributions to provide security while maintaining high composability.