Tokenomics Deep Dive

Complete breakdown of $IFR fee mechanics, deflation model, token allocation, fair launch design, and fee-exempt addresses.

1. Fee-on-Transfer Mechanics

Every standard ERC-20 transfer of $IFR triggers an automatic fee mechanism built directly into the token's _update function. This is not an external router or wrapper — the fee logic lives inside the token contract itself, making it impossible to bypass on any DEX or wallet transfer.

Fees are only applied on normal transfers between non-exempt addresses. Minting (from address(0)) and burning (to address(0)) are excluded. If either the sender or the recipient is marked as feeExempt, the entire fee is waived.

Fee Breakdown

Calculation Example

Contract Logic

The fee mechanism is implemented by overriding OpenZeppelin's _update internal function. All fee calculations use basis points (1 bps = 0.01%) for precision with integer arithmetic.

function _update(address from, address to, uint256 value) internal override {
    // Only apply fees on normal transfers (not mint/burn)
    // and when neither party is exempt
    if (from != address(0) && to != address(0)
        && !feeExempt[from] && !feeExempt[to])
    {
        uint256 burnSender    = (value * senderBurnBps)    / 10_000;
        uint256 burnRecipient = (value * recipientBurnBps) / 10_000;
        uint256 poolFee       = (value * poolFeeBps)       / 10_000;
        uint256 totalBurn     = burnSender + burnRecipient;
        uint256 netAmount     = value - totalBurn - poolFee;

        // Net amount to recipient
        super._update(from, to, netAmount);
        // Pool fee to receiver
        super._update(from, poolFeeReceiver, poolFee);
        // Burn — tokens go to address(0), totalSupply decreases
        super._update(from, address(0), totalBurn);
    } else {
        super._update(from, to, value);
    }
}

2. Deflation Model

Inferno is a purely deflationary token. There is no minting function beyond the initial supply creation in the constructor. Every taxed transfer permanently removes tokens from circulation by sending them to address(0), which decreases totalSupply.

Key Properties

• Initial supply: 1,000,000,000 IFR (1 billion)
• Burn rate per transfer: 2.5% of the transferred amount (2.0% sender burn + 0.5% recipient burn)
• No minting function exists — supply can only decrease, never increase
• Pool fee (1.0%) goes to poolFeeReceiver and does not reduce supply
• Burn rate is volume-dependent, not time-dependent — more trading = faster deflation

Projected Supply Scenarios

The following table illustrates how supply decreases based on cumulative transfer volume. These are simplified examples assuming uniform transfer sizes and no fee-exempt transfers.

Fee Governance

The owner (Governance contract with 48-hour timelock) can adjust the three fee rates via setFeeRates(). The hard cap of 500 bps (5%) is enforced on-chain — the sum of all three rates can never exceed this limit, even through governance action.

function setFeeRates(
    uint256 _senderBurnBps,
    uint256 _recipientBurnBps,
    uint256 _poolFeeBps
) external onlyOwner {
    require(_senderBurnBps + _recipientBurnBps + _poolFeeBps <= 500, "fees>5%");
    senderBurnBps    = _senderBurnBps;
    recipientBurnBps = _recipientBurnBps;
    poolFeeBps       = _poolFeeBps;
}

3. Token Allocation

The total initial supply of 1,000,000,000 IFR is distributed across six categories at deployment. All allocations are executed in the deploy script — there is no ongoing emission or inflation mechanism.

Allocation Visualization

Unlock Schedule Details

DEX Liquidity (40% — 400M IFR)

• Paired on Uniswap V2 after Bootstrap completion
• LP tokens locked via Team.Finance for 12 months (rug pull protection)
• Provides initial trading liquidity for the market

Liquidity Reserve (20% — 200M IFR)

• Smart-contract-locked until 01.09.2026. Purpose: Phase 2 LP expansion after lock expiry. NOT used for Bootstrap (Plan B decision, 08.03.2026).
• After the lock period: 50M IFR released per quarter (4 quarters to fully unlock)
• Purpose: supplemental liquidity, market-making, or strategic partnerships

Team Vesting (15% — 150M IFR)

• Locked in the Vesting contract with a 12-month cliff
• After the cliff: linear vesting over 36 months
• Total vesting period: 48 months (4 years)
• Prevents team dumps and aligns long-term incentives

Treasury (15% — 150M IFR)

• Held in Gnosis Safe multisig (0x5ad6193eD6E1e31ed10977E73e3B609AcBfEcE3b)
• 150M IFR committed to Bootstrap (transferred to BootstrapVaultV3)
• Remaining balance used for development, operations, and strategic initiatives
• All disbursements require multisig approval

Community & Grants (6% — 60M IFR)

• Sent to Community Safe: 57.9M received after 1.5M burn (2.5%) + 0.6M pool fee (1%) = 2.1M total deducted (EOA not feeExempt)
• 50M allocated to Bootstrap funding via BootstrapVaultV3
• ~7.9M retained as operational reserve (after burn)

Builder Ecosystem (4% — 40M IFR)

• Dedicated pool managed by the PartnerVault contract (Mainnet: 0xc6eb7714bCb035ebc2D4d9ba7B3762ef7B9d4F7D)
• Primary distribution via lock-triggered Creator Rewards: when a user locks IFR for a creator's product, the creator earns a percentage (RewardBps) from the pool, vested over 6–12 months
• Hard cap per builder and annual emission cap to prevent pool exhaustion
• All allocations vest linearly — no instant dumps
• Builder tokens grant DAO voting rights in Phase 4+

