Inflationary Token Issuance

While a one-time deposit and yield-bearing endowment can significantly extend the lifetime of a website’s hosting, inflationary token issuance adds an ongoing, protocol-level funding stream. In many protocols, inflation is set to occur continuously (block-by-block) or at regular intervals (epoch-based or annual). However, we only mint new tokens when the Storage Pool runs low. This approach aims to:

• Perpetual Sustainability: Preventing the endowment from depleting too quickly, especially if user demand grows or storage costs fluctuate.

• Decentralized Cost Sharing: Spreading the burden of data longevity across all token holders or protocol participants, rather than only on the initial publisher.

• Minimize Unnecessary Dilution: Avoid inflating the supply if the Storage Pool is already healthy.

• Adapt to Real Demand: Scale the token supply based on actual usage and depletion of the Storage Pool instead of arbitrary schedules.

1. Longevity of Hosted Data

   • A purely endowment-based model can be depleted if the stored content is large or if the Defi yield falls unexpectedly.

   • Inflationary rewards supplement the endowment to ensure content remains funded indefinitely.

2. On-Demand Funding

   • If the Core Storage Pool still has ample funds, there’s no need to introduce new tokens.

   • Only when the balance dips below a critical threshold do we mint more, preventing the pool from hitting zero and halting node rewards.

3. Fair Cost Distribution

   • By inflating the token supply, the “cost” of permanent hosting is distributed across the token-holding community.

   • All participants share in sustaining the decentralized network’s data availability.

4. Stronger Signal of Demand

   • A “low balance” in the Storage Pool indicates high usage or underfunding. The newly minted tokens directly solve that shortfall without overshooting.

System Architecture

High-level view of how inflationary token issuance interacts with the rest of the WebHash ecosystem:

1. Inflation Engine/Module: A protocol-level component (smart contract or on-chain logic) that mints new tokens on a specified schedule or block interval.

2. Distribution Smart Contract: Holds the logic to decide if and how much to mint based on the pool’s balance. Also defines how newly minted tokens flow to the Core Storage Pool and/or the Endowment Investment contract. It will also handle any immediate disbursements or splitting logic (e.g., 60% to the Core Pool, 40% to the Endowment).

3. Threshold Monitoring: A governance-defined balance threshold for the Storage Pool. If the pool’s balance dips below this threshold, the system triggers a mint.

4. Core Storage Pool Contract: Receives a portion of the minted tokens to bolster near-term rewards for node operators (e.g., Proof-of-Storage payments).

5. Endowment Investment Contract: Optionally receives another portion of the inflationary tokens for longer-term growth (via yield strategies).

Dynamic Threshold and Minting

The threshold will be a fraction of the average monthly reward distribution or a fraction of the token supply. For example:

• Threshold = 2× (average monthly payouts).

• If monthly payouts average 500,000 tokens, the threshold is 1,000,000.

This approach scales with usage or changing token prices/costs over time.

When the Storage Pool dips below the threshold, DAO will decide how many tokens to mint:

1. Exact Top-Up

   • Mint Threshold−PoolBalance\text{Threshold} - \text{PoolBalance}Threshold−PoolBalance.

   • Restores the pool exactly to the threshold. Simple but might require frequent small mints.

2. Overfill Strategy

   • Mint more than the difference, e.g., 2× the difference or up to an “upper limit,” to reduce the number of times we trigger inflation.

   • Example: If threshold is 1,000,000 and the pool is at 750,000, we might mint 500,000 to go to 1,250,000, providing more cushion.

Integration with the Storage Pool

Receipt of Minted Tokens

Within the Core Pool (or Distribution) contract, a function like onInflationReceived(uint256 amount) handles each mint event:

function onInflationReceived(uint256 amount) external {
    // Only the authorized inflation module can call this
    require(msg.sender == inflationModule, "Unauthorized");
    
    globalPoolBalance += amount;

    emit InflationReceived(amount);
    
    // Optionally trigger an event or immediate partial distribution
    // e.g. distributeRewardsIfNeeded();
}

Key Points:

• The minted tokens become part of the globalPoolBalance used to pay node rewards.

• If using a split distribution, the function might also route some portion to the Endowment contract.

Boosting Node Rewards

The presence of inflation means that even if user deposits slow down, the pool continues receiving new tokens. This ensures:

• Consistent Payouts: Node operators remain incentivized to store older or less popular content.

• Reduced Risk of Depletion: The pool can stay solvent longer, especially if yields or user fees alone are insufficient.

Coordinating with Endowment Investment

When part of the inflation goes to the Endowment Investment Contract:

• Harvest: Over time, the endowment invests these tokens in yield strategies (e.g., lending, staking).

• Growth: The contract harvests the returns and can periodically transfer them back to the Core Pool.

• Governance decides how much inflation is allocated between immediate vs. long-term capital.

Governance and Adjustments

DAO Decision-Making

A DAO typically governs critical parameters of inflationary issuance:

• Inflation Rate: The community might vote to raise/lower it in response to network health.

• Split Ratio: Determining how minted tokens are divided between the Core Pool and Endowment.

• Emission Schedule Updates: Switching from a fixed rate to a dynamic schedule if the ecosystem evolves.