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
| Fee Type | Rate | Basis Points | Destination |
|---|---|---|---|
| Sender Burn | 2.0% | 200 bps |
address(0) — permanently burned |
| Recipient Burn | 0.5% | 50 bps |
address(0) — permanently burned |
| Pool Fee | 1.0% | 100 bps |
poolFeeReceiver — protocol wallet |
| Total | 3.5% | 350 bps |
— |
| Max Cap (governance limit) | 5.0% | 500 bps |
Sum of all three cannot exceed this |
Calculation Example
Sending 10,000 IFR
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);
}
}
Important: If either the sender or the recipient is feeExempt, the entire transfer proceeds without any fees. Both parties must be non-exempt for fees to apply.
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
poolFeeReceiverand 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.
| Scenario | Transfer Volume | Approx. Burned | Remaining Supply | % Deflation |
|---|---|---|---|---|
| 1,000 transfers of 10,000 IFR | 10,000,000 IFR | 250,000 IFR | 999,750,000 IFR | 0.025% |
| 10,000 transfers of 10,000 IFR | 100,000,000 IFR | 2,500,000 IFR | 997,500,000 IFR | 0.25% |
| 100,000 transfers of 10,000 IFR | 1,000,000,000 IFR | 25,000,000 IFR | 975,000,000 IFR | 2.5% |
| 1M transfers of 10,000 IFR | 10,000,000,000 IFR | 250,000,000 IFR | 750,000,000 IFR | 25% |
Key Insight: The deflation rate is entirely driven by transfer volume, not by the passage of time. High trading activity on DEXes accelerates token burns. During low-activity periods, the supply remains stable. This creates a natural correlation between usage and scarcity.
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.
| Category | Percentage | Amount (IFR) | Unlock Schedule |
|---|---|---|---|
| DEX Liquidity | 40% | 400,000,000 | Immediately paired on Uniswap V2 |
| Liquidity Reserve | 20% | 200,000,000 | 6-month lock, then 50M per quarter |
| Team Vesting | 15% | 150,000,000 | 12-month cliff, then linear over 36 months |
| Treasury | 15% | 150,000,000 | Available to multisig (Gnosis Safe) |
| Community & Grants | 6% | 60,000,000 | Community grants, bug bounties, ecosystem development |
| Partner Ecosystem | 4% | 40,000,000 | Milestone-based partner allocations (vested 6–12 months) |
Allocation Visualization
Unlock Schedule Details
DEX Liquidity (40% — 400M IFR)
- Immediately paired with ETH on Uniswap V2 at deployment
- LP tokens held by the deployer (to be locked or burned)
- Provides initial trading liquidity for the market
Liquidity Reserve (20% — 200M IFR)
- Locked in the LiquidityReserve contract for 6 months minimum
- 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)
- Controlled by a Gnosis Safe multisig wallet
- Available for ecosystem development, audits, marketing, and partnerships
- All spends require multisig approval
Community & Grants (6% — 60M IFR)
- Available to the community wallet
- Used for airdrops, rewards, community incentives, bug bounties, and grants
Partner Ecosystem (4% — 40M IFR)
- Dedicated pool managed by the PartnerVault contract (deployed on Sepolia:
0x5F12C0bC616e9Ca347D48C33266aA8fe98490A39) - 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 partner and annual emission cap to prevent pool exhaustion
- All allocations vest linearly — no instant dumps
- Partner tokens grant DAO voting rights in Phase 4+
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
| Principle | Implementation |
|---|---|
| No presale | Zero tokens sold before Uniswap listing |
| No private rounds | No seed, private, or strategic investor allocations |
| No VC allocations | No venture capital or institutional pre-purchase agreements |
| Transparent distribution | All token transfers executed via the public deploy script on-chain |
| Deployer exemption removed | Deployer's feeExempt status is explicitly revoked after distribution |
| Team tokens vested | 15% allocation locked for 48 months (12-month cliff + 36-month linear) |
| Liquidity locked | Reserve tokens locked for a minimum of 6 months |
How It Works
- The deploy script mints the entire 1B IFR supply to the deployer
- The deployer distributes tokens to all allocation contracts (Vesting, LiquidityReserve, Treasury, Community wallet)
- 40% is paired with ETH on Uniswap V2, creating the initial liquidity pool
- The deployer's
feeExemptstatus is removed so the deployer is subject to the same fees as everyone else - Ownership of InfernoToken (and all admin functions) is transferred to the Governance contract with its 48-hour timelock
- From this point, no single entity has privileged access to the token
Verification: Every step of the CFLM deployment is fully verifiable on-chain. All contract source code is verified on Etherscan, and the deploy script is open source in the project repository.
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
}
Security Note: The fee exemption mapping is controlled exclusively by the Governance contract (owner). No single EOA can grant or revoke exemptions. Any change requires a proposal, a 48-hour waiting period, and execution — giving the community time to review and react.
6. PartnerVault & Creator Rewards
The Partner Ecosystem Pool (4%, 40M IFR) is distributed through the PartnerVault contract (live on Sepolia; mainnet TBD). Instead of fixed tier-based grants, partner 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 Partner Pool:
Reward Example (15% RewardBps)
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
| Property | Value |
|---|---|
| Pool Size | 40,000,000 IFR (4% of supply) |
| Distribution Trigger | User lock events via IFRLock |
| Reward Rate (RewardBps) | Hard bounds (contract-enforced): 5–25% (MIN_REWARD_BPS=500, MAX_REWARD_BPS=2500). Policy target (governance recommendation): 10–20%. Changeable via governance proposal (48h timelock). |
| Vesting Period | 6–12 months linear |
| Per-Partner Cap | Hard cap (configurable via governance) |
| Annual Emission Cap | Default: 4,000,000 IFR/year (10% of pool). Hard bounds (contract-enforced): 1,000,000–10,000,000 IFR. Resets annually; governance can adjust within bounds. |
| Claim Mechanism | Permissionless claim() by partner beneficiary |
| Fee Exempt | Required (internal protocol transfers) |
Key difference from old model: Previous documentation listed fixed tier grants (5M / 2M / 1M / 500K IFR per partner). These numbers were replaced with the lock-triggered reward model because fixed grants become disproportionate at scale — at $0.50/IFR, a 5M grant would be $2.5M, which is unsustainable for early-stage creator partnerships.
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
| Phase | Pricing Model | Requirements |
|---|---|---|
| Phase 0 (Current) | Fixed IFR amount (e.g. 1,000 IFR for Lifetime) | No oracle, no USD, fully on-chain |
| Phase 2+ (Future) | USD-based via TWAP + ETH/USD oracle | ≥ 250K USD liquidity, price floor at 40% of launch price |
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
Transition to Phase 2: USD-based pricing will only be activated once sufficient DEX liquidity exists (≥ 250K USD). Until then, token-denominated pricing ensures the protocol functions without external dependencies.
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
| Parameter | Value | Notes |
|---|---|---|
protocolFeeBps | 5 bps (0.05%) | Default, governance-adjustable |
FEE_CAP_BPS | 25 bps (0.25%) | Hard cap, contract-enforced |
| Fee target | feeCollector address | Set by governance |
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.
| Action | Points |
|---|---|
| Wallet Connect (SIWE) | 10 |
| Complete Wallet Setup Guide | 20 |
| Add IFR Token (Decimals verified) | 20 |
| Complete Lock Guide | 30 |
| Partner Onboarding | 50 |
Voucher threshold: 100 points → 15 bps discount on protocol fee, valid 7 days, single-use.
Important: IFR Points are not a token. They have no transfer value and no monetary promise. They only reduce the protocol fee on a single swap.
Contract Address (Sepolia)
0x499289C8Ef49769F4FcFF3ca86D4BD7b55B49aa4
— Etherscan