Fragmetric Liquid Restaking Program

The protocol mints receipt tokens (e.g., fragSOL) at a 1:1 ratio when the first deposit occurs: ```rust let receipt_token_mint_amount = if self.receipt_token_mint.supply == 0 { // receipt_token_mint_amount will be equal to asset_amount at the initial minting, so like either 1SOL = 1RECEIPT-TOKEN or 1SUPPORTED-TOKEN = 1RECEIPT-TOKEN. asset_amount } else { pricing_service.get_asset_amount_as_token( supported_token_mint_key.as_ref(), asset_amount, &self.receipt_token_mint.key(), )? }; ``` If the first deposited asset has a different number of decimal places than the receipt token, this could result in an incorrect exchange rate. For example: - If the first deposit is a staked SOL variant with 6 decimal places, but fragSOL expects 9 decimal places, fragSOL would be valued 1000x more than SOL, distorting its price relative to the underlying basket. However, the protocol mitigates that by having a flag that enables and disables deposits, so the protocol can be the first depositor to prevent this exploit. <br> However, the protocol includes a deposit enable/disable flag, which allows it to control when user deposits can begin. This ensures that the protocol can act as the initial depositor, setting the correct exchange rate before external deposits occur, and preventing distortions in receipt token pricing.

If the Jito Restaking Vault is paused, all CPI calls to it will fail, preventing the operator command cycle from advancing. This could result in a stalled execution loop where the system repeatedly attempts the same failing action. **Commands interacting with Jito Vault:** - `cmd1` → `ensure_state_update_required()` → [`close_vault_update_state_tracker()`](https://github.com/jito-foundation/restaking/blob/b096d1bf467813cde6f6f930ec2f6cc475324b28/vault_program/src/close_update_state_tracker.rs#L43) - `cmd1` → `ensure_state_update_required()` → [`initialize_vault_update_state_tracker()`](https://github.com/jito-foundation/restaking/blob/b096d1bf467813cde6f6f930ec2f6cc475324b28/vault_program/src/initialize_vault_update_state_tracker.rs#L60) - `cmd1` → `update_delegation_state()` → [`crank_vault_update_state_tracker()`](https://github.com/jito-foundation/restaking/blob/b096d1bf467813cde6f6f930ec2f6cc475324b28/vault_program/src/crank_vault_update_state_tracker.rs#L75) - `cmd3` → `withdraw()` → [`burn_withdrawal_ticket()`](https://github.com/jito-foundation/restaking/blob/b096d1bf467813cde6f6f930ec2f6cc475324b28/vault_program/src/burn_withdrawal_ticket.rs#L77) - `cmd6` → `request_withdraw()` → [`enqueue_withdrawal()`](https://github.com/jito-foundation/restaking/blob/c736bca8edc96efa603d580472b7d26c0d7224c7/vault_program/src/enqueue_withdrawal.rs#L65) - `cmd13` → `add_delegation()` → [`add_delegation()`](https://github.com/jito-foundation/restaking/blob/c736bca8edc96efa603d580472b7d26c0d7224c7/vault_program/src/add_delegation.rs#L60) - `cmd12` → `deposit()` → [`update_vault_balance()`](https://github.com/jito-foundation/restaking/blob/c736bca8edc96efa603d580472b7d26c0d7224c7/vault_program/src/update_vault_balance.rs#L38) - `cmd12` → `deposit()` → [`mint_to()`](https://github.com/jito-foundation/restaking/blob/b096d1bf467813cde6f6f930ec2f6cc475324b28/vault_program/src/mint_to.rs#L75)

Currently, the protocol relies on multiple pricing sources to fetch the price of the different assets it supports for deposits and withdrawals. Supported tokens that use Orca DEX as a pricing source retrieve the spot price instead of a time-weighted average price (TWAP). The configuration of the fund hedges volatility by doing the following: ```Price of FragJito = (JTO Price * JTO Reserve In fund) / FragJTO = JTO Price * K``` However, it should be noted that highly volatile tokens can be vulnerable to flash loan attacks to manipulate the spot price. Since only the JTO token uses the spot price and JTO is the only supported token for FragJTO, this is not currently a risk. The flash loan attack becomes viable if a supported token that uses a spot price is not the only token in a fund account.