# Tips

## Best Practices for Alphas

The **Alpha** role (assigned via `ALPHA_ROLE`) is the operational engine of a Fusion Vault. As an Alpha, your primary responsibility is the execution of yield strategies and the management of vault liquidity. Unlike the Atomist, who configures the "physical" constraints of the vault, the Alpha operates within those constraints to maximize risk-adjusted returns for depositors.

This guide provides technical tips and best practices for running an efficient Alpha bot or manual strategy.

### 1. Optimize for Atomicity and Gas Efficiency

The `execute(FuseAction[] calldata calls_)` function is designed for atomic batching. Every action within the `calls_` array is executed via `delegatecall` in the vault's context.

* **Batching for Gas Efficiency:** Combine related operations (e.g., swapping tokens, then supplying them to Aave V3) into a single `execute` call. This reduces overhead and ensures that the vault never holds intermediary assets across blocks.
* **Optimal Transaction Sizing:** Avoid overly long execution chains that might exceed block gas limits. Estimate gas fees for execution and evaluate them against the likelihood of sustained rate changes.
* **All-or-Nothing Execution:** If any `FuseAction` fails—due to slippage or substrate violations—the entire transaction reverts. Use this to build complex "Zaps" or arbitrage loops with zero principal risk to the vault.

### 2. Leveraged Looping Strategies

Leveraging can significantly boost yield but introduces specific risks to the vault's Net Asset Value (NAV).

* **Slippage Management:** Slippage is the primary "performance killer."
  * Prefer **native staking/unstaking** or **wrapping** over DEX swaps whenever possible.
  * Use **aggregators** to find the best routes. The `UniversalSwapper` fuse provides additional validation for aggregator-provided transactions.
  * For large positions, **TWAP in and out**. Building a massive leveraged position in a single block can cause high slippage. Smaller, incremental steps allow the market depth to recover.
* **Simulate Market Depth:** Before executing, understand the current market depth and rate dynamics. Simulate slippage on-chain or via off-chain forks to ensure you aren't leaving "free money" for MEV sandwich bots.
* **Avoid Swaps via Flash Loans:** When moving between positions with similar assets, use a **Flash Loan** (e.g. via `MorphoFlashLoanFuse`) to transition atomically without incurring swap fees or slippage.

### 3. Managing Accounting and Performance Fees

Performance fees are calculated on realized gains during `execute()` and `updateMarketsBalances()`.

* **Understand the High-Water Mark:** IPOR Fusion utilizes High-Water Mark (HWM) logic. Performance fees are only minted when $$TotalAssets\_{after} > HighWaterMark$$.
* **Strategic Balance Updates:** Call `updateMarketsBalances(uint256[] marketIds)` periodically. This synchronizes internal accounting with external protocol interest.
* **Prevent Inflation Attacks:** Update the share price ($$\frac{TotalAssets}{TotalSupply}$$) frequently enough to ensure accuracy and prevent share price inflation attacks, especially in public vaults.
* **Oracle Precision:** If an asset is new or has limited DEX liquidity but maintains a 1:1 redemption peg, consider suggesting a hardcoded price oracle to the Atomist to prevent oracle manipulation during low-liquidity events.

### 4. Liquidity and Withdrawal Orchestration

* **Unallocated Buffer:** Maintain a buffer of assets in an instantly liquid strategy (e.g., IPOR Lending Optimizers). This allows the vault to fulfill smaller withdrawals instantly without the gas cost of deleveraging a complex position.
* **Scheduled Withdrawal Flexibility:** Do not ignore the flexibility of scheduled withdrawals. Sometimes it is more economical to use the next incoming deposit to pay down vault debt rather than manually deleveraging via a swap.
* **The `releaseFunds` Responsibility:** For scheduled withdrawals, Alphas must call `releaseFunds()` on the `WithdrawManager`. Monitor the queue and rebalance the vault *before* releasing funds to ensure liquidity is present.
* **Dynamic Fees:** If granted the role, the Alpha can manage the **Request Fee** and **Withdrawal Fee**. Set these dynamically to match your expected cost of unwinding positions, preventing users from "socializing" the cost of their exits.

### 5. Deleveraging and Risk Execution

The Alpha executes deleveraging actions based on market conditions, but must always operate within the risk framework established by the Atomist.

* **Bite the Bullet:** Deleveraging often incurs trade costs (swaps/fees). In high-risk scenarios (e.g., price volatility approaching an Atomist-defined threshold), it is better to "bite the bullet" and deleverage at a loss than to risk a liquidation event that threatens the vault's principal.
* **Cost vs. Performance:** Decisions to deleverage must balance execution costs (slippage and gas) against the cumulative negative carry of an inverted position. While using new deposits to pay down debt is an efficient way to deleverage, it is unlikely to occur when rates are inverted, as smart depositors will avoid a vault with negative performance. Alphas must proactively calculate the "breakeven" time—where the cost of a forced swap today is lower than the projected loss from holding the inverted position—and execute accordingly while remaining within the Atomist's safety bounds.

### 6. Security and Risk Mitigation

* **Strict Slippage:** Always populate `minOutAmount` or `maxSharesBurned`. Never use `0` in production.
* **Oracle Pre-Hooks:** Use the `ValidateAllAssetsPricesPreHook` before `execute()` to block operations if the `PriceOracleMiddleware` detects a price deviation beyond your threshold (e.g., 1-2%).
* **Monitoring Health Factors:** For borrow positions (e.g. Euler V2, Morpho), monitor the Health Factor ($$HF$$) of sub-accounts using the `balanceOf` query in the corresponding Balance Fuse.

### 7. Technical Role Constraints

* **Governance Separation:** Internal functions (fee % changes, adding fuses) are restricted to the Atomist. Focus on capital allocation and execution logic.
* **Bot Robustness:** Ensure your automated Alpha has robust error handling, monitors gas price spikes, and maintains a sufficient ETH balance for operations.

#### Summary Checklist for Alpha Operations

| **Task**                       | **Frequency**        | **Target Contract**   |
| ------------------------------ | -------------------- | --------------------- |
| `updateMarketsBalances`        | e.g. Hourly/Daily    | `PlasmaVault`         |
| `releaseFunds`                 | Per Withdrawal Cycle | `WithdrawManager`     |
| `execute` (Rebalance/Compound) | As needed            | `PlasmaVault`         |
| `claimRewards`                 | Based on Accrual     | `RewardsClaimManager` |


---

# 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/alpha/running-an-alpha/tips.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.