Please upgrade to `docs.json` before proceeding and delete the legacy `mint.json` file.
```
## Embeds and HTML elements
{title}
... snippet content ...
(Loopscale Vault) | wfragSOL | Loopscale | [Link](https://app.loopscale.com/vault/7n5F6vLutwTPuVju9t4ZC22vHyJNyGbHKzaokdyWycjy) | | 2 | Lending
(Advanced Lending) | wfragSOL | Loopscale | [Link](https://app.loopscale.com/market/wfragSOL?role=lend) | | 3 | Lending | wfragSOL (Exponent Market) | Kamino | [Link](https://app.kamino.finance/lending/reserve/F4Pn9mAvbUazDmWET5yYATTiyLHLaCRTWgGex4tiMXAs/3w38SEhBoK2LRjuSL8p7cGAZ9hoFZ5gXjpza432HbeKx) | | | | | | | | 1 | Looping | wfragSOL/SOL | Loopscale | [Link](https://app.loopscale.com/loops/wfragsol-sol) | | 2 | Looping | Orca wfragSOL-JitoSOL/JitoSOL | Loopscale | [Link](https://app.loopscale.com/loops/orcaFragSolJitoSol-JitoSol) | | 3 | Looping | wfragBTC/zBTC | Loopscale | [Link](https://app.loopscale.com/loops/wfragbtc-zbtc) | | 4 | Looping | Orca wfragBTC-zBTC/zBTC | Loopscale | [Link](https://app.loopscale.com/loops/orcazBTCwfragBTC) | | 5 | Looping | wfragSOL/SOL | NX Finance | [Link](https://www.nxfinance.info/leverage/v2/fragSOL) | | | | | | | | 1 | Yield Trading | fragSOL-PT (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragSOL-2601) | | 2 | Yield Trading | fragSOL-YT (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragSOL-2601) | | 3 | Yield Trading | fragSOL-LP (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragSOL-2601) | | 4 | Yield Trading | fragJTO-PT (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragJTO-2601) | | 5 | Yield Trading | fragJTO-YT (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragJTO-2601) | | 6 | Yield Trading | fragJTO-LP (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragJTO-2601) | | 7 | Yield Trading | fragBTC-PT (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragBTC-2601) | | 8 | Yield Trading | fragBTC-YT (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragBTC-2601) | | 9 | Yield Trading | fragBTC-LP (29JAN26) | Rate X | [Link](https://app.rate-x.io/points?symbol=fragBTC-2601) | | 10 | Yield Trading | fragSOL-PT (31OCT25) | Exponent | [Link](https://www.exponent.finance/income/fragsol-31Oct25?preserveScroll=true) | | 11 | Yield Trading | fragSOL-YT (31OCT25) | Exponent | [Link](https://www.exponent.finance/farm/fragsol-31Oct25) | | 12 | Yield Trading | fragSOL-LP (31OCT25) | Exponent | [Link](https://www.exponent.finance/liquidity/fragsol-31Oct25) | | 13 | Yield Trading | fragBTC-PT (13JAN26) | Exponent | [Link](https://www.exponent.finance/income/fragbtc-12Jan26?preserveScroll=true) | | 14 | Yield Trading | fragBTC-YT (13JAN26) | Exponent | [Link](https://www.exponent.finance/farm/fragbtc-12Jan26) | | 15 | Yield Trading | fragBTC-LP (13JAN26) | Exponent | [Link](https://www.exponent.finance/liquidity/fragbtc-12Jan26) |
🌐 Built by Believers
Staking FRAG into FRAG² unites you with a community shaping Fragmetric's vision and driving collective growth.
🗳️ Fragmetric Vote Token
FRAG² holders receive Fragmetric Vote Tokens (FVT) to propose initiatives, vote on decisions, and lead community governance.
💰 Earn More with FRAG²
Stake FRAG to earn FRAG APY and boost your F Points, rewarding your active commitment to Fragmetric.
📊 Bi-Weekly Distribution
10,000,000 FVT
Distributed every 2 weeks to all FRAG² holders proportionally based on their staked amount and duration
| **Token Name** | Fragmetric (FRAG) |
| **Maximum Total Supply** | 1,000,000,000 FRAG |
| **Initial Circulating Supply** | 202,000,000 FRAG |
| **Token Standard** | Solana SPL Token |
| Allocation | Percentage | Initial Unlock | Cliff Period | Vesting Duration |
|---|---|---|---|---|
| Core Contributors | 20% | 0% | 1 year | 2 years (monthly) |
| Investors | 22% | 10% | 1 year | 2 years (monthly) |
| Foundation | 13% | 0% | None | 4 years (quarterly) |
| Ecosystem Development | 30% | 33.33% | None | 4 years (quarterly) |
| Airdrop (Season 1) | 15% | 53.33% | None | Fully unvested at season end |
(per Underlying Asset)"] ValuationService["Asset Valuation Service (Pricing Sources)"] NormalizedTokenMint <-->|Mint / Burn| TokenReserveAccount TokenReserveAccount <-->|Valuation Updates| ValuationService end style NormalizedTokenMint fill:#00AEEF,color:#fff style TokenReserveAccount fill:#4682B4,color:#fff style ValuationService fill:#FFC107,color:#000 ``` * **Normalized Token Mint:** Manages the minting and burning processes. * **Token Reserve Accounts:** Store underlying assets individually. * **Asset Valuation Service:** Provides dynamic pricing to ensure accurate valuation of underlying assets. ## **Importance of Normalized Tokens** * **Unified Representation:** Enables simplified management of multiple diverse assets through a single token interface. * **Accurate Valuation:** Continuously ensures fairness by reflecting real-time asset values. * **Efficiency & Scalability:** Reduces operational overhead and facilitates scalable yield management. * **Security & Control:** Restricts access to yield sources or authorized entities, ensuring the system’s security and integrity. # Overview Source: https://docs.fragmetric.xyz/protocol/module/ntp/overview ```mermaid theme={null} graph TD %% User Deposit Flow (via Fund Module) subgraph User Deposit Flow User["User Assets
(Multiple Asset Types)"] --> FundReserve["Fund Reserve Account"] FundReserve --> AssetDeposit end %% Normalized Token Pool Module subgraph Normalized Token Pool FRAG-22 direction TB AssetDeposit["Asset Deposit Handler
(Validate & Deposit)"] AssetNormalization["Asset Normalization
(Unified Asset Valuation)"] NormalizedReserve["Normalized Asset Reserve
(Stores Normalized Tokens)"] NormalizedTokenMint["Normalized Token Mint/Burn
(Yield Sources & Special Cases Only)"] AssetWithdrawal["Asset Withdrawal Handler
(Redeem Original Assets)"] end %% Yield Source Integration subgraph Yield Source Module direction TB Adaptor1["Yield Source Adaptor #1"] AdaptorN["Yield Source Adaptor #N"] end %% Special Cases (Slasher, etc.) SpecialCase["Special Entities
(e.g., Slasher)"] %% External Yield Sources ExternalYield1["External Yield Source #1"] ExternalYieldN["External Yield Source #N"] %% Flows between Fund and Normalized Pool AssetDeposit --> AssetNormalization AssetNormalization --> NormalizedReserve NormalizedReserve --> NormalizedTokenMint %% Flows between Normalized Pool and Yield Source Adaptors NormalizedTokenMint --> Adaptor1 NormalizedTokenMint --> AdaptorN Adaptor1 --> NormalizedReserve AdaptorN --> NormalizedReserve Adaptor1 --> ExternalYield1 AdaptorN --> ExternalYieldN ExternalYield1 --> Adaptor1 ExternalYieldN --> AdaptorN %% Special Case Flows NormalizedTokenMint --> SpecialCase SpecialCase --> AssetWithdrawal AssetWithdrawal --> NormalizedReserve NormalizedReserve --> AssetWithdrawal %% Styling classDef user fill:#0078D4,color:#fff classDef fund fill:#6A5ACD,color:#fff classDef internal fill:#34A853,color:#fff classDef integration fill:#FFC107,color:#000 classDef reserve fill:#4682B4,color:#fff classDef special fill:#F7941D,color:#fff classDef external fill:#00AEEF,color:#fff class User user class FundReserve fund class AssetDeposit,AssetNormalization,AssetWithdrawal internal class NormalizedReserve,NormalizedTokenMint reserve class Adaptor1,AdaptorN integration class SpecialCase special class ExternalYield1,ExternalYieldN external ``` The **Normalized Token Pool** within the FRAG-22 ecosystem serves as an essential mechanism for efficiently handling multiple asset types in a unified, composable manner. By standardizing different types of deposited tokens into a single, fungible token representation, it significantly simplifies asset management, enhances liquidity efficiency, and optimizes capital utilization across the protocol. At its core, the Normalized Token Pool aggregates diverse underlying assets deposited by users, assigning normalized values to maintain fair proportionality. This approach ensures seamless integration with various yield strategies, liquidity provisions, and DeFi applications, effectively removing complexity from multi-asset management. ### **Key Functionalities:** * **Asset Normalization:** Translates deposited assets into a common token representation, ensuring consistency in valuation and reward calculation. * **Liquidity Optimization:** Pools normalized assets to maximize efficiency, enabling simpler and faster reallocation of assets to yield-generating sources. * **Simplified Asset Management:** Reduces operational overhead for users and developers by abstracting away complexities associated with handling multiple distinct asset types. * **Composability and Interoperability:** Facilitates effortless integration with external DeFi applications, enabling users to leverage their normalized asset positions across diverse financial protocols seamlessly. The Normalized Token Pool thus forms a robust foundation within FRAG-22, enabling highly efficient, scalable, and simplified asset interactions across decentralized finance. # Fund Admin Source: https://docs.fragmetric.xyz/protocol/module/operator/fund-admin The **Fund Admin** manages core operations related to asset allocation, rebalancing, and reserve account maintenance within the FRAG-22 ecosystem. They ensure optimal asset deployment, maintain liquidity health, and swiftly respond to changing market conditions to secure efficient fund operations. ## Responsibilities and Operations ### 1. Asset Allocation Management Fund Administrators control asset distribution to various yield sources, ensuring maximized returns and efficiency. **Core Functions:** * **Allocate Assets**: Decides how assets are distributed across available yield sources. * **Rebalance Assets**: Adjust allocations periodically or as needed based on market dynamics and liquidity demands. **Process Overview:** ```mermaid theme={null} flowchart TD FundAdmin["Fund Administrator"] AllocationDecision["Allocation Decision"] AllocationDecision --> YieldSourceA["Yield Source A"] AllocationDecision --> YieldSourceB["Yield Source B"] AllocationDecision --> YieldSourceN["Yield Source N"] YieldSourceA --> Feedback["Performance & Yield Feedback"] YieldSourceB --> Feedback YieldSourceN --> Feedback Feedback --> AllocationDecision style FundAdmin fill:#00AEEF,color:#fff style AllocationDecision fill:#FFC107,color:#000 style YieldSourceA fill:#34A853,color:#fff style YieldSourceB fill:#34A853,color:#fff style YieldSourceN fill:#34A853,color:#fff style Feedback fill:#4682B4,color:#fff ``` ### 2. Reserve Account Management Responsible for maintaining sufficient liquidity within reserve accounts to facilitate smooth user interactions (deposits and withdrawals). **Core Functions:** * **Monitor Liquidity**: Continuously assesses reserve liquidity status. * **Trigger Rebalancing**: Initiates transfers between reserves and yield sources when liquidity thresholds are breached. **Process Overview:** ```mermaid theme={null} flowchart TD FundAdmin["Fund Administrator"] LiquidityMonitor["Liquidity Monitor"] LiquidityMonitor -->|Liquidity Adequate| NoAction["No Action Needed"] LiquidityMonitor -->|Liquidity Low| TriggerRebalance["Trigger Rebalance"] TriggerRebalance --> AssetWithdrawal["Withdraw Assets from Yield Sources"] AssetWithdrawal --> LiquidityReplenish["Replenish Reserve Account"] style FundAdmin fill:#00AEEF,color:#fff style LiquidityMonitor fill:#FFC107,color:#000 style NoAction fill:#34A853,color:#fff style TriggerRebalance fill:#F7941D,color:#fff style AssetWithdrawal fill:#4682B4,color:#fff style LiquidityReplenish fill:#0078D4,color:#fff ``` ## Permissions and Access Fund Administrators possess: * **Allocation Authority**: Authorized to set and adjust allocation ratios. * **Reserve Management Authority**: Can manage and rebalance reserve assets. This role has restricted permissions to secure operations, limiting the potential risk exposure of the fund's overall assets. ## Importance in FRAG-22 Fund Administrators ensure liquidity and asset management remains responsive and aligned with strategic objectives, providing a crucial layer of operational efficiency and stability to the ecosystem. # Overview Source: https://docs.fragmetric.xyz/protocol/module/operator/overview ## Overview In the FRAG-22 ecosystem, **Operators** are specialized roles responsible for critical operational tasks, ensuring the seamless execution, maintenance, and optimization of the entire system. Operators handle asset allocation, yield management, reward settlements, and various operational tasks within predefined permission structures, safeguarding both security and efficiency. ## Core Responsibilities of Operators * **Asset Allocation Management**: Strategically manage the allocation of pooled assets across multiple yield sources, maximizing returns and optimizing asset utilization. * **Yield Harvesting & Reward Management**: Periodically harvest yields generated by external yield sources, managing rewards securely and transparently within the Fund Reward Accounts. * **Reward Settlement**: Conduct regular settlement procedures, accurately distributing rewards to user accounts based on their recorded contributions. * **Normalized Token Management**: Oversee minting, burning, and redemption operations involving normalized tokens, ensuring accurate valuations and fairness across user interactions. * **Liquidity & Asset Rebalancing**: Maintain optimal liquidity levels within the Fund Module, promptly responding to withdrawal demands and market conditions. * **Operational Security & Compliance**: Maintain adherence to defined protocols, ensuring transactions, asset management, and settlements are compliant with established security standards. ## Operator Interaction within FRAG-22 Operators interact closely with multiple modules, including Fund, Reward, Yield Source, and Normalized Token Pool. Their coordinated efforts enable FRAG-22 to deliver predictable, secure, and efficient financial services within the decentralized ecosystem. ```mermaid theme={null} flowchart TD subgraph Operator_Roles["Operator Roles"] AssetAllocator[Asset Allocator] YieldHarvester[Yield Harvester] RewardSettlement[Reward Settlement Authority] TokenManager[Normalized Token Manager] LiquidityManager[Liquidity & Rebalancing Manager] end subgraph FRAG_22_Modules["FRAG-22 Modules"] FundModule[Fund Module] RewardModule[Reward Module] YieldSourceModule[Yield Source Module] NormalizedTokenPool[Normalized Token Pool] end AssetAllocator --> FundModule LiquidityManager --> FundModule YieldHarvester --> YieldSourceModule RewardSettlement --> RewardModule TokenManager --> NormalizedTokenPool FundModule --> NormalizedTokenPool YieldSourceModule --> RewardModule NormalizedTokenPool --> YieldSourceModule style Operator_Roles fill:#4682B4,color:#fff style FRAG_22_Modules fill:#00AEEF,color:#fff style AssetAllocator fill:#FFC107,color:#000 style YieldHarvester fill:#FFC107,color:#000 style RewardSettlement fill:#FFC107,color:#000 style TokenManager fill:#FFC107,color:#000 style LiquidityManager fill:#FFC107,color:#000 style FundModule fill:#34A853,color:#fff style RewardModule fill:#34A853,color:#fff style YieldSourceModule fill:#34A853,color:#fff style NormalizedTokenPool fill:#34A853,color:#fff ``` ## Permissions and Access Control Operator permissions are explicitly defined and strictly enforced: * **Allocation Authority**: Authorized to define asset allocation ratios. * **Settlement Authority**: Authorized to initiate reward settlements. * **Harvesting Authority**: Responsible for yield collection from external sources. * **Mint & Burn Authority**: Controls minting and burning of normalized tokens based on system requirements. These permissions ensure clarity, accountability, and the highest level of security in all operator-driven tasks. ## Importance of Operators in FRAG-22 Operators are crucial for the effective, secure, and efficient management of assets and yields. They ensure the FRAG-22 system remains responsive and robust, continuously optimizing performance while maintaining operational integrity. Their clearly defined roles and restricted permissions create a balanced operational environment, essential for maintaining user trust and system reliability. # Operator Permissions Matrix Source: https://docs.fragmetric.xyz/protocol/module/operator/permissions This matrix summarizes the permissions assigned to each operator role, clearly delineating responsibilities and access levels within the FRAG-22 system. | Permissions & Actions | Fund Admin | Reward Admin | Yield Operator | Pricing Operator | | ------------------------------------- | ---------- | ------------ | -------------- | ---------------- | | **Asset Allocation & Rebalancing** | ✅ | ❌ | ✅ | ❌ | | **Reserve Account Management** | ✅ | ❌ | ✅ | ❌ | | **Reward Settlement** | ❌ | ✅ | ❌ | ❌ | | **Reward Pool Management** | ❌ | ✅ | ❌ | ❌ | | **Asset Deployment to Yield Sources** | ✅ | ❌ | ✅ | ❌ | | **Yield Harvesting** | ✅ | ❌ | ✅ | ❌ | | **Asset Valuation & Pricing Updates** | ❌ | ❌ | ❌ | ✅ | ### Legend: * ✅ = Has Permission * ❌ = No Permission # Pricing Operator Source: https://docs.fragmetric.xyz/protocol/module/operator/pricing-operator ## Overview The **Pricing Operator** plays a critical role in the FRAG-22 ecosystem by ensuring accurate, reliable, and timely updates of asset valuations. Accurate pricing directly impacts normalized token valuation, redemption fairness, and overall asset management within the system. ## Responsibilities and Operations ### 1. Asset Valuation Updates The Pricing Operator periodically updates the valuation of underlying assets within the Normalized Token Pool using integrated pricing sources. **Core Functions:** * **Trigger Valuation Updates:** Regularly initiate asset valuation procedures. * **Integrate Pricing Sources:** Use predefined external pricing sources to ensure precise asset valuations. **Process Overview:** ```mermaid theme={null} flowchart TD PricingOperator["Pricing Operator"] TriggerUpdate["Trigger Asset Valuation Update"] TriggerUpdate --> PricingInterface["Pricing Interface"] PricingInterface --> ExternalSources["External Pricing Sources"] ExternalSources --> UpdatedValuation["Updated Asset Valuations"] UpdatedValuation --> NormalizedTokenPool["Normalized Token Pool"] style PricingOperator fill:#00AEEF,color:#fff style TriggerUpdate fill:#FFC107,color:#000 style PricingInterface fill:#34A853,color:#fff style ExternalSources fill:#4682B4,color:#fff style UpdatedValuation fill:#6A5ACD,color:#fff style NormalizedTokenPool fill:#F7941D,color:#fff ``` ### 2. Maintaining Exchange Ratios The Pricing Operator maintains accurate exchange ratios between normalized tokens and underlying assets, ensuring fair and transparent redemption processes. **Core Functions:** * **Calculate Exchange Ratios:** Dynamically calculate normalized token valuations based on the updated asset prices. * **Adjust Valuations:** Continuously monitor and adjust valuations to reflect market conditions accurately. **Process Overview:** ```mermaid theme={null} flowchart TD PricingOperator["Pricing Operator"] CalculateRatio["Calculate Exchange Ratios"] CalculateRatio --> PricingData["Current Pricing Data"] PricingData --> NormalizedToken["Normalized Token Mint"] NormalizedToken --> AdjustRatio["Adjust Exchange Ratios"] style PricingOperator fill:#00AEEF,color:#fff style CalculateRatio fill:#FFC107,color:#000 style PricingData fill:#34A853,color:#fff style NormalizedToken fill:#4682B4,color:#fff style AdjustRatio fill:#6A5ACD,color:#fff ``` ### 3. Pricing Data Integrity Ensures data integrity and consistency across the FRAG-22 system by verifying and validating pricing sources regularly. **Core Functions:** * **Data Verification:** Regularly verify pricing data from multiple integrated sources. * **Ensure Consistency:** Maintain consistency and transparency in reported valuations. **Process Overview:** ```mermaid theme={null} flowchart TD PricingOperator["Pricing Operator"] ValidateData["Validate Pricing Data"] ValidateData --> ExternalPricing["External Pricing Sources"] ExternalPricing --> DataIntegrity["Ensure Data Integrity"] DataIntegrity --> ConfirmConsistency["Confirm Pricing Consistency"] style PricingOperator fill:#00AEEF,color:#fff style ValidateData fill:#FFC107,color:#000 style ExternalPricing fill:#34A853,color:#fff style DataIntegrity fill:#4682B4,color:#fff style ConfirmConsistency fill:#6A5ACD,color:#fff ``` ## Permissions and Access Pricing Operators have the following clearly defined authorities: * **Valuation Update Authority**: * Explicitly authorized to initiate asset valuation updates via integrated pricing sources. * **Implicit Exchange Ratio Adjustment**: * Indirectly influences exchange ratios by updating underlying asset valuations. Exchange ratio adjustments are automatically computed by the system. **Note:** Pricing data integrity checks are automatically managed by the system internally and do not require explicit operator oversight. ## Importance in FRAG-22 The Pricing Operator ensures critical valuation accuracy, directly influencing normalized token fairness, reward calculations, and system trustworthiness, which are essential to the reliability and overall success of the FRAG-22 ecosystem. # Reward Admin Source: https://docs.fragmetric.xyz/protocol/module/operator/reward-admin The **Reward Admin** ensures accurate and timely distribution of accumulated rewards within the FRAG-22 ecosystem. This role triggers periodic settlements, manages on-chain reward settlement blocks, and maintains the integrity of the reward pools, directly aligning with the implemented system logic. ## Responsibilities and Operations ### 1. Reward Settlement Management The Reward Admin periodically initiates reward settlement procedures, recording global reward pool states into on-chain settlement blocks, but does **not directly calculate individual user rewards**. Users calculate and claim their individual rewards separately. **Core Functions:** * **Trigger Settlements:** Periodically initiate the settlement process, creating a new settlement block that snapshots the current global contribution state. * **Settlement Block Management:** Maintain up to 64 on-chain settlement blocks in a circular buffer, ensuring historical data availability for reward claims. **Process Overview:** ```mermaid theme={null} flowchart TD RewardAdmin["Reward Admin"] TriggerSettlement["Trigger Reward Settlement"] TriggerSettlement --> SnapshotContribution["Snapshot Current Global Contribution State"] SnapshotContribution --> CreateSettlementBlock["Create New Settlement Block (Circular Buffer)"] CreateSettlementBlock --> StoreOnChain["Store Block On-Chain (Max 64)"] style RewardAdmin fill:#00AEEF,color:#fff style TriggerSettlement fill:#FFC107,color:#000 style SnapshotContribution fill:#34A853,color:#fff style CreateSettlementBlock fill:#4682B4,color:#fff style StoreOnChain fill:#6A5ACD,color:#fff ``` ### 2. Reward Pool Maintenance The Reward Admin oversees the Fund Reward Accounts, ensuring these accounts correctly track global contributions and accumulated rewards. **Core Functions:** * **Monitor Global Contribution:** Ensure accurate tracking and updates of global contribution states within Fund Reward Accounts upon each settlement. * **Reward Reserve Oversight:** Confirm reward tokens are sufficiently reserved, maintaining the integrity and readiness of reward pools for claims. **Process Overview:** ```mermaid theme={null} flowchart TD RewardAdmin["Reward Admin"] MonitorFundReward["Monitor Fund Reward Account"] MonitorFundReward --> UpdateGlobalContribution["Update Global Contribution at Settlement"] UpdateGlobalContribution --> EnsureReserve["Ensure Reward Token Reserves Sufficient"] EnsureReserve -->|Sufficient| NoAction["No Action Needed"] EnsureReserve -->|Insufficient| NotifyFundAdmin["Notify Fund Admin to Rebalance Rewards"] style RewardAdmin fill:#00AEEF,color:#fff style MonitorFundReward fill:#FFC107,color:#000 style UpdateGlobalContribution fill:#34A853,color:#fff style EnsureReserve fill:#4682B4,color:#fff style NoAction fill:#6A5ACD,color:#fff style NotifyFundAdmin fill:#F7941D,color:#fff ``` ## Permissions and Access Reward Admins have: * **Settlement Trigger Authority:** Authorized to initiate periodic settlements, creating on-chain snapshots (settlement blocks). * **Fund Reward Account Oversight:** Permissions to monitor global contribution states and reward reserves but not individual user-level distributions directly. These clear permissions maintain operational integrity and security. ## Importance in FRAG-22 Reward Admins are essential for maintaining the fairness and transparency of the reward distribution system, enabling reliable and secure operation for users. # Roles in FRAG-22 Source: https://docs.fragmetric.xyz/protocol/module/operator/roles ## Operator Roles Operators within FRAG-22 manage critical system functions, ensuring smooth operations, security, and optimal performance across the fund, reward, and yield management processes. Each role is carefully defined to maintain strict security standards and effective operational control. ### 1. Fund Administrator The Fund Administrator manages overall asset allocation and strategic fund operations. **Key Responsibilities:** * **Asset Allocation Management** * Determines asset distribution among yield sources. * Manages periodic rebalancing and adjustments based on market conditions. * **Reserve Account Management** * Ensures sufficient liquidity for efficient deposit and withdrawal operations. * Monitors reserve health and initiates rebalancing actions when necessary. *** ### 2. Reward Administrator The Reward Administrator oversees the reward distribution process, settlement management, and reward integrity. **Key Responsibilities:** * **Reward Settlement Management** * Periodically initiates the settlement process to distribute accumulated rewards fairly based on user contributions. * Manages settlement blocks (max 64 blocks on-chain). * **Reward Pool Management** * Oversees the allocation of reward tokens to the reward reserve accounts. * Monitors the reward distribution to ensure accurate, timely, and fair allocations. *** ### 3. Yield Source Operator The Yield Source Operator directly manages interactions with external yield sources through standardized adapters. **Key Responsibilities:** * **Asset Deployment** * Deploys allocated assets to yield sources via adapters. * Executes asset withdrawal from yield sources back to the reserve as required. * **Yield Harvesting** * Periodically triggers the harvest of yields generated by deployed assets. * Ensures harvested yields are accurately recorded into the Fund Reward Account. *** ### 4. Pricing Operator The Pricing Operator manages asset pricing within the FRAG-22 ecosystem, crucial for maintaining accurate valuations and fair exchanges. **Key Responsibilities:** * **Asset Valuation Updates** * Regularly updates the valuation of assets within the normalized token pool. * Ensures pricing data integrity by interacting with integrated pricing sources. * **Exchange Ratio Maintenance** * Ensures the normalized token's valuation remains accurate relative to underlying assets, supporting fair redemption processes. *** Next, we'll detail the Operator Permissions Matrix. # Yield Operator Source: https://docs.fragmetric.xyz/protocol/module/operator/yield-operator The **Yield Operator** manages asset interactions with external yield-generating sources through standardized yield source adapters. This role ensures efficient allocation of assets, periodic harvesting of generated yields, and the management of asset withdrawals, directly interfacing with external DeFi protocols via defined adapter interfaces. ## Responsibilities and Operations ### 1. Asset Allocation to Yield Sources The Yield Source Operator allocates assets from the Fund's Reserve Account to designated yield sources using yield source adapters. **Core Functions:** * **Deploy Assets:** Transfer assets to external yield sources based on predefined allocation parameters. * **Manage Allocations:** Monitor asset positions, ensuring optimal utilization and efficient allocation. **Process Overview:** ```mermaid theme={null} flowchart TD YieldOperator["Yield Source Operator"] AllocationRequest["Asset Allocation Request"] AllocationRequest --> AdapterInterface["Yield Source Adapter Interface"] AdapterInterface --> ExternalYield["External Yield Source (e.g., Liquid Staking, Restaking)"] ExternalYield --> ConfirmAllocation["Confirm Asset Allocation"] style YieldOperator fill:#00AEEF,color:#fff style AllocationRequest fill:#FFC107,color:#000 style AdapterInterface fill:#34A853,color:#fff style ExternalYield fill:#4682B4,color:#fff style ConfirmAllocation fill:#6A5ACD,color:#fff ``` ### 2. Yield Harvesting & Collection The Yield Source Operator is responsible for harvesting generated yields from external sources and ensuring these yields are returned securely to the Fund Reward Account. **Core Functions:** * **Trigger Harvesting:** Periodically collect yields from allocated external yield sources. * **Yield Accounting:** Ensure harvested yields are accurately recorded within the Fund Reward Account. **Process Overview:** ```mermaid theme={null} flowchart TD YieldOperator["Yield Source Operator"] TriggerHarvest["Trigger Yield Harvesting"] TriggerHarvest --> AdapterHarvest["Yield Source Adapter Interface"] AdapterHarvest --> ExternalYield["External Yield Source"] ExternalYield --> YieldCollection["Collect Generated Yields"] YieldCollection --> FundRewardAccount["Fund Reward Account"] style YieldOperator fill:#00AEEF,color:#fff style TriggerHarvest fill:#FFC107,color:#000 style AdapterHarvest fill:#34A853,color:#fff style ExternalYield fill:#4682B4,color:#fff style YieldCollection fill:#6A5ACD,color:#fff style FundRewardAccount fill:#F7941D,color:#fff ``` ### 3. Asset Withdrawal & Rebalancing The Yield Source Operator manages withdrawal of assets from yield sources back to the Fund's reserve when rebalancing is needed or withdrawal demands occur. **Core Functions:** * **Withdraw Assets:** Execute asset withdrawal from yield sources, converting normalized tokens back into underlying assets. * **Asset Rebalancing:** Act promptly based on the Fund Administrator's instructions for optimal liquidity and asset management. **Process Overview:** ```mermaid theme={null} flowchart TD YieldOperator["Yield Source Operator"] WithdrawRequest["Asset Withdrawal Request"] WithdrawRequest --> AdapterWithdraw["Yield Source Adapter Interface"] AdapterWithdraw --> ExternalYield["External Yield Source"] ExternalYield --> ReturnAssets["Withdraw & Return Assets"] ReturnAssets --> FundReserve["Fund Reserve Account"] style YieldOperator fill:#00AEEF,color:#fff style WithdrawRequest fill:#FFC107,color:#000 style AdapterWithdraw fill:#34A853,color:#fff style ExternalYield fill:#4682B4,color:#fff style ReturnAssets fill:#6A5ACD,color:#fff style FundReserve fill:#F7941D,color:#fff ``` ## Permissions and Access Yield Source Operators have: * **Deployment & Withdrawal Authority:** Authorized to deploy and withdraw assets via yield source adapters. * **Harvesting Authority:** Explicit permission to trigger yield harvesting operations. * **Asset Rebalancing Authority:** Ability to execute rebalancing operations based on the Fund Administrator's directives. These clearly defined permissions ensure secure and efficient yield management. ## Importance in FRAG-22 Yield Source Operators are crucial for maximizing yield generation, managing external yield risks, and ensuring efficient asset utilization, thereby directly contributing to the overall performance and stability of the FRAG-22 system. # Settlement Source: https://docs.fragmetric.xyz/protocol/module/reward/claim In the FRAG-22 architecture, rewards are distributed based on each user’s contribution—determined by the amount of tokens held and the duration these tokens are held. The processes of **Settlement** and **Claiming** manage accurate reward distribution, ensuring fairness and precision. ## **Settlement in FRAG-22** Settlement is a periodic process where newly accumulated rewards in the Fund Reward Account are proportionally allocated to all contributors based on their accumulated contribution points during a defined time interval. Each settlement results in a **Settlement Block**, which records the reward details, enabling users to claim rewards later. **Why Settle?** * Ensures rewards are fairly allocated according to token holding duration and amount. * Provides transparency and auditability. * Maintains manageable on-chain storage for reward data. ## **Detailed Structure of a Settlement Block** Each settlement generates a **Settlement Block**, structured with the following key data: * **Reward Amount**: Total amount of reward tokens to distribute in the settlement period. * **Start and End Contribution Snapshot**: Captures global contributions at the beginning and end of the settlement period, defining the exact interval. * **Timestamp**: Time when the settlement block was created. These settlement blocks are stored in a **circular buffer** with a fixed length of **64**, meaning the system retains only the **64 most recent settlement records**. When a new block is created beyond this limit, it overwrites the oldest block. ### **Settlement Block Buffer Structure** ```mermaid theme={null} flowchart LR subgraph SettlementBlocks[Settlement Blocks Circular Buffer #40;Max 64#41;] direction LR Block1["Settlement Block #1"] --> Block2["..."] --> Block63["Settlement Block #63"] --> Block64["Settlement Block #64"] --> Block1 end classDef blockStyle fill:#4682B4,color:#fff,stroke:#333,stroke-width:2px, padding:20 classDef dotsStyle fill:#cccccc,color:#000,stroke:#333,stroke-width:1px,padding:10px,font-size:14px; class Block1,Block63,Block64 blockStyle; class Block2 dotsStyle; ``` * **Note**: Due to this circular nature, users must claim their rewards regularly to avoid losing access to older rewards. Due to the fixed storage size (64 settlement blocks), managing settlement blocks efficiently is critical: * **Resource Optimization**: Keeps on-chain storage efficient and cost-effective. * **Fairness and Incentivization**: Encourages users to claim rewards regularly, optimizing reward distribution fairness and system usage. ### **Settlement Block Management** * Settlement blocks are managed as a circular buffer (FIFO - First In, First Out). * Oldest settlement blocks are overwritten by the newest ones after exceeding 64 settlements. * Users who fail to claim rewards within 64 blocks (e.g., 64 days, if settlements are daily) permanently lose access to those rewards. These lost rewards typically revert to the treasury. ## **Reward Settlement Procedure** ```mermaid theme={null} flowchart TD Trigger[Periodic Trigger
#40;Daily, Weekly, or Manual by Operator#42;] --> CheckAccumulatedRewards["Check Fund Reward Account for Accumulated Rewards"] CheckAccumulatedRewards -->|Rewards Exist| CreateSettlementBlock["Create New Settlement Block"] CheckAccumulatedRewards -->|No Rewards| End["No Settlement Required"] CreateSettlementBlock --> RecordGlobalContribution["Snapshot Global Contributions #40;Start & End#42;"] RecordGlobalContribution --> AllocateRewardAmount["Record Total Reward Amount"] AllocateRewardAmount --> StoreSettlementBlock["Store Block in Circular Buffer #40;max 64#41;"] StoreSettlementBlock --> UpdateFundRewardAccount["Update Fund Reward Account's Global Contribution State"] UpdateFundRewardAccount --> Complete["Settlement Complete & Block Ready for User Claims"] style Trigger fill:#34A853,color:#fff style CheckAccumulatedRewards fill:#FFC107,color:#000 style CreateSettlementBlock fill:#4682B4,color:#fff style RecordGlobalContribution fill:#6A5ACD,color:#fff style AllocateRewardAmount fill:#6A5ACD,color:#fff style StoreSettlementBlock fill:#00AEEF,color:#fff style UpdateFundRewardAccount fill:#00AEEF,color:#fff style Complete fill:#34A853,color:#fff style End fill:#F7941D,color:#fff ``` * **Periodic Execution**: Ensures predictable intervals of reward calculation and distribution. * **Accurate Calculation**: Rewards precisely allocated proportional to recorded global contributions. * **Structured Storage**: Efficiently maintains only the most recent 64 settlements. ## **Reward Claim** Users individually initiate reward claims. Claims are calculated based on accumulated contributions and stored settlement data: ```mermaid theme={null} flowchart TD UserClaim["User Initiates Reward Claim"] --> UpdateUserContribution["Update User Contribution & Calculate Latest Rewards"] UpdateUserContribution --> FetchSettlementBlocks["Fetch Unclaimed Settlement Blocks"] FetchSettlementBlocks --> VerifyClaimable["Verify User's Claimable Amount Based on Contributions"] VerifyClaimable --> CheckReserveBalance["Check Reward Reserve Balance"] CheckReserveBalance -->|Sufficient Balance| ExecuteClaim["Transfer Rewards to User"] CheckReserveBalance -->|Insufficient Balance| Notify["Notify User (Claim Failed)"] ExecuteClaim --> UpdateUserAccount["Update User Reward Account
(Reduce Claimable Balance)"] ExecuteClaim --> FinalizeClaim["Finalize Claim Process"] Notify --> FinalizeClaim style UserClaim fill:#0078D4,color:#fff style UpdateUserContribution fill:#34A853,color:#fff style FetchSettlementBlocks fill:#4682B4,color:#fff style VerifyClaimable fill:#6A5ACD,color:#fff style CheckReserveBalance fill:#00AEEF,color:#fff style ExecuteClaim fill:#34A853,color:#fff style Notify fill:#F7941D,color:#fff style UpdateUserAccount fill:#4682B4,color:#fff style FinalizeClaim fill:#34A853,color:#fff ``` * **Contribution Update**: Before claiming, user-specific contributions are updated based on the latest holding period. * **Fetch Unclaimed Rewards**: User’s reward claims are calculated using historical settlement blocks not yet claimed. * **Reserve Check**: Ensures the system has sufficient liquidity to honor claims. * **Token Transfer**: Successful claims result in immediate reward token transfers to the user’s wallet, and claimable balances are updated accordingly. ## **User Implications** * **Regular Claims Recommended**: Users should periodically claim their accumulated rewards to prevent losing older rewards due to block overwriting. * **Transparency**: Users can always verify current and historical contributions and claimable rewards, ensuring complete transparency. # Contribution Source: https://docs.fragmetric.xyz/protocol/module/reward/contribution ### **Contribution Tracking** In the FRAG-22 standard, reward distribution isn’t simply based on the current balance of receipt tokens held by users. Instead, rewards reflect both **the quantity of tokens and the duration they are held**. Accurately tracking this combination of quantity and time—termed **“Contribution”**—ensures rewards are distributed fairly according to users’ actual involvement over time. When a user’s token balance changes, either by deposit, withdrawal, transfer, or wrapping/unwrapping, the system immediately recalculates their contribution to keep reward allocations precise and fair. ### **Contribution Calculation** Contribution calculation involves two primary data structures: * **Fund Reward Account**: Maintains global information about total token supply and cumulative contributions across all users. * **User Reward Account**: Tracks each user’s token balance, individual contribution, and the timestamp of their last contribution update. **The formula for calculating contribution is:** $\text{Contribution Increase} = \text{Token Balance at Previous Update} \times \text{Elapsed Time}$ **Upon any balance change, FRAG-22 performs two calculations:** 1. **Global Contribution Update** * Calculates the elapsed time since the last global update. * Increases global contribution by multiplying global token supply with the elapsed time. 2. **User Contribution Update** * Calculates the elapsed time since the user’s last update. * Increases user’s contribution by multiplying user’s token balance with the elapsed time. This immediate recalculation ensures both global and individual contribution records stay accurate. ### **Contribution Calculation Flow** ```mermaid theme={null} flowchart TD subgraph Contribution Update Cases %% Case 1: User Balance Change UserBalanceChange["User Balance Change (Deposit, Withdraw, Transfer, Wrap/Unwrap)"] --> CalculateElapsed_User["Calculate Elapsed Time since Last User Update"] CalculateElapsed_User --> UpdateUserContribution["Update User Contribution (User Balance × Elapsed Time)"] CalculateElapsed_User --> UpdateGlobalContribution_User["Update Global Contribution (Global Supply × Elapsed Time)"] UpdateUserContribution --> UpdateUserRewardAccount["Record to User Reward Account"] UpdateGlobalContribution_User --> UpdateFundRewardAccount_User["Record to Fund Reward Account"] UpdateUserRewardAccount --> ContributionUpdated["Contribution Updated & Ready for Settlement"] UpdateFundRewardAccount_User --> ContributionUpdated %% Case 2: Reward Settlement RewardSettlement["Reward Settlement (Fund-Level Periodic Update)"] --> CalculateElapsed_Settlement["Calculate Elapsed Time since Last Global Update"] CalculateElapsed_Settlement --> UpdateGlobalContribution_Settlement["Update Global Contribution (Global Supply × Elapsed Time)"] UpdateGlobalContribution_Settlement --> UpdateFundRewardAccount_Settlement["Record to Fund Reward Account"] UpdateFundRewardAccount_Settlement --> ContributionUpdated %% Case 3: User Claim Reward UserClaimReward["User Claim Reward"] --> CalculateElapsed_Claim["Calculate Elapsed Time since Last User Update"] CalculateElapsed_Claim --> UpdateUserContribution_Claim["Update User Contribution (User Balance × Elapsed Time)"] CalculateElapsed_Claim --> UpdateGlobalContribution_Claim["Update Global Contribution (Global Supply × Elapsed Time)"] UpdateUserContribution_Claim --> UpdateUserRewardAccount_Claim["Record to User Reward Account"] UpdateGlobalContribution_Claim --> UpdateFundRewardAccount_Claim["Record to Fund Reward Account"] UpdateUserRewardAccount_Claim --> ContributionUpdated UpdateFundRewardAccount_Claim --> ContributionUpdated end classDef trigger fill:#0078D4,color:#fff classDef calculate fill:#34A853,color:#fff classDef update fill:#4682B4,color:#fff classDef record fill:#6A5ACD,color:#fff classDef ready fill:#00AEEF,color:#fff class UserBalanceChange,RewardSettlement,UserClaimReward trigger class CalculateElapsed_User,CalculateElapsed_Settlement,CalculateElapsed_Claim calculate class UpdateUserContribution,UpdateGlobalContribution_User,UpdateGlobalContribution_Settlement,UpdateUserContribution_Claim,UpdateGlobalContribution_Claim update class UpdateUserRewardAccount,UpdateFundRewardAccount_User,UpdateFundRewardAccount_Settlement,UpdateUserRewardAccount_Claim,UpdateFundRewardAccount_Claim record class ContributionUpdated ready ``` ### **Data Structure of Contribution Records** ```mermaid theme={null} classDiagram class FundRewardAccount { +rewardPools : RewardPool[] } class RewardPool { +rewardTokenMint : Pubkey +rewardReserveAccount : Pubkey +accumulatedRewardPerContribution : u128 +lastAccumulatedRewardAmount : u64 +lastUpdatedAt : u64 } class UserRewardAccount { +userPools : UserRewardPool[] } class UserRewardPool { +rewardTokenMint : Pubkey +claimableRewardAmount : u64 +lastAccumulatedRewardPerContribution : u128 +userContribution : u128 } FundRewardAccount "1" --> "*" RewardPool : contains RewardPool "1" --> "*" UserRewardPool : tracks UserRewardAccount "1" --> "*" UserRewardPool : maintains ``` **Explanation:** * **Fund Reward Account** * **GlobalContribution**: Cumulative contribution of all users. * **GlobalTokenSupply**: Total outstanding token supply at the last update. * **LastUpdatedTimestamp**: Timestamp of the last global contribution update. * **User Reward Account** * **UserContribution**: User’s accumulated contribution over time. * **UserTokenBalance**: User’s token balance at the last update. * **LastUpdatedTimestamp**: Timestamp of the last individual update. This structure enables immediate updates on contribution states, facilitating accurate reward calculation and settlement. ### **Contribution Tracking Example** To clearly illustrate contribution calculations, consider three users—**Alice**, **Bob**, and **Chuck**—and how their contributions evolve: | **Time (seconds)** | **Alice’s Tokens** | **Bob’s Tokens** | **Chuck’s Tokens** | **Total Token Supply** | **Alice’s Contribution** | **Bob’s Contribution** | **Chuck’s Contribution** | **Global Contribution** | | :----------------- | :----------------- | :--------------- | :----------------- | :--------------------- | :----------------------- | :--------------------- | :----------------------- | :---------------------- | | 0 | 500 | 300 | 200 | 1000 | 0 | 0 | 0 | 0 | | 300 | 800 (+300) | 300 | 400 (+200) | 1500 (+500) | 150,000 | 90,000 | 60,000 | 300,000 | | 480 | 600 (-200) | 500 (+200) | 400 | 1500 | 294,000 | 144,000 | 132,000 | 570,000 | | 600 | 600 | 500 | 400 | 1500 | 366,000 | 204,000 | 180,000 | 750,000 | **How to read this table:** * From 0 to 300 seconds: * Alice held 500 tokens for 300 seconds: **Alice’s contribution increase**: $500 \times 300 = 150,000$ * Total global tokens were 1000 for 300 seconds: **Global contribution increase**: $1000 \times 300 = 300,000$ * Similarly, contributions for Bob and Chuck are calculated at each interval. ### **Contribution Tracking Outcomes** By employing immediate recalculation upon every balance change: * **Fairness**: Ensures that rewards match user participation accurately. * **Transparency**: Users can verify their contributions and corresponding rewards clearly. * **Precision**: Facilitates precise and trustworthy reward distribution aligned to actual token holding duration. FRAG-22’s structured approach provides a transparent, verifiable, and accurate reward distribution mechanism by effectively managing user contributions in real-time. # Distribution by DeFi Source: https://docs.fragmetric.xyz/protocol/module/reward/defi To integrate FRAG-22 with external DeFi protocols, users must first **wrap** their FRAG-22 receipt tokens into wrapped tokens (**wFRAG** assets). The wrapping process transfers original FRAG assets into the Fund’s reserve account, minting corresponding SPL-compliant wrapped tokens to represent those original assets within external DeFi protocols. These wrapped tokens held by external DeFi vaults accumulate their own contributions within FRAG-22’s reward tracking system. Since the FRAG-22 module cannot directly monitor individual user actions inside external DeFi protocols, the wrapped tokens’ accumulated rewards are distributed to the corresponding DeFi vaults. These external DeFi vaults then internally distribute the rewards to their own participants. ## **Technical Process** ### **Wrapping Procedure (User → DeFi Vault)** **Process**: * **User Action**: User initiates the wrapping of their FRAG-22 receipt tokens. * **FRAG-22 Action**: * Transfers user’s original FRAG-22 tokens to the Fund’s **Reserve Account**. * Mints an equal amount of SPL-compliant wrapped tokens (e.g., **wFRAG**) and sends them to the user’s account. * Updates the **Wrapped Token Holder Account** to reflect the increase in the wrapped token balance. **Consequence**: * Wrapped tokens become representative assets in external DeFi protocols. * Contribution for rewards now begins tracking in the **Wrapped Token Holder Account**. ### **Wrapped Asset and Contribution Structure** **Data Structures involved**: ```mermaid theme={null} classDiagram class User { +FRAGAssetBalance : u64 +wFRAGAssetBalance : u64 } class ReserveAccount { +FRAGAssetBalance : u64 } class WrappedTokenHolderAccount { +WrappedTokenBalance : u64 +Contribution : u128 +ClaimableRewards : map
(Accumulates FRAG Tokens)"] ReserveAccount -->|Mint wFRAG Tokens| WrappedHolderAccount["Wrapped Token Holder Account
(Represents DeFi Protocol)
- Tracks wFRAG Balance
- Tracks Contribution
- Accumulates Rewards"] WrappedHolderAccount --> ContributionUpdate["Update Contribution
(on Balance Change or Claim)"] ContributionUpdate --> FundRewardAccount["Fund Reward Account
- Tracks Global Contribution
- Records Rewards per Settlement"] FundRewardAccount --> RewardSettlement["Periodic Reward Settlement
(Allocates Rewards per Contribution)"] RewardSettlement --> RewardReserve["Reward Reserve Account
(Holds Reward Tokens)"] RewardReserve -->|DeFi Protocol Claims Reward| WrappedHolderClaim["Claim Rewards for Wrapped Holder"] end subgraph External DeFi Protocol WrappedHolderClaim --> DeFiRewardVault["DeFi Reward Vault"] DeFiRewardVault -->|Distributes Rewards Internally| DeFiUsers["Individual Users in DeFi Vault"] end %% Styling style User fill:#0078D4,color:#fff style WrapRequest fill:#FFC107,color:#000 style ReserveAccount fill:#34A853,color:#fff style WrappedHolderAccount fill:#6A5ACD,color:#fff style ContributionUpdate fill:#4682B4,color:#fff style FundRewardAccount fill:#4682B4,color:#fff style RewardSettlement fill:#34A853,color:#fff style RewardReserve fill:#6A5ACD,color:#fff style WrappedHolderClaim fill:#F7941D,color:#fff style DeFiRewardVault fill:#00AEEF,color:#fff style DeFiUsers fill:#0078D4,color:#fff ``` ## **Why this Approach?** * **Fairness**: Users participating in external DeFi protocols through wrapped FRAG assets still earn rewards proportional to their underlying FRAG asset holdings. * **Scalability**: Allows easy integration with multiple DeFi protocols without adding complexity to individual user tracking. * **Transparency**: All reward flows remain clear, auditable, and on-chain, up to the point of distribution to external DeFi protocols. # Overview Source: https://docs.fragmetric.xyz/protocol/module/reward/overview ## **FRAG-22 : Reward Module** The Reward module functions as the central mechanism for reward tracking, calculation, and distribution within the FRAG-22 ecosystem. It continuously tracks users’ contributions based on their holdings of receipt tokens, systematically manages reward settlements, and handles the precise distribution of rewards to both individual users and external DeFi protocols. By ensuring accurate and transparent reward management, the Reward module incentivizes user participation and enhances overall system efficiency. ```mermaid theme={null} graph TD %% User interactions User[User] -- Update Receipt Token Holdings --> ContributionTracking User -- Claim Reward Request --> RewardClaimProcess subgraph Reward Module %% Contribution Tracking Flow (Blue Arrows) ContributionTracking -->|Update| UserRewardAccount ContributionTracking -->|Update| FundRewardAccount %% Reward Settlement Flow (Green Arrows) FundRewardAccount -->|Periodic Settlement| RewardSettlement RewardSettlement -->|Allocate Rewards| UserRewardAccount RewardSettlement -->|Allocate Rewards to Wrapped Token| WrappedTokenHolderRewardAccount %% Reward Claim Flow (Purple Arrows) UserRewardAccount -->|User Initiates Claim| RewardClaimProcess WrappedTokenHolderRewardAccount -->|DeFi Protocol Initiates Claim| RewardClaimProcess %% Reward Distribution (Actual Reward Token Transfers) RewardClaimProcess -->|Transfer Reward Tokens| RewardTokenReserveAccount end %% External Entities RewardTokenReserveAccount -->|Transfer Rewards| User RewardTokenReserveAccount -->|Transfer Rewards| ExternalDeFiProtocol %% Styling the arrows with distinct colors linkStyle 0 stroke:#00AEEF,stroke-width:2px,color:#00AEEF linkStyle 1 stroke:#00AEEF,stroke-width:2px,color:#00AEEF linkStyle 2 stroke:#34A853,stroke-width:2px,color:#34A853 linkStyle 3 stroke:#34A853,stroke-width:2px,color:#34A853 linkStyle 4 stroke:#34A853,stroke-width:2px,color:#34A853 linkStyle 5 stroke:#7B68EE,stroke-width:2px,color:#7B68EE linkStyle 6 stroke:#7B68EE,stroke-width:2px,color:#7B68EE linkStyle 7 stroke:#FF8C00,stroke-width:2px,color:#FF8C00 linkStyle 8 stroke:#FF8C00,stroke-width:2px,color:#FF8C00 linkStyle 9 stroke:#FF8C00,stroke-width:2px,color:#FF8C00 classDef user fill:#0078D4,color:#ffffff classDef internal fill:#34A853,color:#ffffff classDef external fill:#FFA500,color:#ffffff class User,ExternalDeFiProtocol user class ContributionTracking,UserRewardAccount,FundRewardAccount,RewardSettlement,WrappedTokenHolderRewardAccount,RewardClaimProcess,RewardTokenReserveAccount internal ``` ### **Core Responsibilities:** * **Contribution Tracking**: Dynamically tracks users’ and the fund’s contributions, based on changes in receipt token holdings. * **Reward Settlement**: Periodically settles and allocates reward amounts to users’ reward accounts based on accurate contribution calculations. * **Wrapped Token Reward Distribution**: Manages and allocates rewards intended specifically for wrapped token holders (DeFi protocols), which then distribute these rewards internally. * **Transparent Reward Accounting**: Maintains detailed records for every reward calculation, settlement, and distribution event, ensuring complete transparency and auditability. # Reward Pool Source: https://docs.fragmetric.xyz/protocol/module/reward/reward-pool ## **Reward Pool Management** The **Reward Pool** section describes the core structure and processes within the Reward Module of FRAG-22. This section explains how rewards are accumulated, tracked, managed, and ultimately distributed to both individual users. The reward pool logic ensures accurate, transparent, and fair distribution aligned with each user’s and DeFi protocol’s respective asset holdings. ## **Reward Pool Structure** ```mermaid theme={null} graph TD subgraph Reward Module subgraph Reward_Pool_A ["Reward Pool - Token A"] RewardTokenA["Reward Token Mint A"] RewardReserveA["Reward Reserve Account A"] GlobalContributionA["Global Contribution A"] RewardSettlementA["Settlement Record A"] end subgraph Reward_Pool_B ["Reward Pool - Token B"] RewardTokenB["Reward Token Mint B"] RewardReserveB["Reward Reserve Account B"] GlobalContributionB["Global Contribution B"] RewardSettlementB["Settlement Record B"] end subgraph Reward_Pool_N ["Reward Pool - Token N"] RewardTokenN["Reward Token Mint N"] RewardReserveN["Reward Reserve Account N"] GlobalContributionN["Global Contribution N"] RewardSettlementN["Settlement Record N"] end subgraph User_Reward_Accounts ["User Reward Accounts"] UserRewardAccount["User Reward Account
- Contributions per Token
- Claimable per Token"] end FundReserveAccount["Fund Reserve Account
(Source of Reward Settlements)"] end classDef poolA fill:#4682B4,color:#fff classDef poolB fill:#6A5ACD,color:#fff classDef poolN fill:#8A2BE2,color:#fff classDef user fill:#34A853,color:#fff classDef fundReserve fill:#F7941D,color:#fff class RewardTokenA,RewardReserveA,GlobalContributionA,RewardSettlementA poolA class RewardTokenB,RewardReserveB,GlobalContributionB,RewardSettlementB poolB class RewardTokenN,RewardReserveN,GlobalContributionN,RewardSettlementN poolN class UserRewardAccount user class FundReserveAccount fundReserve ``` The Reward Module is built upon two primary reward pool accounts: * **Fund Reward Account** * **User Reward Account** These pools maintain accurate and real-time reward state information, enabling precise distribution of rewards across different participants in the FRAG-22 ecosystem. ### **Fund Reward Account** The **Fund Reward Account** acts as the central repository for tracking and managing all rewards accrued at the fund-wide level. **Managed Data:** * Total accumulated rewards per reward token. * Global reward state, tracking the overall distribution status across the Fund. The Fund Reward Account accumulates rewards from various yield sources and periodically updates its state through a mechanism called **Reward Settlement**, ensuring accurate allocation of rewards based on each user’s relative contributions. ### **User Reward Account** Each user possesses an individual **User Reward Account**, precisely tracking user-specific reward balances and contributions. The user account is updated whenever there is a change in the user’s holdings of receipt tokens (e.g., through deposits, withdrawals, or transfers). **Managed Data:** * User-specific accumulated rewards per reward token. * User’s contribution (holding-based) records. * Reward claimable status (whether rewards are available to claim). These individual accounts ensure users have accurate visibility into their accrued rewards and clearly manage their eligibility to claim rewards directly. ## **Reward Pool Update Logic** Reward pools are systematically updated at two distinct moments: * **Fund-level Reward Update (Settlement)**: * Triggered periodically (manually or through a predefined automated interval). * Calculates total accrued rewards since the last settlement. * Distributes these rewards proportionally to User Reward Accounts and Wrapped Token Holder Reward Accounts based on recorded contributions. * **User-level Reward Update (Contribution Tracking)**: * Automatically triggered by changes in user receipt token holdings (deposits, withdrawals, transfers). * Immediately updates a user’s relative contribution status, which directly influences their accrued rewards in subsequent fund-level settlements. ## **Detailed Reward Pool Procedures** The following step-by-step procedures detail reward management within the Reward Module, clearly outlining the logic for reward accumulation, tracking, updating, and distribution: ### **Contribution Tracking** **Trigger**: Any change in user holdings of receipt tokens. **Action**: * The system immediately recalculates the user’s contribution based on their new token balance. * Updates the User Reward Account to reflect the new contribution state. * Simultaneously updates the global contribution state in the Fund Reward Account. **Outcome**: * Both user-specific and global contribution states remain current, ensuring accurate reward calculations in subsequent settlements. ### **Reward Settlement (Fund-Level)** **Trigger**: Periodically (e.g., daily, weekly, or upon manual operator invocation). **Action**: * The Fund Reward Account aggregates all newly accumulated rewards since the previous settlement. * It then calculates proportional rewards for each user based on recorded contributions during this interval. * Allocated rewards are then recorded in respective User Reward Accounts, updating claimable balances. **Outcome**: * Accurate distribution of rewards proportional to each entity’s contribution, ready to be claimed. ### **Reward Claiming (User & DeFi Protocols)** **Trigger**: User or DeFi protocol initiates reward claiming via the Reward Claim Process. **Action**: * Checks the User Reward Account for available claimable rewards. * Validates the claim request and confirms sufficient reward tokens are available in the Reward Token Reserve Account. * Executes the token transfer from the Reward Token Reserve Account directly to the claimant’s designated account. **Outcome**: * Successful reward distribution to the claimant. * Reward accounts update immediately, reducing claimable balances accordingly. ## **Reward Pool Accounting & Recordkeeping** Every reward-related operation (contribution updates, settlements, and reward claims) updates the following reward accounts to maintain precise records: * **Fund Reward Account** (Global reward tracking) * **User Reward Account** (User-specific reward tracking) * **Reward Token Reserve Account** (Actual reward tokens storage) This clear separation of responsibilities across dedicated reward accounts ensures high transparency, auditability, and security in reward management. # Wrap & Unwrap (DeFi Mode) Source: https://docs.fragmetric.xyz/protocol/module/wrap-unwrap ## wfragSOL & wfragJTO fragSOL and fragJTO utilize the Transfer Hook of Token Extension (also known as Token-2022), an advanced token program on the Solana blockchain. While Token-2022 is becoming increasingly common in DeFi recently, many dApps still do not support it. To integrate with such dApps, there's another form of Fragmetric Restaked Tokens called wfragSOL (Wrapped Fragmetric Restaked SOL), wfragJTO (Wrapped Fragmetric Restaked JTO). ## What are wfragSol & wfragJTO wfragSOL and wfragJTO are standard SPL tokens that represent an account's share of the total supply of fragSOL and fragJTO, respectively. They serve as the wrapped versions of fragSOL and fragJTO, designed to maximize DeFi compatibility. For example, when converting fragSOL to wfragSOL, the corresponding amount of fragSOL is locked in the wfragSOL program's token account, and an equal amount of wfragSOL is minted. Conversely, when unwrapping wfragSOL, it is burned, and the equivalent amount of fragSOL is unlocked. wfragSOL holders can always convert wfragSOL to fragSOL at a 1:1 ratio, and vice versa. ## How to wrap and unwrap
(Tracks Contribution & Rewards)"] WrappedTokenHolderAccount -->|Claim Rewards| RewardPool["Reward Pool"] RewardPool -->|Transfer Reward Tokens| ExternalDeFiRewardAccount["External DeFi Protocol Reward Account"] end subgraph External DeFi Protocol ExternalDeFiVault -->|Internal Distribution| DeFiUsers["DeFi Protocol Users"] ExternalDeFiRewardAccount -->|Internal Reward Distribution| DeFiUsers end style User fill:#34A853,color:#fff style ReserveAccount fill:#4682B4,color:#fff style WrappedTokenMint fill:#00AEEF,color:#fff style UserWrappedAccount fill:#0078D4,color:#fff style ExternalDeFiVault fill:#FFC107,color:#000 style WrappedTokenHolderAccount fill:#6A5ACD,color:#fff style RewardPool fill:#4682B4,color:#fff style ExternalDeFiRewardAccount fill:#FFC107,color:#000 style DeFiUsers fill:#34A853,color:#fff ``` The Wrap Module positions FRAG-22 assets for broader decentralized use, combining security, simplicity, and interoperability to extend asset functionality far beyond the native FRAG-22 ecosystem. # Unwrap Source: https://docs.fragmetric.xyz/protocol/module/wrap/unwrap "Unwrap" converts Wrapped FRAG (**wFRAG**) tokens back into original FRAG assets. It ensures accurate redemption of underlying assets and appropriate reward management within FRAG-22. ## Why Unwrap? Unwrapping wFRAG tokens into original FRAG assets allows users to: * **Retrieve Original Assets:** Redeem underlying FRAG tokens at any point. * **Claim Rewards:** Access accumulated rewards and settle any outstanding balances associated with their token holdings. * **Rebalance Holdings:** Adjust their asset allocation according to changing market conditions or investment strategies. ## Detailed Unwrap Procedure ### Step-by-Step Process ```mermaid theme={null} flowchart TD User[User] -->|Return wFRAG Tokens| ReserveAccount["Reserve Account"] ReserveAccount -->|Validate & Burn wFRAG| wFRAGBurn["Burn Wrapped Tokens"] wFRAGBurn --> FRAGRelease["Release Underlying FRAG Tokens"] FRAGRelease --> UserFRAGAccount["User's Wallet"] FRAGRelease --> RewardUpdate["Update & Settle Reward Balances"] style User fill:#34A853,color:#fff style ReserveAccount fill:#4682B4,color:#fff style wFRAGBurn fill:#00AEEF,color:#fff style FRAGRelease fill:#0078D4,color:#fff style UserFRAGAccount fill:#FFC107,color:#000 style RewardUpdate fill:#6A5ACD,color:#fff ``` 1. **User Initiates Unwrapping** Users request unwrapping by returning wrapped FRAG tokens (wFRAG) back to FRAG-22. 2. **Reserve Account Validation** The Reserve Account confirms the wFRAG token authenticity and the user's token balance. 3. **Burn wFRAG Tokens** Once validated, the corresponding amount of wFRAG tokens is burned to maintain accurate total supply records. 4. **Release Underlying FRAG Assets** The Reserve Account releases the equivalent original FRAG tokens to the user's wallet. 5. **Update Reward Accounts** Reward contributions and balances are recalculated and settled based on the final holdings after unwrapping. ### Technical Components | Component | Role | Description | | ---------------------------- | ---------------------------- | ----------------------------------------------------------- | | **Reserve Account** | Asset Validation & Custody | Validates and accepts wFRAG for burning. | | **Wrapped Token Burn** | Token Supply Management | Burns returned wFRAG tokens to reduce circulating supply. | | **Underlying Asset Release** | FRAG Asset Transfer | Releases FRAG tokens back to the user’s account. | | **Reward Account Update** | Reward Tracking & Settlement | Recalculates contributions and settles outstanding rewards. | ### Unwrap Operation Benefits * **Asset Flexibility:** Allows users immediate access to original FRAG assets when desired. * **Accurate Reward Management:** Ensures precise calculation and settlement of rewards upon redemption. * **Maintains Asset Integrity:** Keeps asset supply and circulation transparent and correctly balanced within the FRAG-22 ecosystem. # Wrap Source: https://docs.fragmetric.xyz/protocol/module/wrap/wrap "Wrap" converts FRAG assets into Wrapped FRAG (**wFRAG**), enabling users to participate in external DeFi ecosystems while preserving reward tracking within the FRAG-22 framework. ## Why Wrap? Wrapping FRAG tokens into wFRAG allows: * **External Integration:** Enables FRAG assets to seamlessly integrate into external DeFi protocols. * **Enhanced Liquidity:** Improves asset liquidity and flexibility across DeFi ecosystems. * **Reward Tracking:** Preserves reward accumulation accurately FRAG-22 while assets are externally deployed. ## Detailed Wrap Procedure ### Step-by-Step Process ```mermaid theme={null} flowchart TD User[User] -->|Deposit FRAG Tokens| ReserveAccount["Reserve Account"] ReserveAccount -->|Validation Successful| wFRAGMint["Mint wFRAG Tokens"] wFRAGMint --> UserWrappedTokenAccount["User's Wallet (wFRAG)"] UserWrappedTokenAccount --> ExternalDeFi["External DeFi Protocol"] style User fill:#34A853,color:#fff style ReserveAccount fill:#4682B4,color:#fff style wFRAGMint fill:#00AEEF,color:#fff style UserWrappedTokenAccount fill:#0078D4,color:#fff style ExternalDeFi fill:#FFC107,color:#000 ``` 1. **User Initiates Wrapping** Users initiate the wrapping process by depositing FRAG tokens into the FRAG-22 Reserve Account. 2. **Reserve Account Validation** The Reserve Account validates the deposited assets, verifying authenticity and asset balance sufficiency. 3. **wFRAG Token Minting** Upon successful validation, the Reserve Account triggers minting of an equivalent amount of wrapped FRAG tokens (wFRAG). 4. **Distribution of wFRAG** Minted wFRAG tokens are directly issued to the user's wallet. 5. **External Deployment** Users utilize wrapped FRAG tokens into external DeFi protocol vaults, enabling yield generation and liquidity provision and more. ### Technical Components | Component | Role | Description | | ------------------------------ | -------------------------------------- | ------------------------------------------------------ | | **Reserve Account** | Asset Custody & Validation | Receives FRAG tokens, validates deposits. | | **Wrapped Token Mint (wFRAG)** | Token Generation | Mints wFRAG tokens proportional to the FRAG deposited. | | **User's Wallet** | wFRAG Holding | Holds wrapped tokens ready for external deployment. | | **External DeFi Protocol** | Yield Generation & Liquidity Provision | Accepts wFRAG tokens, providing yield and liquidity. | ### Wrap Operation Benefits * **Cross-Protocol Utilization:** Empowers users to leverage FRAG tokens in various DeFi environments. * **Yield Generation:** Facilitates earning additional yield via external DeFi protocols. * **Secure Tracking:** Ensures continuous and secure tracking of asset contributions and reward accumulation. # Yield Source Adapters Source: https://docs.fragmetric.xyz/protocol/module/yield-source/adapter Yield Source Adapters function as standardized interfaces within the FRAG-22 protocol, enabling secure interaction between the internal asset management system and external yield-generating protocols. Each adapter implements clearly defined operations such as asset allocation, yield harvesting, and asset withdrawal, ensuring transparent, consistent, and secure management of deployed assets. ### **Core Functions of Yield Source Adapters** Each Yield Source Adapter must implement the following standardized functions according to the FRAG-22 protocol specifications: * **Asset Allocation** * **Function:** `allocate(amount: u64)` Moves specified assets from the FRAG-22 Reserve Account to the external yield source. * **Yield Harvesting** * **Function:** `harvest() → yield_amount: u64` Retrieves generated yields from external yield sources and deposits them into the FRAG-22 Reward Reserve Account. * **Asset Withdrawal** * **Function:** `withdraw(amount: u64)` Withdraws assets from the external yield sources back to the FRAG-22 Reserve Account. * **Status Reporting** * **Function:** `report_status() → {allocated_assets: u64, accumulated_yield: u64}` Reports the current state of allocated assets and total accumulated yield, ensuring internal transparency and accurate record-keeping. ### **Adapter Structure and Operation Flow** ```mermaid theme={null} flowchart TD ReserveAccount[FRAG-22 Reserve Account] Adapter[Yield Source Adapter] ExternalYieldSource[External Yield Source] RewardReserve[FRAG-22 Reward Reserve Account] ReserveAccount -->|Allocate Assets| Adapter Adapter -->|Deploy Assets| ExternalYieldSource ExternalYieldSource -->|Generate Yield| ExternalYieldSource ExternalYieldSource -->|Harvest Yield| Adapter Adapter -->|Deposit Yield| RewardReserve ExternalYieldSource -->|Withdraw Assets| Adapter Adapter -->|Return Assets| ReserveAccount ``` ### **Existing Implementations (by Fragmetric)** Fragmetric currently maintains two fully operational Yield Source Adapters integrated within FRAG-22: * **Liquid Staking Adapter** * **Restaking Adapter** These existing adapters demonstrate robust and secure integrations that follow the standardized Yield Source Adapter interface. ### **Custom Yield Source Adapter Development** The modular architecture of FRAG-22 allows external developers to create and propose new adapters that conform to the predefined adapter interface. Operators will review and validate each adapter's implementation before approving any asset allocation. ### **Adapter Activation and Asset Allocation Management** Operators hold exclusive permissions to manage the activation status and asset allocation parameters for each Yield Source Adapter. This ensures controlled asset exposure, risk management, and compliance with the FRAG-22 asset management strategy. **Allocation Management Flow:** ```mermaid theme={null} flowchart TD Operator[Operator] Adapter[Yield Source Adapter] ExternalYieldSource[External Yield Source] Operator -->|Set Allocation Limits| Adapter Adapter -->|Execute Allocation| ExternalYieldSource ``` The FRAG-22 Yield Source Adapter framework provides a standardized, transparent, and secure approach to extending and integrating various external yield-generation strategies, empowering a scalable and adaptable asset management ecosystem. # Overview Source: https://docs.fragmetric.xyz/protocol/module/yield-source/overview ## **FRAG-22: Yield Source Module** ### **Overview** The Yield Source Module manages the strategic deployment and optimization of assets within the FRAG-22 system, actively allocating user-deposited funds across various external decentralized yield strategies. This module seamlessly connects internal asset management with external yield-generating protocols, maximizing user returns while maintaining efficient liquidity. The module distinctly organizes responsibilities across three internal layers and clearly interacts with external yield opportunities: * **Asset Management :** Safely maintains and manages the pool of assets (Reserve Account), readying them for strategic deployment to external yield sources. * **Operator Management :** Handles critical operations including asset allocation, periodic rebalancing for optimal yields, and yield harvesting—ensuring asset positions remain optimized and responsive to market conditions. * **Accounting :** Precisely tracks and accumulates the generated yields within the Fund Reward Account, ensuring transparent and accurate reward accounting. External yield opportunities, such as staking, restaking, liquidity pools, lending protocols, and structured financial products, provide diverse and attractive yield streams. The Yield Source Module strategically integrates these external systems, continuously monitoring and adjusting positions to deliver consistent and optimized returns for users. ### **Comprehensive Structure Diagram** ```mermaid theme={null} graph TD %% External Yield Sources subgraph External_Yield_Sources LiquidStaking[Liquid Staking] Restaking[Restaking] CustomYieldSource[Custom Yield Source] end %% Adapters Layer subgraph Adapters_Layer LiquidStakingAdapter[Liquid Staking Adapter] RestakingAdapter[Restaking Adapter] CustomAdapter[Custom Yield Adapter] end %% Logic Layer subgraph Logic_Layer YieldHarvester[Yield Harvester] AssetAllocator[Asset Allocator] end %% Internal Accounts Layer subgraph Internal_Accounts ReserveAccount[Reserve Account] FundRewardAccount[Fund Reward Account] end %% External Sources to Adapters LiquidStaking --> LiquidStakingAdapter Restaking --> RestakingAdapter CustomYieldSource --> CustomAdapter %% Adapters to Logic Layer LiquidStakingAdapter --> YieldHarvester RestakingAdapter --> YieldHarvester CustomAdapter --> YieldHarvester AssetAllocator --> LiquidStakingAdapter AssetAllocator --> RestakingAdapter AssetAllocator --> CustomAdapter %% Logic Layer to Internal Accounts YieldHarvester --> FundRewardAccount AssetAllocator --> ReserveAccount %% Internal Accounts Interaction FundRewardAccount --> ReserveAccount classDef external fill:#ADD8E6, stroke:#333,stroke-width:1px classDef adapter fill:#FFD580, stroke:#333,stroke-width:1px classDef logic fill:#87CEFA, stroke:#333,stroke-width:1px classDef internal fill:#90EE90, stroke:#333,stroke-width:1px class LiquidStaking,Restaking,CustomYieldSource external class LiquidStakingAdapter,RestakingAdapter,CustomAdapter adapter class YieldHarvester,AssetAllocator logic class ReserveAccount,FundRewardAccount internal ``` # Overview Source: https://docs.fragmetric.xyz/protocol/overview ## FRAG-22 ### Fragmetric Asset Standard The **FRAG-22 standard** represents an advanced asset tokenization framework developed by Fragmetric, built upon Solana’s innovative Token 2022 - **transfer hook**. Initially utilized for liquid restaking, the standard now provides robust capabilities to support multiple asset deposits, diverse reward distributions, and seamless adoption of various yield-generating strategies beyond traditional staking solutions. ### **Expansion Beyond Restaking** Fragmetric initially introduced the **FRAG-22** standard to support its Liquid Restaking Tokens, allowing multiple LSTs to be deposited, automatically generating and accurately distributing multiple reward streams created by NCNs. With this robust and modular infrastructure, restaking served as the first use case demonstrating the standard’s potential. Recognizing broader opportunities, Fragmetric expanded the standard’s applicability beyond restaking, integrating diverse yield generation methods into a unified, composable token architecture. This expansion enables FRAG-22 assets to seamlessly integrate with liquidity pools, lending protocols, structured DeFi products, and more complex yield-generation strategies. ## Technical Innovation of FRAG-22