Platform Revenue Model
HYFY earns platform revenue when users purchase Space Credits through supported payment channels. Space Credits are off-chain spending units used for eligible features and services inside HYFY. Only verified, settled payment activity is included in tokenomics.
1. How HYFY Earns Revenue
HYFY generates platform revenue when users purchase Space Credits. Those credits are then used for eligible features, services, and digital interactions inside HYFY.
- Supported Payment Channels: Available payment methods may vary by platform, region, and launch stage. Only enabled and verified payment providers are included in revenue accounting.
- Utility-First Design: Space Credits are off-chain platform spending units. They are not HYFY, do not represent equity or ownership in HYFY, and purchasing them does not create an automatic entitlement to HYFY tokens.
2. Net Revenue: The Starting Point
Before any revenue is allocated, gross transaction receipts must be reconciled against the direct external costs required to process payments and comply with platform partner requirements.
Tokenomics and platform budgets operate exclusively on verified net revenue:
Net Revenue = Gross Receipts - Payment/Store Fees - Applicable Taxes - Refunds & Chargebacks - Other Verified Deductions
Gross checkout totals, pending transactions, incomplete payments, duplicate webhooks, and unreconciled receipts are strictly excluded. Only settled, verifiable funds are recognized in the monthly accounting cycle.
3. Where Every $100 of Net Revenue Goes
For every $100 of verified net platform revenue, verified net revenue is budgeted under HYFY's current governed allocation policy:
| Destination | Share of Net Revenue | Effective Dollar Amount | Operational Purpose |
|---|---|---|---|
| Platform Development, Growth & Operations | 75.0% | $75.00 | Payment-processing/platform-distribution fees, infrastructure hosting, identity verification, product engineering, customer support, and compliance |
| Community Claims Support | 12.5% | $12.50 | Establishes the revenue-backed reference allocation used to calculate the monthly community claims pool |
| Treasury Resilience Support | 7.5% | $7.50 | Establishes the reference allocation for treasury resilience and long-term protocol runway |
| Liquidity Provision Support | 2.5% | $2.50 | Establishes the reference budget for liquidity provisioning. Under current accounting, approximately half is stablecoin funding and half is HYFY value |
| Token Burn Support | 2.5% | $2.50 | Establishes the reference budget for conditional HYFY burns, subject to applicable treasury, oracle, and execution safeguards |
| Total | 100.0% | $100.00 | Fully reconciled monthly budget allocation |
Accounting note: These dollar figures represent the economic allocation reference under the current configuration, not necessarily four immediate cash outflows or separately escrowed dollar balances. Token-support amounts are translated into HYFY reference amounts using the approved monthly price and remain subject to the applicable treasury, market, claim, oracle, and execution safeguards. For liquidity, the reference budget represents a balanced pair value: approximately half is stablecoin funding and half is HYFY value, subject to execution and rounding rules.
4. Why 75% Supports Platform Development, Growth & Operations
A sustainable token ecosystem requires a thriving, high-performance product. Unlike pure decentralized protocols that operate solely as smart contracts, HYFY is a consumer-scale media platform with real-world infrastructure and regulatory obligations.
The 75% operational allocation funds:
- Global Cloud & Video Infrastructure: High-bandwidth video streaming, edge caching, media transcode pipelines, and low-latency databases.
- Payment & Distribution Costs: Payment-processing, app-store, and other applicable platform-distribution fees.
- Identity Verification & Security: Per-user KYC vendor verification, anti-fraud screening, and bot mitigation services to ensure authentic human participation.
- Continuous Engineering: Core protocol and application development, iOS and Android client updates, UI/UX design, and security audits.
- Legal, Compliance & Operations: Global regulatory compliance, customer support operations, and administrative overhead.
Without robust platform revenue supporting these real-world expenses, the user experience degrades, scaling stalls, and user retention declines.
5. What the 25% Token-Support Pool Does
The remaining 25% of verified net revenue is allocated to support the HYFY token economy. Rather than treating token support as a single generic fund, it establishes the reference budget across four distinct functions:
1. Community Claims Support (50% of pool / 12.5% of net revenue)
Establishes the revenue-backed reference allocation used in calculating the safe monthly community claim pool. Actual claims remain subject to eligibility, participation, reserve, market, and lifetime limits.
2. Treasury Resilience (30% of pool / 7.5% of net revenue)
Establishes the treasury-support reference allocation used to strengthen long-term protocol resilience and runway.
3. Liquidity Provision (10% of pool / 2.5% of net revenue)
Establishes the liquidity-support reference budget. Actual liquidity deployment requires the applicable market, treasury, stablecoin, and execution conditions to pass.
4. Permanent Token Burns (10% of pool / 2.5% of net revenue)
Establishes the burn-support reference budget. Burns are conditional and occur only when the applicable price, treasury, and safety checks pass.
6. Why Revenue Does Not Guarantee Token Rewards
HYFY connects revenue to token support responsibly and transparently:
- No Direct Token Entitlement: Purchasing Space Credits does not directly purchase HYFY or guarantee a future HYFY claim. Community claims depend on eligible claimable Karma and the monthly claim process, including applicable verification, participation, reserve, market, and safety limits.
- Prudent Execution: Token-support allocations are subject to oracle verification, market volatility checks, and protocol safety limits. If market conditions are unsafe or data feeds are interrupted, distributions may be paused or carried forward to safeguard protocol stability.
7. Governance Flexibility & Allowed Ranges
HYFY utilizes governed ranges to adapt to changing market conditions while preventing arbitrary or destabilizing budget shifts. Governance can adjust the allocation percentages, but only within strict on-chain boundaries:
| Allocation Level | Parameter | Base Default | Allowed Governance Range | Purpose of Boundary |
|---|---|---|---|---|
| Top-Level Net Revenue | Platform Operations | 75% | 60% – 85% | Keeps the operations share within the approved range |
| Top-Level Net Revenue | Token-Support Pool | 25% | 15% – 40% | Keeps token-economy support within the approved range |
| Within Token-Support Pool | Community Claims | 50% | 40% – 60% | Keeps claims as the largest default component of token support |
| Within Token-Support Pool | Treasury Resilience | 30% | 20% – 38% | Bounds the treasury-resilience share |
| Within Token-Support Pool | Liquidity Provision | 10% | 5% – 20% | Bounds liquidity support |
| Within Token-Support Pool | Token Burns | 10% | 5% – 15% | Bounds burn support |
Every adjustment must maintain an exact 100% total at each level. Governance proposals that attempt to set values outside these mathematical ranges are automatically rejected.
8. Technical Accounting & Governance (For Auditors & Developers)
This section details the smart contract constants, runtime data structures, and monthly reconciliation mechanisms for auditors and technical integrators.
Smart Contract Governance Bounds
The governance contract (HYFYGovernance.sol) enforces parameter bounds via setAllocations() using basis points (where 10,000 basis points equal 100%):
- Platform Operations:
MIN_OPERATIONS_BPS(6,000 / 60%) toMAX_OPERATIONS_BPS(8,500 / 85%). - Token Support Pool:
MIN_BUYBACK_BPS(1,500 / 15%) toMAX_BUYBACK_BPS(4,000 / 40%). - Community Claims:
MIN_CLAIMS_BPS(4,000 / 40%) toMAX_CLAIMS_BPS(6,000 / 60%). - Treasury Resilience:
MIN_TREASURY_BPS(2,000 / 20%) toMAX_TREASURY_BPS(3,800 / 38%). - Liquidity Provision:
MIN_LP_BPS(500 / 5%) toMAX_LP_BPS(2,000 / 20%). - Token Burns:
MIN_BURN_BPS(500 / 5%) toMAX_BURN_BPS(1,500 / 15%).
Validation checks require:
operationsBps + buybackBps == 10000
claimsBps + treasuryBps + lpBps + burnBps == 10000
Runtime Configuration Snapshots
The backend uses an active configuration snapshot synchronized from the authoritative governance parameters so monthly calculations can be reproduced against the configuration in effect for that close. The snapshot records the relevant governance/configuration provenance used by the monthly process.
Worked $10,000 Monthly Example
Consider a monthly close with $10,000 in verified net revenue:
| Destination | Share of Parent Budget | Effective Share | Budgeted Dollar Amount |
|---|---|---|---|
| Platform Development, Growth & Operations | 75% of net revenue | 75.0% | $7,500 |
| Community Claims Support | 50% of token support | 12.5% | $1,250 |
| Treasury Resilience Support | 30% of token support | 7.5% | $750 |
| Liquidity Provision Support | 10% of token support | 2.5% | $250 |
| Token Burn Support | 10% of token support | 2.5% | $250 |
| Total Accounted For | — | 100.0% | $10,000 |
Illustrative HYFY Conversion
If the resolved HYFY price used for this illustrative monthly calculation were $0.05 per HYFY:
- Community Claims ($1,250): Represents a base reference of 25,000 HYFY for the monthly claims calculation before the applicable claim, reserve, participation, and market safeguards are applied.
- Token Burns ($250): Represents a burn-support reference of up to 5,000 HYFY at the illustrative price. An actual burn occurs only if the applicable treasury, oracle, and execution safeguards pass.
- Liquidity ($250): Under balanced 50/50 liquidity accounting, the reference budget corresponds to approximately $125 of stablecoin funding and $125 of HYFY value (2,500 HYFY at the illustrative price). If the liquidity action passes the applicable safeguards and executes, those assets can be deployed into the protocol's liquidity position.
Quiet, Failed, and Corrected Periods
- Low Participation (Quiet Months): If participation is unusually low, the system can carry forward part of the available claim capacity rather than allowing a very small participant set to receive a disproportionate distribution.
- Oracle Halts: If required price inputs are unavailable, invalid, or fail configured safety checks, price-dependent allocations, burns, and liquidity actions pause until a valid price can be resolved under the oracle rules.
- Late Adjustments: Valid provider corrections, refunds, or chargebacks received after a period closes are handled through the approved auditable correction process rather than silently rewriting finalized historical records.