Note: BuybackVault and BurnReserve are not genesis allocations. They accumulate from the 1% protocol pool fee on every non-exempt IFR transfer. Bootstrap is funded via Plan B from Treasury + Community Safe — not a standalone genesis bucket.

Bootstrap Event (Plan B — not a genesis allocation)

• Funded via Plan B (decision 08.03.2026): Treasury Safe (150M) + Community Safe (50M) = ~200M IFR in BootstrapVaultV3
• 90-day Bootstrap period — ETH raised + IFR from vault create Uniswap V2 LP via finalise()
• BootstrapVaultV3 contract: 0xf72565C4cDB9575c9D3aEE6B9AE3fDBd7F56e141

LP Allocation — Phased Release

Iron rule: ETH always stays in the LP — never withdrawn by the team.

BuybackVault (protocol contract — not a genesis allocation)

• Accumulates from the 1% protocol pool fee on every non-exempt IFR transfer
• Not pre-funded at genesis. Current balance: 0 IFR.
• BuybackController.sol — Deployed 14.04.2026 (0x1e05...F7c):
  • 50/50 split: buyback+burn / LP deepening
  • Permissionless execute() with 24h cooldown
  • Slippage protection (minIFR/minETH parameters)
  • Governance wiring: Proposal #13 (feeExempt) executed 16.04.2026, Proposal #14 (setFeeCollector) executed 18.04.2026 — fully active ✅

BurnReserve (protocol contract — not a genesis allocation)

• Accumulates from the 1% protocol pool fee on every non-exempt IFR transfer
• Not pre-funded at genesis. Current balance: 0 IFR.
• Structured token burning to accelerate deflation
• Burns are executed via governance — transparent and verifiable on-chain

4. Fair Launch Model (CFLM)

Inferno uses a Community Fair Launch Model (CFLM), which guarantees that no individual or group receives preferential access to tokens before public trading begins.

Core Principles

How It Works

1. The deploy script mints the entire 1B IFR supply to the deployer
2. The deployer distributes tokens to all allocation contracts (Vesting, LiquidityReserve, Treasury, Community wallet)
3. 40% is paired with ETH on Uniswap V2, creating the initial liquidity pool
4. The deployer's feeExempt status is removed so the deployer is subject to the same fees as everyone else
5. Ownership of InfernoToken (and all admin functions) is transferred to the Governance contract with its 48-hour timelock
6. From this point, no single entity has privileged access to the token

5. Fee Exempt Addresses

Certain protocol contracts are marked as feeExempt to ensure that internal protocol operations (vesting releases, reserve unlocks, buyback executions, burns) are not taxed. Without these exemptions, protocol mechanisms would lose tokens to fees on every internal transfer, breaking the intended allocation math.

Exempt Contracts

Exemption Rules

• If either the sender or recipient is feeExempt, the entire transfer is fee-free
• Exemptions are set via setFeeExempt(address, bool) by the owner (Governance contract)
• The deployer's exemption is explicitly removed after the initial distribution to prevent any privileged fee-free trading
• Adding or removing exemptions requires a governance proposal with 48-hour timelock

// Setting fee exemption (onlyOwner = Governance contract)
function setFeeExempt(address account, bool exempt) external onlyOwner {
    feeExempt[account] = exempt;
    emit FeeExemptUpdated(account, exempt);
}

// Fee check in _update:
// Both sender AND recipient must be non-exempt for fees to apply
if (from != address(0) && to != address(0)
    && !feeExempt[from] && !feeExempt[to])
{
    // ... apply fees
}

6. PartnerVault & Creator Rewards

The Builder Ecosystem Pool (4%, 40M IFR) is distributed through the PartnerVault contract (deployed on Ethereum Mainnet). Instead of fixed tier-based grants, builder rewards are driven by actual user engagement via lock-triggered Creator Rewards.

Lock-triggered Creator Rewards

When a user locks IFR for premium access to a creator's product, the creator earns a reward from the Builder Pool:

This model is inherently deflationary: the reward is always smaller than the locked amount, so every lock-triggered reward results in a net reduction of circulating supply.

PartnerVault Design

7. Bootstrap Pricing (Phase 0)

In the initial bootstrap phase, all pricing is token-denominated. There is no USD pricing, no oracle, and no TWAP — this is a deliberate design decision for a zero-capital launch.

How It Works

Why Token-Denominated?

• Zero capital required — no initial liquidity needed for price feeds
• Manipulation-resistant — no oracle to exploit, no flash loan attacks on pricing
• Fully on-chain — the lock amount is a simple uint256, verifiable by any contract
• Automatic adjustment — as IFR price increases, the USD-equivalent cost rises naturally, reducing token emission pressure

7. Protocol Fee & FeeRouter

The FeeRouterV1 contract handles protocol-level fees on IFR swaps. These are separate from the token's built-in transfer fees (2.5% burn + 1% pool fee).

Fee Structure

Discount Vouchers (IFR Points)

Users earn points through verified actions in the IFR ecosystem. Points can be redeemed for a signed EIP-712 discount voucher, applied against the protocol fee at swap time.

Contract Address (Mainnet)

0x4807B77B2E25cD055DA42B09BA4d0aF9e580C60a — Etherscan