diff --git a/docs/security/security_audits.md b/docs/security/security_audits.md index 6a1f0491..c3cdfe63 100644 --- a/docs/security/security_audits.md +++ b/docs/security/security_audits.md @@ -9,6 +9,11 @@ image: /img/banners/audits-banner.png Panoptic has undergone numerous economic and security reviews by leading firms. The following reports are available for public review. +## Vault Audits + +### Code4rena +The Panoptic vault infrastructure was [audited](https://code4rena.com/audits/2025-06-panoptic-hypovault) by [Code4rena](https://code4rena.com/) from Jun 27 to July 7, 2025. + ## Smart Contract Audits ### Cantina @@ -19,7 +24,7 @@ The initial Panoptic V1.1 Protocol [report](https://cantina.xyz/portfolio/5a11e7 ### Code4rena A review of the Panoptic V1.1 Protocol was completed by top code4rena wardens on January 28, 2025. The reports can be found [here](/pdf/Bauchibred_Panoptic.pdf) and [here](/pdf/MrPotatoMagic_Panoptic.pdf). -The final [review](https://code4rena.com/reports/2024-09-panoptic) of the Panoptic V1 Protocol was completed by [Code4rena](https://code4rena.com/) on October 10, 2024 and found _**no High or Medium severity issues**_. +The final [review](https://code4rena.com/reports/2024-09-panoptic) of the Panoptic V1 Protocol was completed by Code4rena on October 10, 2024 and found _**no High or Medium severity issues**_. The second Panoptic V1 protocol audit [report](https://code4rena.com/reports/2024-06-panoptic) was completed by Code4rena on June 10, 2024. diff --git a/docs/vaults/_category_.json b/docs/vaults/_category_.json new file mode 100644 index 00000000..52def27c --- /dev/null +++ b/docs/vaults/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Vaults", + "position": 3.5, + "link": null +} diff --git a/docs/vaults/curation.md b/docs/vaults/curation.md new file mode 100644 index 00000000..955fb813 --- /dev/null +++ b/docs/vaults/curation.md @@ -0,0 +1,74 @@ +--- +sidebar_position: 6 +--- + +# Curation + +Curation is the process of defining the operational and security framework for a vault. A Curator acts as both a fund administrator and a security officer, establishing the rules of engagement for the Manager and ensuring the vault operates as intended. + +--- +## Management controls + +A Curator's primary responsibility is to define the level of trust and autonomy granted to the vault's Manager. + +### Manager + +This is the standard, trusted model. The Curator sets a single address as the **Manager** in the `HypoVault` contract. This gives the Manager full, discretionary power to execute any on-chain action through the `manage()` function. This model is highly flexible but requires absolute trust in the Manager's competence and integrity. + +### Manager with Merkle Verification + +This is an advanced, trust-minimized pattern. While not native to the base `HypoVault`, a Curator can design a system where the Manager can only execute a limited set of pre-approved actions. This is typically achieved by having the Curator commit to a Merkle root of all valid strategic actions. The Manager must then provide a Merkle proof along with each action, which is verified on-chain before execution. This enforces a "strategic whitelist," preventing the Manager from going rogue. + +--- +## Safeguards + +While the Manager constructs the `managerInput` payload for each NAV calculation, the Curator defines the immutable rules and sanity checks that this input is validated against in the `PanopticVaultAccountant`. + +### managerPrices + +These are the Manager's off-chain price quotes for the assets in the portfolio. The Curator's key control here is setting the `maxPriceDeviation` within the `pools` configuration. This is a critical security parameter that causes the transaction to revert if the Manager's provided price differs too much from the on-chain oracle's TWAP, protecting against stale or manipulative pricing. + +### pools + +This is a core Curator responsibility. The Curator defines the exact list of `PoolInfo` structs that the vault is allowed to interact with. This configuration specifies every approved pool, token, oracle, and risk parameter. The `keccak256` hash of this list is then stored in the `PanopticVaultAccountant`, and for maximum security, the Curator should lock this configuration to make it immutable. + +### tokenIds + +This is the complete list of all Panoptic position NFTs the vault holds. The Manager must provide this with every NAV calculation. The Curator's role is to understand that the accountant contract automatically enforces the completeness of this list. If the Manager tries to hide a position, the transaction will revert with `IncorrectPositionList`. + +--- +## User fund management + +The Curator should design the vault's fund management cadence, balancing user experience with strategic needs. + +### Epochs + +Deposits and withdrawals are not instant, but rather they are batched into **epochs**. The Manager fulfills an entire epoch at once, ensuring all participants in that batch receive a fair, uniform price based on a single NAV calculation. + +### `shouldRedeposit` + +This is a boolean flag in a user's pending withdrawal. When `true`, the assets from a user's withdrawal are automatically [re-queued for deposit](/docs/vaults/deposit-withdrawal#compounding-returns) into the next epoch instead of being sent to their wallet. + +### `requestWithdrawalFrom()` + +This manager-only function utilizes the `shouldRedeposit` flag. It allows the Manager to trigger a withdrawal on behalf of a user and force the proceeds to be redeposited. This is a powerful tool for portfolio rebalancing or realizing profits for performance fee calculation without the user's funds ever leaving the vault's ecosystem. + +## Performance fee + +The `performanceFeeBps` is set at the vault's creation and defines the Manager's share of the profits, ensuring incentives are aligned with the depositors. + +### Withdrawal +The performance fee is calculated and taken **only on profitable withdrawals**. This "high-water mark" model ensures the Manager is only rewarded for generating real returns above a user's original cost basis. + +When a user's withdrawal is executed, the contract compares the value of their withdrawn assets against their basis. If the withdrawal is profitable, the fee is taken **only on the profit** and sent to the designated `feeWallet`. + +### Manager-Initiated Fee Crystallization +Managers do not need to wait for users to withdraw their funds to realize earned fees. The protocol allows for a process called "fee crystallization" using the `requestWithdrawalFrom()` workflow. + +At their discretion (e.g., at the end of a reporting period), a Manager can: +1. Call `requestWithdrawalFrom()` on a user's position. +2. This initiates a withdrawal that is automatically flagged to be **redeposited**. +3. When the withdrawal is processed, it triggers the standard performance fee calculation on any accrued profit. +4. The fee is sent to the `feeWallet`, and the user's remaining capital is seamlessly rolled into a new deposit in the next epoch. + +This powerful feature allows Managers to periodically "net" the vault's performance and collect their earned fees, much like a traditional hedge fund, without requiring users to manually exit and re-enter their positions. diff --git a/docs/vaults/deposit-withdrawal.mdx b/docs/vaults/deposit-withdrawal.mdx new file mode 100644 index 00000000..2277f695 --- /dev/null +++ b/docs/vaults/deposit-withdrawal.mdx @@ -0,0 +1,306 @@ +--- +sidebar_position: 4 +sidebar_label: "Deposits and Withdrawals" +--- + +import ThemedImage from '@theme/ThemedImage'; +import useBaseUrl from '@docusaurus/useBaseUrl'; + +# Deposit and Withdrawal Flow +Panoptic Vaults use an asynchronous deposit and withdrawal system. +Every deposit request must be approved by the manager to help set the shares price from the pool's valuation. +Similarly, withdrawals must also be approved by the manager in case the vault needs to divest from its investments to free up capital. + +## Deposit Flow + +The deposit process in the Panoptic Vault follows a two-phase epoch-based system designed to ensure fair pricing and prevent front-running attacks. When users deposit assets, they enter a queue for the current epoch and must wait for the manager to fulfill their request before receiving shares. + + + +The process works as follows: +1. **Request Phase**: Users call `requestDeposit()` to transfer their assets (e.g., USDC) into the vault. The assets are held in escrow and the request is recorded in the current deposit epoch. +2. **Fulfillment Phase**: The manager periodically calls `fulfillDeposits()` to process all pending deposits in the current epoch. During fulfillment, the manager: + - Calculates the vault's [Net Asset Value (NAV)](/docs/vaults/nav) through the accountant contract + - Determines the share price based on the current NAV + - Allocates shares proportionally to all depositors in that epoch + - Advances to the next epoch +3. **Execution Phase**: After fulfillment, users call `executeDeposit()` to claim their shares. The shares are calculated based on the NAV at the time of fulfillment, ensuring all users in the same epoch receive the same price. Since assets can only be withdrawn after shares are claimed, users typically wait to claim until they're ready to withdraw, avoiding unnecessary steps in the meantime. + +This system prevents sandwich attacks and ensures fair pricing by batching deposits together and pricing them simultaneously based on the vault's actual NAV. + + +## Withdrawal Flow + + + +The withdrawal process mirrors the deposit flow but in reverse, using a similar epoch-based queuing system to ensure orderly redemptions and protect remaining shareholders. + +The process consists of: +1. **Request Phase**: Users call `requestWithdrawal()` to burn their shares and enter the withdrawal queue. The shares are immediately burned but assets remain in the vault. The system tracks each user's cost basis to calculate performance fees on profitable withdrawals. +2. **Fulfillment Phase**: The manager calls `fulfillWithdrawals()` to process pending withdrawals. During this phase: + - The vault's NAV is calculated to determine the current share price + - Assets are allocated proportionally to all withdrawers in the epoch + - The manager can set a maximum asset disbursement to ensure vault liquidity + - Performance fees are calculated on any gains above the original cost basis +3. **Execution Phase**: Users call `executeWithdrawal()` to receive their assets. Performance fees (if any) are automatically deducted and sent to the fee wallet. + +## Compounding Returns +The system also supports a unique redeposit feature where withdrawn assets can be automatically reinvested into the vault, useful for compounding strategies or manager-initiated rebalancing. + + +## Transfers + + +The Panoptic Vault implements custom transfer logic that goes beyond standard ERC20 functionality to maintain accurate performance fee calculations across share transfers. + +Key features of the transfer system: +- **Basis Tracking**: When shares are transferred, the cost basis (original deposit value) transfers proportionally with them. This ensures performance fees are calculated correctly regardless of share ownership changes. +- **Basis Averaging**: When transferring to an existing shareholder, the system uses the lower average basis between sender and receiver to prevent fee manipulation. +- **Standard Compatibility**: Despite the custom logic, transfers remain fully compatible with standard ERC20 interfaces, allowing integration with DEXs, wallets, and other DeFi protocols. + +The basis tracking system ensures that: +- Performance fees cannot be avoided by transferring shares before withdrawal +- New shareholders inherit the appropriate cost basis for their shares +- The vault maintains accurate records for fee calculations even with secondary market trading + +This sophisticated transfer mechanism allows Panoptic Vault shares to function as tradeable assets while maintaining the integrity of the performance fee system. + +## Contract Interactions +
+Deposits + +### `requestDeposit()` +Users initiate a deposit by calling `requestDeposit()` with the amount of assets they want to deposit. The assets are transferred from the user to the vault and a deposit request is created that must be fulfilled by the manager. + +```solidity +function requestDeposit(uint256 assets, address receiver, address owner) + external + returns (uint256 requestId) +``` + +----- + + +**Parameters:** +- `assets`: The amount of underlying assets to deposit +- `receiver`: The address that will receive the vault shares +- `owner`: The address that owns the deposit request + +**Returns:** +- `requestId`: A unique identifier for the deposit request + +----- + + +### `executeDeposit()` +Executes a pending deposit request after it has been fulfilled by the manager. This mints the vault shares to the receiver based on the share price set during fulfillment. + +```solidity +function executeDeposit(uint256 requestId, address receiver) + external + returns (uint256 shares) +``` + +----- + + +**Parameters:** +- `requestId`: The ID of the deposit request to execute +- `receiver`: The address to receive the minted shares + +**Returns:** +- `shares`: The amount of vault shares minted + + +----- + +### `cancelDeposit()` +Allows users to cancel their pending deposit request before it's fulfilled by the manager. The deposited assets are returned to the owner. + +```solidity +function cancelDeposit(uint256 requestId) external +``` + +----- + + +**Parameters:** +- `requestId`: The ID of the deposit request to cancel + +
+ + +
+Withdrawals + +### `requestWithdrawal()` +Users request to withdraw their shares by calling `requestWithdrawal()`. The shares are transferred from the user to the vault and a withdrawal request is created that must be fulfilled by the manager. + +```solidity +function requestWithdrawal(uint256 shares, address receiver, address owner) + external + returns (uint256 requestId) +``` + +----- + + +**Parameters:** +- `shares`: The amount of vault shares to redeem +- `receiver`: The address that will receive the withdrawn assets +- `owner`: The address that owns the withdrawal request + +**Returns:** +- `requestId`: A unique identifier for the withdrawal request + +----- + + +### `executeWithdrawal()` +Executes a pending withdrawal request after it has been fulfilled by the manager. This burns the vault shares and transfers the underlying assets to the receiver based on the share price set during fulfillment. + +```solidity +function executeWithdrawal(uint256 requestId, address receiver) + external + returns (uint256 assets) +``` + +----- + + +**Parameters:** +- `requestId`: The ID of the withdrawal request to execute +- `receiver`: The address to receive the withdrawn assets + +**Returns:** +- `assets`: The amount of underlying assets withdrawn + +----- + + +### `cancelWithdrawal()` +Allows users to cancel their pending withdrawal request before it's fulfilled by the manager. The vault shares are returned to the owner. + +```solidity +function cancelWithdrawal(uint256 requestId) external +``` + +----- + + +**Parameters:** +- `requestId`: The ID of the withdrawal request to cancel + +
+ +
+Transfers + +### `transfer()` +Standard ERC20 transfer function that moves vault shares between addresses. This implementation includes special handling for basis tracking used in withdrawal calculations. + +```solidity +function transfer(address to, uint256 amount) + public + override + returns (bool) +``` + +----- + + +**Parameters:** +- `to`: The recipient address +- `amount`: The amount of shares to transfer + +**Returns:** +- `bool`: True if the transfer was successful + +----- + + +### `_transferBasis()` +Internal function that handles the transfer of cost basis information along with share transfers. This is used to track the original deposit value for each share, which is important for calculating withdrawal amounts and potential profits/losses. +The new basis for the recipient will be the *minimum* average between the sender and receiver to ensure performance fee is not deflated through the transfer of negative pnl shares. + +```solidity +function _transferBasis(address from, address to, uint256 amount) internal +``` + +----- + +**Parameters:** +- `from`: The sender address +- `to`: The recipient address +- `amount`: The amount of shares being transferred + +
+ +
+Manager Actions + +### `fulfillDeposits()` +A manager-only function to fulfill pending deposit requests from the current epoch. The manager specifies the amount of assets to fulfill, and the contract calculates the number of shares to mint based on the vault's current Net Asset Value (NAV). The share price is determined implicitly on-chain. + +```solidity +function fulfillDeposits( + uint256 assetsToFulfill, + bytes memory managerInput +) external onlyManager; +```` + +----- + +**Parameters:** + + - `assetsToFulfill`: The total amount of underlying assets from the deposit queue to convert into vault shares. + - `managerInput`: Calldata for the `PanopticVaultAccountant` contract to compute the vault's NAV. This includes pool information, position data, and manager price quotes. + +**Notes:** + + - Any assets not fulfilled in the current epoch are rolled over to the next deposit epoch. + - Must be called before users can execute their deposits via `executeDeposit()`. + +----- + +### `fulfillWithdrawals()` + +A manager-only function to fulfill pending withdrawal requests from the current epoch. The manager specifies the number of shares to redeem. The contract calculates the corresponding amount of assets to be disbursed based on the vault's NAV. + +```solidity +function fulfillWithdrawals( + uint256 sharesToFulfill, + uint256 maxAssetsReceived, + bytes memory managerInput +) external onlyManager; +``` + +----- + +**Parameters:** + + - `sharesToFulfill`: The total amount of shares from the withdrawal queue to redeem for underlying assets. + - `maxAssetsReceived`: A safety parameter defining the maximum amount of assets the manager is willing to disburse for the `sharesToFulfill`. The transaction reverts if the calculated amount exceeds this value, protecting the vault from slippage or price anomalies. + - `managerInput`: Calldata for the `PanopticVaultAccountant` contract to compute the vault's NAV. + +**Notes:** + + - Any shares not fulfilled are rolled over to the next withdrawal epoch. + - The disbursed assets are moved into a reserve pool, from which users can claim them by calling `executeWithdrawal()`. + +
+ + + diff --git a/docs/vaults/integrations.md b/docs/vaults/integrations.md new file mode 100644 index 00000000..fa416484 --- /dev/null +++ b/docs/vaults/integrations.md @@ -0,0 +1,14 @@ +--- +sidebar_position: 7 +--- + +# Integrations + +## Panoptic Vault SDK +(COMING SOON...) + +## PanopticVaultHelper +(COMING SOON...) + + + diff --git a/docs/vaults/nav.md b/docs/vaults/nav.md new file mode 100644 index 00000000..711beaf6 --- /dev/null +++ b/docs/vaults/nav.md @@ -0,0 +1,87 @@ +--- +sidebar_position: 5 +--- + +# Net Asset Value (NAV) + +The Net Asset Value (NAV) represents the total value of all assets held by the vault, denominated in its `underlyingToken`. +It's the core metric used to determine the price of a vault share. + +When a manager fulfills [deposits or withdrawals](/docs/vaults/deposit-withdrawal), the NAV is calculated by the [`PanopticVaultAccountant`](/docs/vaults/vault-architecture#accountant) contract to ensure that new shares are minted and old shares are redeemed at the fair market value of the vault's portfolio. + +## Asset valuation + +The vault's assets are valued using a hybrid on-chain and manager-driven approach to balance accuracy with security. The valuation process accounts for all assets under the vault's control, including: + +- **Panoptic Positions**: The value of all long and short option positions held across various Panoptic pools. +- **Collateral**: The value of collateral deposited in Panoptic pools, redeemable for the underlying assets. +- **Accumulated Fees**: Premiums collected from selling options. +- **Fungible Tokens**: Balances of any other ERC20 tokens and native ETH held directly by the vault. + +To ensure prices are accurate and not manipulated, the vault manager provides price quotes which are cross-referenced against on-chain Time-Weighted Average Prices (TWAPs) from oracles. +If a manager-provided price deviates from the oracle's TWAP by more than the configured `maxPriceDeviation`, the NAV calculation fails, preventing transactions with stale or incorrect prices. +All asset values are ultimately converted to the vault's single `underlyingToken` to produce the final NAV. + + +## Computing the NAV + +The NAV is computed by the `computeNAV` function of the `PanopticVaultAccountant`, which is called by the vault manager during the [`fulfillDeposits`](/docs/vaults/deposit-withdrawal#deposit-flow) or [`fulfillWithdrawals`](/docs/vaults/deposit-withdrawal#withdrawal-flow) process. + +The computation follows these steps: +1. **Manager Input**: The manager supplies the necessary data, which includes a list of every Panoptic pool the vault interacts with, a complete list of all position token IDs held in each of those pools, and the manager's current price quotes for the assets. +2. **Input Verification**: The `PanopticVaultAccountant` performs critical safety checks: + * It verifies that the provided list of pools matches a pre-approved configuration for the vault, reverting with `InvalidPools()` on a mismatch. + * It ensures the list of positions is complete by comparing it against the on-chain record, reverting with `IncorrectPositionList()` if any are missing. + * It validates the manager's prices against on-chain oracles, reverting with `StaleOraclePrice()` if they deviate too much. +3. **Portfolio Valuation**: The accountant iterates through each pool to calculate its net worth. For each pool, it sums the value of collateral, fees, and all option positions. A key feature of the calculation is that if a single pool has a net negative value (i.e., represents a liability), its value is floored at zero (`Math.max(poolExposure0 + poolExposure1, 0)`). This means an underwater position in one pool does not detract from the total NAV derived from other, profitable pools. +4. **Final Aggregation**: The values from all pools are summed together, along with the value of any other tokens held directly by the vault, to arrive at the final NAV in the vault's `underlyingToken`. This value is then used to price shares for deposits and withdrawals. + + + + +
+Manager Actions + +### `computeNAV()` +A view function on the `PanopticVaultAccountant` contract that calculates the vault's total Net Asset Value (NAV) in terms of its `underlyingToken`. While not called directly, the **manager is responsible for constructing its `managerInput` payload**, which is passed into `fulfillDeposits()` and `fulfillWithdrawals()`. This function serves as the on-chain valuation engine for the vault. + +```solidity +function computeNAV( + address vault, + address underlyingToken, + bytes calldata managerInput +) external view returns (uint256 nav); +```` + +----- + +**Parameters:** + + - `vault`: The address of the `HypoVault` being valued. + - `underlyingToken`: The ERC20 token in which the NAV should be denominated. + - `managerInput`: A `bytes` string containing the `abi.encode`d data required for the calculation. The manager must provide: + - **`ManagerPrices[]`**: The manager's current price quotes for each asset pool. + - **`PoolInfo[]`**: A struct array describing every Panoptic pool the vault uses. The hash of this data must match a pre-approved configuration stored in the accountant contract. + - **`TokenId[][]`**: A complete, two-dimensional array of every Panoptic position NFT owned by the vault, organized by pool. + +**Notes:** + + - This function includes several **critical safety checks**. The manager's transaction will revert if the provided list of pools is invalid (`InvalidPools`), the list of positions is incomplete (`IncorrectPositionList`), or the manager's prices deviate too far from the on-chain oracles (`StaleOraclePrice`). + - As a **view function**, it can be called off-chain at any time for reporting purposes without incurring gas fees. + +
+ + diff --git a/docs/vaults/overview.md b/docs/vaults/overview.md new file mode 100644 index 00000000..7ae6d51e --- /dev/null +++ b/docs/vaults/overview.md @@ -0,0 +1,38 @@ +--- +sidebar_position: 1 +--- +# Introduction + +## Overview + +Panoptic Vaults are a decentralized asset management protocol that allows for the creation of on-chain, structured financial products. +At their core, these vaults are smart contract-based investment funds that specialize in executing automated strategies using [**perpetual options**](/docs/trading/perpetual-options) (perpetual option vaults or "POVs"). + +This design allows anyone to gain passive exposure to complex trading strategies—like covered calls, protective puts, or delta-neutral positions—that would otherwise require deep expertise and constant, active management. + +The architecture is built on a flexible and secure set of smart contracts that separates key duties. +A **Vault Manager** is responsible for executing the strategy, while a **Curator** establishes the risk parameters and safety rails, creating a system of checks and balances. +This modular framework allows for the permissionless creation of unique, manager-driven funds on top of Panoptic and other protocols. + +## Who Are Vaults For? + +The protocol is designed to serve two distinct groups within the DeFi ecosystem: +1. Depositors seeking yield and risk management +2. Managers seeking to deploy their strategies. + +### For Depositors (Investors, DAOs, & Treasuries) + +For those looking to put their capital to work, POVs offer a simple way to access sophisticated financial instruments. + +* **Diversify & Earn Yield:** Depositors can access strategies that generate returns in various market conditions, moving beyond typical lending and liquidity-providing yields. +* **Automated Risk Management:** DAOs and large token holders can use vaults to hedge their treasury assets. For example, a vault running a [protective put strategy](/docs/product/basic-options-strategies#buying-puts) can automatically shield a treasury from downside market volatility. +* **Passive Exposure:** Gain the benefits of complex options strategies without needing to be an expert. Simply deposit assets and let the automated vault do the work. + +### For Vault Managers & Strategists + +For skilled traders and asset managers, the protocol provides the infrastructure to deploy strategies and attract capital in a permissionless environment. + +* **Focus on Strategy:** Leverage a secure and audited contract framework to build your on-chain fund. Instead of building an entire protocol from scratch, you can focus on what you do best: developing and executing winning strategies. +* **Attract Capital:** Launch a vault to build a verifiable track record and attract capital from across the DeFi ecosystem. +* **Flexible Infrastructure:** The system is designed to be composable, allowing managers to create a wide range of strategies involving perpetual options and other EVM-based protocols. + diff --git a/docs/vaults/structured-products.md b/docs/vaults/structured-products.md new file mode 100644 index 00000000..c8df733c --- /dev/null +++ b/docs/vaults/structured-products.md @@ -0,0 +1,50 @@ +--- +sidebar_position: 2 +sidebar_label: "Structured Products" +--- + +# What are Structured Products? +**Structured Products** are pre-packaged, on-chain investment strategies that combine a primary asset or yield source with a derivative layer—in this case, [perpetual options](/docs/trading/perpetual-options) on Panoptic. +The goal is to create a specific risk-return profile that isn't possible with traditional assets alone. + +--- +## Perpetual Option Vaults (POVs) vs. DeFi Option Vaults (DOVs) +Perpetual Option Vaults (POVs) represent a significant evolution from the first generation of on-chain option strategies, commonly known as DeFi Option Vaults (DOVs). + +### DOVs (2020-2023) +DOVs pioneered on-chain yield generation with options but had key limitations: +* **Inflexibility:** Most DOVs were locked into a single, rigid strategy (e.g., selling weekly out-of-the-money calls). They operated on fixed expiries, meaning capital could sit idle between cycles, and managers couldn't adapt to changing market conditions. +* **Inefficient Pricing:** They often relied on off-chain auctions or basic algorithms to price their options. This could lead to options being sold for less than their fair market value, creating "toxic flow" and reducing yields for depositors. + +### POVs (2025-) +Panoptic's architecture provides far greater flexibility and efficiency: +* **Flexibility & Adaptability:** By using **perpetual options**, there are no fixed expiries. Strategies can be continuous and "rolling." The `manage()` function gives managers full discretion to adapt in real-time by moving strikes, adjusting position sizes, or even changing the strategy entirely. +* **Efficient On-Chain Pricing:** Panoptic’s novel infrastructure [prices options](/docs/product/streamia) based on the real-time trading activity and volatility within the underlying automated market maker (AMM). This leads to fairer, more efficient price discovery and ensures that the vault is compensated appropriately for the risk it takes on. + +--- +## Structured Product Strategies +The flexibility of the POV framework allows managers to create a wide array of strategies. Here are just a few examples: + +### Yield Generation +These vaults aim to generate returns on capital that are uncorrelated with typical DeFi yields. +* **Automated Option Selling:** The classic approach. Create vaults that systematically sell options to earn premiums, such as through [covered calls](/research/naked-covered-call-defi-options#covered-calls) (for yield on a held asset) or cash-secured puts (for yield on stablecoins). +* **Passive LPing:** Lend single-sided tokens in multiple pools to earn [passive yield](/docs/getting-started/passive-lp) from Uniswap LPs and option traders. +* **Volatility Harvesting:** Systematically sell volatility when it is high and perceived to be overpriced. This is often done by selling [straddles or strangles](/research/defi-option-strangle-straddle), which profit if the market stays within a predicted range. +* **Funding Rate Arbitrage:** Capture [funding rate differentials](/research/introduction-synthetic-perps#funding-rate-for-synthetic-perps) between perpetual futures and perpetual options. +* **Hedged Yield Farming:** Deploy capital into a primary yield source (e.g., a liquidity pool or lending protocol) and use Panoptic options to [hedge](/research/hedge-with-panoptic-options) against the directional risk of the underlying assets, protecting the principal while capturing the farm yield. + +### Risk Management & Hedging +These vaults focus on protecting capital or a treasury from adverse market movements. +* **Delta-Neutral LPing:** [Zero market exposure liquidity provisioning](/blog/delta-neutral-lp-hedge-uniswap-position) in Uniswap v3 and v4 to limit impermanent loss (IL) and earn twice as many LP fees. +* **Tail Risk Hedging:** Protect a portfolio against "black swan" events by systematically purchasing far out-of-the-money [put options](/docs/product/basic-options-strategies#buying-puts), providing a catastrophic insurance policy. +* **Treasury Protection:** A perfect use case for DAOs. A vault can implement a [collar](/docs/terms/collar) strategy (e.g., selling a call option to finance the purchase of a protective put option) to protect the treasury's assets from a market downturn at a low cost. + + + +--- +## Risks +While powerful, structured products come with their own unique set of risks that users must understand. + +* **Strategy Risk:** This is the primary risk. The vault's performance is entirely dependent on its underlying strategy succeeding. A strategy designed for a sideways market (like a short straddle) will lose significant money in a strong trending market. There is no guarantee that the manager's strategy will be profitable. +* **Complexity Risk:** The payoffs of option strategies are non-linear and can be difficult to understand. Users may not fully grasp the specific market conditions under which their investment will perform well or poorly. +* **Liquidity Risk:** Panoptic’s options are powered by the liquidity of the underlying Uniswap v3 or v4 pool. During periods of extreme volatility or low liquidity in the underlying pool, it may be difficult or expensive for a manager to enter or exit positions, which could negatively impact the vault's performance. diff --git a/docs/vaults/vault-architecture.md b/docs/vaults/vault-architecture.md new file mode 100644 index 00000000..08e95345 --- /dev/null +++ b/docs/vaults/vault-architecture.md @@ -0,0 +1,47 @@ +--- +sidebar_position: 3 +sidebar_label: "Architecture" +--- + +# Vault Architecture + +## Overview +POVs (perpetual option vaults) are a decentralized asset management system built to run strategies on top of Panoptic and other protocols. Its architecture is modular, separating the core responsibilities of asset management, portfolio valuation, and administration into distinct smart contracts and roles. + +Users deposit assets into a `HypoVault` and receive ERC20 shares that represent their claim on the vault's assets. A designated **Manager** actively manages the vault's portfolio by trading [perpetual options](/docs/trading/perpetual-options). The value of the vault's shares is determined by the **Accountant** contract, which calculates the Net Asset Value (NAV) of the portfolio. New vaults can be deployed permissionlessly using the **Vault Factory**. + +--- +## Roles/Smart contracts +The system's design is based on a separation of duties, where different actors and contracts are responsible for specific functions. This enhances security by limiting the scope of any single component. + +### Manager +The Manager is the active strategist for the vault. This role, controlled by an address set in the `HypoVault` contract, is responsible for the day-to-day operations and portfolio management. + +Key powers include: +* Executing arbitrary transactions from the vault to manage its Panoptic positions (`manage()`). +* Initiating the fulfillment of [deposit and withdrawal](/docs/vaults/deposit-withdrawal) requests (`fulfillDeposits()`, `fulfillWithdrawals()`). +* Providing the necessary data for the Accountant to perform NAV calculations. + +### Accountant +The `PanopticVaultAccountant` contract is the specialized valuation engine for the vault. Its sole responsibility is to calculate the [NAV](/docs/vaults/nav) of the vault's holdings. + +It performs several critical security checks, such as verifying the manager's price quotes against on-chain oracles and ensuring the manager has provided a complete list of the vault's positions. This separation prevents a malicious manager from manipulating the vault's reported value. + +### Curator +The [Curator](/docs/vaults/curation) is the `owner` of the `PanopticVaultAccountant` contract. This administrative role is responsible for the initial security setup of a vault's valuation parameters. + +The Curator's primary duty is to set and lock the approved list of Panoptic pools the vault can interact with (`updatePoolsHash` and `lockVault`). This acts as a safeguard, ensuring the Manager can only operate within a pre-defined, trusted set of pools when the Accountant calculates the NAV. + +### Vault Factory +The `HypoVaultFactory` is a simple factory contract used to deploy new `HypoVault` instances. It standardizes the vault creation process and provides a discoverable, on-chain registry of all vaults created through its `VaultCreated` event log. + +--- +## Risks +While the architecture is designed to be secure, users should be aware of several key risks: + +* **Manager Risk**: The Manager has significant control over the vault's assets. A malicious or compromised Manager could execute trades that are not in the best interest of the depositors, potentially leading to a loss of funds. +* **Oracle Risk**: The NAV calculation depends on external price oracles. A manipulated or faulty oracle could lead to an incorrect NAV, causing shares to be issued or redeemed at unfair prices. +* **Centralization Risk**: The `owner` of the vault (the "Curator" role for the Accountant) holds powerful administrative keys. If these keys are compromised, an attacker could change the Manager or alter the fundamental security parameters of the vault. +* **Smart Contract Risk**: As with any DeFi protocol, there is an inherent risk of bugs or vulnerabilities in the smart contracts that could be exploited. +* **Strategy Risk**: The value of the vault is dependent on the performance of the Manager's trading strategy. Options trading is complex and carries a high degree of [risk](/docs/panoptic-protocol/risks), which could result in the loss of deposited capital. + diff --git a/static/img/vault-deposit-flow.png b/static/img/vault-deposit-flow.png new file mode 100644 index 00000000..ed14969e Binary files /dev/null and b/static/img/vault-deposit-flow.png differ diff --git a/static/img/vault-withdraw-flow.png b/static/img/vault-withdraw-flow.png new file mode 100644 index 00000000..0f11777d Binary files /dev/null and b/static/img/vault-withdraw-flow.png differ